Concept for an e-Transit Reference Enterprise Architecture (2004)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

5CHAPTER 2 SUMMARY OF SYSTEMS ENGINEERING AND ENTERPRISE ARCHITECTURE CONCEPTS This chapter explains the essential relationship between sys- tems engineering procedures, or disciplines, and how they relate to and support the concept of an e-transit reference enter- prise architecture. General guidelines for the development of the e-transit reference enterprise architecture and its use by a typical transit agency once it is developed will be explored. Figure 2-1 presents the question that this section discusses. An enterprise architecture is a communications tool that allows non-engineers and business leaders to understand the whole enterprise in a more integrated manner. The role of the enterprise architecture9 is to respond to business leaders when they ask “How?”, “When?”, “Where?”, “Why?”, “Who does what?”, and “What resources or tools do they need to do it?” The enterprise architecture models the important pieces of the entire actual system and allows others to see what is happen- ing within the enterprise and to examine what can happen in the future enterprise. The creation of an enterprise architecture is supported by the underlying systems engineering procedures of operational requirements definition and analysis, evaluation of alter- natives, design and implementation, testing, incorporation of feedback, and iteration. However, systems engineering and the tools that have been developed to support it aim at spe- cific technical systems or functions within the organization and do not encompass the overall operations of the business. Enterprise architectures and the tools that support them are designed to capture this larger perspective. A useful enterprise architecture for an operational transit system will be sufficiently complex that it cannot be effec- tively created or maintained without the use of a computer application. An enterprise architecture tool must support sound engineering practices associated with creating models of established systems, showing the linkage of those systems, and modeling established data and process flows. A useful enterprise architecture must have several desir- able qualities. It must be good enough, but not perfect. It must be flexible and sustainable. It must address the impor- tant pieces of the enterprise, and it must support rapid itera- tion. Management and control of the systems engineering processes are necessary to produce a useful, flexible, sustain- able enterprise architecture for an e-transit organization that serves the needs of its business leaders. Several computer applications to support both systems engi- neering and enterprise architectures were surveyed and evalu- ated in the development of this concept paper. The tools devel- oped to support the systems engineering processes typically focus on narrowly scoped areas and can be very effective in dealing with their little piece of the enterprise architecture. Complicating matters is that these separate tools often do not work well together while they work to optimize their specific areas with little or no understanding of the entire enterprise. As a result, such a collection of engineering tools cannot address all the important pieces of an entire enterprise in a compre- hensive yet useful manner. The tools developed to support enterprise architectures overcome these issues. Depending on an organization’s needs, either Metis by Computas or System Architect by Popkin would be a good choice. The appendix presents details of the enterprise architecture tool evaluation. 2.1 OVERVIEW OF ENTERPRISE ARCHITECTURE CONCEPTS Enterprise architectures are widely used as a tool for man- aging and planning the evolution of large, complex “enter- prises.” An “enterprise” can be any complex entity or group of entities that share a common set of purposes. Some exam- ples are a commercial company, a government agency, a large nonprofit organization. Enterprise architectures evolved out of the business process re-engineering and IT strategic plan- ning of the late 1980s and early 1990s. John Zachman origi- nally proposed the idea of an enterprise architecture in 1987.10 His representation of a general enterprise architecture is the Zachman Framework.11 As it applies to enterprises, the framework is simply a log- ical structure for classifying and organizing the descriptive representations and views of an enterprise from different perspectives that are significant to the management of the enterprise as well as to the development of the enterprise’s systems. The rows capture the views and perspectives of the different major roles in maintaining and operating any enter- prise. They move from Row 1’s highest contextual perspec- 9Building the Enterprise Architecture: The Popkin Process, Version 1.0. 10 “A Framework for Information Systems Architecture,” J. A. Zachman, IBM Systems Journal, Volume 26, Number 3, 1987, and “Extending and Formalizing the Framework for Information Systems Architecture,” J. F. Sowa & J. A. Zachman, IBM Systems Journal, Volume 31, Number 3, 1992. 11URL: http://www.zifa.com, © John A. Zachman, Zachman International.

tive of the planner—which captures what is important to the enterprise; the context in which the enterprise operates; its mission, goals, and objectives and how and when the enter- prise meets them; and its important stakeholders—to Row 5’s detailed representations and descriptions of the data, technologies, and software applications needed for imple- menting and operating the functions and processes of the business. Each successive row provides more details needed to implement the requirements and constraints from the rows above. The columns capture the answers to “What?”, “How?”, “Where?”, “Who?” “When?”, and “Why?” from each row’s perspective. The column order does not represent any partic- ular sequence, and the columns can be rearranged in any order that best meets the needs of the enterprise architecture being developed. However, Zachman’s original paper only presented the “What?”, “How?”, and “Where?” columns. The remaining “Who?”, “When?”, and “Why” columns help provide the context and constraints of the business at each level. Since originally proposed, the Zachman Framework has been refined and variants have emerged (e.g., the Popkin Process, the Federal Enterprise Architecture Process, and the NIST Five-Layered Architecture Structure). All variants relate back to the original framework, but may be tailored to meet specific needs and purposes of the enterprise architec- tures they are used for. Not all the rows or columns of the Zachman Framework are necessary for all applications, and what is included should be scoped to address the issues being raised using the resources and time available for the effort. For example, a reference enterprise architecture typically includes the Row 1, “Contextual, Planner,” and Row 2, “Conceptual, Owner,” and sometimes parts of Row 3, “Log- ical, Designer,” views of the enterprise. The remaining rows apply to site-specific design and development issues. They focus on the design and engineering details associated with a specific business and its operations and therefore usually cannot even be incorporated into a reference architecture. Likewise, the information associated with a specific business 6 in the “who” and “when” columns may not be appropriate for a reference architecture. An enterprise architecture models important aspects of the enterprise, representing them and their interrelationships in a way that supports communication, analysis, and planning (see Figure 2-2). Enterprise architectures typically capture, at a minimum, information about people, business processes (i.e., functions), data, and supporting infrastructure. Addi- tional elements may include location and time. The relation- ships between these aspects must also be captured to under- stand the enterprise as a whole and make the architecture valuable. A reference architecture, or generic blueprint, provides guidance for developing an agency-specific enterprise archi- tecture. A reference architecture tailored for e-transit will facilitate a transit agency’s self-examination and modeling of the important pieces and relationships of the whole transit enterprise in a descriptive framework. Guidance in using an e-transit reference architecture will help ensure that the re- sulting e-transit enterprise architecture for a specific organi- Systems Engineering Procedures Requirements Definition, Analysis, Reliability, Benefit, Availability, Maintainability, Failure Mode, Design, Test, Evaluation, Metrics, Cost, Trade-off Studies, Schedule, Risk, Value, Operations, etc. Enterprise Architecture e-Transit Repository for information and relationships: - People - Processes - Technology - Business Requirements How are these related? Figure 2-1. How do systems engineering procedures relate to enterprise architecture? Enterprise Architecture eTransit Repository for information and relationships: - People - Processes - Technology - Business Requirements Technology Data SW HW Mission, Goals, Objectives Business Requirements Functions (Processes) People Ref ere nce Arc hite ctu re Mo del an d S ubm ode ls Inte rfac e S tan dar ds Sec urit y Is sue s Figure 2-2. An enterprise architecture models the organization.

zation has the characteristics of a good enterprise architecture and that the enterprise architecture is useful for understanding the enterprise and analyzing alternative responses to business changes and emerging technology. The reference architecture will address techniques such as knowledge management, business (re)engineering, data warehousing, and alignment of business and IT strategy—all techniques crucial to the success of e-transit. The reference architecture will also include the functions and responsibilities needed to provide governance and man- agement of the evolution toward the future “To Be” scenario. This governance process may also provide an example for agency-specific e-transit enterprise architectures for manag- ing change and in the organization’s priorities, new tech- nologies, or external factors. A good enough architecture covers the immediate time frame and provides guidelines, models, interfaces, defini- tions, and protocols for immediate use by business leaders in managing and planning processes and systems engineers in the design and integration processes.12 A design goal of any reference enterprise architecture should be the flexibility to respond to changing business and technology drivers. The phases of development and imple- mentation captured within a reference enterprise architecture are shown in Figure 2-3. Along with the overall vision for an organization’s long-term e-transit enterprise architecture, smaller pieces will be implemented to provide value in the immediate time frame. Larger pieces will be planned and implemented over a tactical period of 12 to 24 months. Over the strategic period of 36 months, changes due to new busi- ness requirements or emerging technology may be made to the e-transit enterprise architecture. 7 The e-transit reference enterprise architecture may also be used as a foundation and starting point for specific transit agency enterprise architectures. The most important pieces of an agency’s e-transit enterprise architecture depend on the specific conditions and priorities that the agency faces. For one agency, interoperability and integration may be high- priority architecture work. For another agency, ease of cus- tomer access or ease of exchanging information may be the high priority. A useful enterprise architecture is also one that is easily changed over time to respond to changes in business drivers and emerging technology. A practical enterprise architecture is more important than the ultimate vision or the perfect enterprise architecture. The underlying assumption is that the enterprise architecture will need to be amended often. The design of the enterprise architecture must incorporate gover- nance, an organizational structure, and a process to ensure that it is updated as often as necessary. Certainly, excessive change to an architecture diminishes its value; however, fre- quent, regular change to respond to evolving needs and oppor- tunities is healthy. Thus, an enterprise architecture should have program rather than project status. This will aid continuity of process and retention of corporate knowledge associated with sustaining and using an enterprise architecture for business management, design, and integration. One method of developing and modeling an enterprise architecture uses an operations architecture that focuses on the immediate (or near-term) time frame and acts as a stabi- lizing conduit between the current (or legacy) business pro- cesses and the future enterprise architecture. Figure 2-4 shows how the use of a sound operations architecture is a practical approach that facilitates construction of a useful overall enterprise architecture. Transit organizations may find that business logic neces- sary to sustain established operations is hidden in legacy ap- 12Schulman, J. Defining “Good Enough” Architecture, Gartner Research Note, COM- 20-2743, July 1, 2003. Immediate time frame Architecture projects deliver value 12 months 24 months 36 months Tactical Rolling Period Implementation of Near-Term Architecture Strategic Window Aligns with the e-Transit Long-Term Architecture Figure 2-3. Time frames suggested in the reference enterprise architecture. Business Strategy Operations Architecture Enterprise Architecture Figure 2-4. Stabilizing role of an operations architecture.

plications and poorly documented processes. The e-transit components of the future enterprise architecture may have substantial impact on the organization’s ability to both re- main competitive and change. The e-transit, IT, and other components of an operations architecture can perform a dual role of maintaining essential stability while fostering change.13 The goal is to manage the cost of the operations while improving the availability and performance of busi- ness processes in a changing environment where e-transit and IT become integrated into the business process. The enterprise architecture must become flexible and sustain- able through the use of appropriate systems management tools. Defining the operations architecture and making it the core of the transition plan can help the enterprise architects, de- velopers, and operators all become part of a common team.14 This can help the enterprise architects address the effects of architectural complexity and its impact on manageability so the complexity does not lead to poor manageability, lower quality of service, and higher costs. John A. Zachman defines enterprise architecture as the set of descriptive representations (i.e., models) that are relevant for describing an Enterprise such that it can be pro- duced to management’s requirements (quality) and main- tained over the period of its useful life (changed).15 An important consideration in the development of enter- prise architectures is the scope. Whatever is left out of the enterprise architecture will not be subjected to analysis or planning using that enterprise architecture. But the scope does not need to be the entire organization. There is no min- imum or maximum size of an architecture. There is no re- quirement that all components be within the same organiza- tion or that the enterprise be an entire organization. One of the first challenges of an enterprise architecture is to estab- lish the boundaries of the enterprise, an issue that will be addressed in the next phase of this work. Suppose, however, a policy decision is made to include everything, however briefly, in the enterprise architecture. The models should be developed at a high (i.e., general) level to contain the effort to create the architecture but detailed enough in the areas of interest to provide sufficient fidelity that the models and architecture are useful and practical for their intended purpose. A balance is necessary to enable a 8 practical, useful enterprise architecture. For e-transit, level of detail is a critical issue, since it is easy to capture extraneous detail beyond what will be useful in some areas of the frame- work. The reference enterprise architecture and the guide- lines will help achieve balance. In summary, it is important to be realistic about which lev- els of the enterprise architecture are developed. Develop only the highest (i.e., most general) level, and the architecture has limited usefulness. Develop the architecture down to too low a level (i.e., too specific a level) and it will never be able to be completed before it is obsolete. The balance is found in capturing additional detail only in those areas that are impacted by new business rules or new technology in the near term. Development of an enterprise architecture, including the current and future architectures and the transition plan for evolution, is a complex process. Typical architecture projects begin with the development of the current architecture using a team composed of domain experts and facilitators with architectural development expertise. Once the current archi- tecture is developed, a combination of strategic requirements from domain experts and system engineering is required to develop the future architecture. Similarly, the team develops the operations architecture, which is the core of the transition plan. As discussed next, most of the effort should be allo- cated to the operations architecture and transition plan for near-term use. The team must identify and investigate alter- natives. Priorities must be set and may include interoperabil- ity, sharing, reuse, and service-oriented metrics. Important issues to be addressed include the following: • How to relate the cells in the framework? • How to use the framework to capture data and reveal the enterprise architecture? • How to choose supporting systems engineering tools and when to use them? • How to produce the designs and deliverables necessary to achieve the goals of the transit organization? Consider a transit enterprise architecture as the product of an effort (performed by systems engineers using systems engineering concepts described in the next sub-section) to systematically describe and model transit services and relate them to the people, processes, and technology needed to sat- isfy the performance metrics of business requirements. Here technology expands to include data, software (applications), and hardware. Processes expand, for example, to provide customer service, assess condition/status, perform planning, authorize use, implement actions, monitor actions, manage compliance, manage work, and sustain the transit organiza- tion. Figure 2-5 shows an internal set of relationships in these enterprise architecture building blocks: • The transit mission and business requirements define business functions (i.e., processes). 13Govekar, M., Enterprise Architecture Builds on Operations Architecture, Gartner Research Note COM-16-8215, June 19, 2002. 14Ibid. 15As quoted in “Building an Enterprise Architecture: The Popkin Process Version 1.0,” Popkin Software, Inc., date unknown, obtained at www.popkin.com. The white paper does not provide a specific citation for the quote. It does provide the following in its reference section: Zachman, John A. “A Framework for Information Systems Architecture.” IBM Sys- tems Journal, 26 (No. 3, 1987) [IBM Publication G321-5298. 914-945-3836 or 914- 945-2018 fax.]. Sowa, J.F. and J. A. Zachman. “Extending and Formalizing the Framework for Infor- mation Systems Architecture.” IBM Systems Journal, 31 (No. 3, 1992).

• Processes define data (i.e., operational, administrative, engineering, and other). • Processes and data define applications (i.e., software). • Processes, data, and applications define the transit and technology infrastructure (i.e., hardware). Logic suggests that defining the business processes should precede defining data, which in turn should precede applica- tions. In practice, capturing the current transit architecture and transitioning to a new architecture may proceed on multi- ple building blocks simultaneously. It may appear less than systematic to have a mixture of long-term (i.e., enterprise) efforts and short-term efforts that bridge gaps between where we are and where we want to be. For most customers, the transit system will continue to operate and serve them well while some architectural magic occurs. Another important concept for enterprise architectures is the representation of evolution. For planning purposes, an “As Is” architecture is generally developed first. Then, a future goal architecture is developed based on strategic plan- ning and the analysis of unmet requirements. An operational architecture and transition plan for evolution in the near term is developed that takes the “As Is” architecture and trans- forms it to the future architecture over a period of time, often in stages. This plan provides a road map for evolution and can be used to guide project planning and budgets. It is also practical because the “To Be” architecture can be somewhat general and subject to change as the near-term changes are implemented, while the business changes and technology continues to improve. Other considerations that are important to capture in enter- prise architecture development include security and coordi- nation with other organizations. Security systems need to be part of the enterprise architecture. Current best practice is to include security within the rest of the framework, rather than 9 develop a separate security architecture or separate security elements. Security requirements must be addressed wherever they are appropriate. Coordinated enterprise architectures among transportation entities will facilitate sharing and reuse within the transit community. Figure 2-6 shows a common external relationship for interoperability: compatible inter- face standards. Current best practices in the development of enterprise architecture incorporate the use of tools because of the com- plexity of the architecture.16 Two tools are currently used by many agencies within the federal government. System Archi- tect by Popkin is frequently used to capture agency architec- tures and provides good linkage into the Office of Man- agement and Budget’s (OMB’s) budget process. Metis by Computas is also widely used, especially for cross-agency projects. These tools provide many features that streamline the process of modeling the enterprise, provide better com- munication, and support management of the enterprise and development of the enterprise’s systems. 2.2 OVERVIEW OF SYSTEMS ENGINEERING CONCEPTS Enterprise architectures capture relationships and interac- tions between systems, business processes, people, and var- ious disparate technologies in order to provide a cohesive and useful description of the enterprise. Systems engineering helps identify the goals and needs of the organizations and what the relationships should be. Systems engineering evolved during the 1960s and 1970s to assist the developers of the defense program and other complex high-technology systems in identifying and tracing requirements, examining tradeoffs, and evaluating risks to ensure that once the systems were implemented they worked as planned. Systems engineering provides a disciplined envi- ronment to design quality into complex systems from the very beginning. Key to the success of systems engineering is the involvement of all the stakeholders and users of the system throughout the process to correctly identify what the system is supposed to do. This collective involvement provides a mechanism to view transit services as a business, focus on needs and goals, address the operational requirements and ways to accomplish them, examine alternatives, and trace im- pacts through the system to see the results. Systems engineer- ing becomes increasingly important as provision of transit service shifts from independent operation within a single tran- sit agency to dependence on coordinated operation of complex systems (e.g., automatic vehicle location/computer-aided dispatch, communications, automatic passenger counters, and signal priority) across numerous providers and modes Enterprise Architecture eTransit Repository for information and relationships: - People - Processes - Technology - Business Requirements Technology Data SW HW Mission, Goals, Objectives Business Requirements Functions (Processes) People Sec urit y Is sue s Ref ere nc e A rch itec ture Mo del an d S ubm ode ls Inte rfac e S tan dar ds Figure 2-5. A logical sequence for developing content in enterprise architecture building blocks. 16See the appendix for a more complete discussion of enterprise architecture tools, their characteristics, and the selection criteria and recommendations for use in devel- oping an e-transit reference enterprise architecture.

(e.g., multiple local transit agencies, trains, ITS, traffic net- works, and information providers) using computerized pro- curement, maintenance, asset management, and delivery sys- tems to provide mobility management to customers.17 The steps found in the overall systems engineering process are as follows: 1. Identify the concept of operations (through users and stakeholders), including a. Needs and goals, b. External factors (e.g., environment, constraints, and policies), c. Initial operational concepts, and d. Initial operational scenarios (e.g., peak, off-peak, inclement weather, and emergency/disaster). 2. Develop operational requirements (e.g., functions, pro- cess, performance, and verification). 3. Identify and evaluate alternatives (e.g., according to feasibility risk, uncertainty, reliability, and costs). 4. Trace impacts on existing organizations and processes. 5. Integrate and implement system components. 6. Provide for verification and validation. 7. Incorporate feedback and iteration into development and design (i.e., refine). 8. Manage the implementation and operation of the inte- grated system, and incorporate changes as they occur. In general, there are two phases to systems engineering: (1) identifying “what” is to be built (i.e., goals, needs, and requirements) and (2) providing integration, testing, verifica- tion, validation, and change management as the system is im- plemented and operated. How systems engineering is applied and implemented (i.e., the level of detail, feedback and iter- ation methods, and appropriate software tools) depends on 10 the purpose and focus of the project that it is being used for.18 Figure 2-7 provides some examples of approaches to incor- porating feedback and iteration within the process. These vary from a simple “waterfall” approach, moving from step to step with iteration at the next cycle of development; to a “Vee” model, with overlapping steps (e.g., needs analysis and concept of operations) and feedback/iteration between each step; to a “spiral” approach, with increasing levels of detail as needs and designs are refined. For the development of the e-transit reference enterprise architecture, the focus of the systems engineering will be on the first phase of systems engineering: developing the needs, goals, and required functions and accounting for future con- tingencies, risks, and impacts on transit’s business processes and organization. Consequently, since the ongoing imple- mentation management, verification, validation, and feed- back to incorporate change is not the focus of this effort, a waterfall or modified spiral process of feedback and refine- ment will likely be used. In applying a systems engineering process to improve the business of providing public transportation services, the business processes associated with the business functions of transit agencies must be identified and examined. The sys- tems engineering discipline can call upon any of numerous traditional engineering procedures that may be appropriate for a specific engineering project and may be performed for a specific transit system project. When an enterprise architecture is used, systems engi- neering procedures employed may include • Documenting and describing established systems with performance metrics, • Creating models of established systems to an appropri- ate fidelity, 17See TCRP Research Results Digest 55, December 2002. Interoperability Requirements Enterprise Architectures Government Agencies, Transit Agencies, Professional Societies, Suppliers Customers Stakeholders Enterprise Architecture eTransit Repository for information and relationships: - People - Processes - Technology - Business Requirements Technology Data SW HW Mission, Goals, Objectives Business Requirements Functions (Processes) People Sec urit y Is sue s Mo del an d S ubm ode ls Inte rfac e S tan dar ds Ref ere nce Arc hite ctu re Figure 2-6. Interoperability prerequisite: compatible interface standards. 18 “The Engineering Design of Systems: Models and Methods” (D. M. Buede, John Wiley & Sons, 2000) provides a general discussion.

• Documenting the relationships between established sys- tems with appropriate metrics, • Describing the linkages between modeled systems, • Documenting established data and process flows, • Modeling established data and process flows, and • Following specialty and traditional engineering proce- dures for transit and IT that support the goal of the enter- prise architecture and its use for communications and planning. Another element that can characterize a good enterprise architecture is the amount of systems engineering effort that is expended on the current, near-term, and future architectures, as shown in Figure 2-8. Schulman20 believes that 15 percent of the systems engineering effort needs to address the “As Is” 11 architecture, 70 percent of the effort needs to address the near term, and 15 percent needs to address the “To Be” enterprise architecture. For the “As Is” effort, systems engineers docu- ment and analyze the current architecture. Engineering pro- cesses involved are creating models of established systems, Definition of Need fi iti f Conceptual Analysis ce t l al sis Preliminary Systems Design reli i ary yst s si Detail Design & Development et il si e el e t Production & Construction rod cti str ti Utilization, Evaluation & Support tili ti , l ti rt Phase Out & Disposal s t is sal P R O J M G M T Waterfall Spiral “Vee” Figure 2-7. Approaches to feedback and iteration within systems engineering.19 19 “The Systems Engineering Process & its Variants: A Quick Refresher including QFD, IDEF 0 & Design–ilities,” Tutorial, Bob Lewis, Mitretek Systems Tutorial, Falls Church Virginia, 4 February 2002. 20Schulman, J. Defining “Good Enough” Architecture, Gartner Research Note, COM- 20-2743, July 1, 2003. Near Term 15%15% 70% “To Be” “As Is” Figure 2-8. Apportioned systems engineering effort in enterprise architecture development.

showing the linkage of those systems, and modeling estab- lished data and process flows. The key to this process is pre- dicting what will probably be useful and what will probably sit on the shelf unused. Systems engineering and enterprise architects can derive great satisfaction from detailing a massive current architecture that fills binders that span a book shelf, but the downside is that the resulting overly detailed architecture project may live only on that shelf, unused and untouched. Enterprise archi- tecture is an ongoing program that is subject to change, and it 12 must be flexible to incorporate new business processes and emerging technology. This is the reason to apportion the effort involved in creating an abbreviated “As Is” architecture, a “To Be” architecture that is usually full of generalizations, and an operational architecture for use during the near term. It is this good enough, near-term architecture that covers the immediate time frame and provides guidelines, models, interface definitions, and protocols for immediate use by sys- tems engineers in the design and integration processes for e-transit operations.