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.

TOOLS TO SUPPORT e-TRANSIT REFERENCE ENTERPRISE ARCHITECTURE Tools to support the e-transit reference enterprise architec- ture can be evaluated for planning and performance. Under the planning factor are sub-factors for the underlying tech- nology of the tool, market share and third-party opinions of the tool, the relative stability of the tool as it evolves, outside investments, and functional modules or third-party add-ons. Under the performance factor are sub-factors for the tool’s and other module’s packaging, pricing, ease of setup, train- ing, use, and maintenance by both systems architects and others who need to interface with the tool. Performance sub- factors include service, support, and management by the tool developer and by third-party manufacturers. TOOL REQUIREMENTS The requirements for tools for the development of e-transit reference enterprise architecture include the following: • Support architecture development at the multi-enterprise level, since e-transit will involve federal, state, and local governments as well as commercial enterprises. • Support the Office of Management and Budget concepts for architecture described in OMB 96-17. This requires the ability to represent and interrelate organizations, functions, systems, data, and infrastructure at high levels. • Be able to drill down from higher levels to lower levels. • Be able to depict evolution of the architecture. • Focus on strategy and planning rather than custom soft- ware implementation. • Support simultaneous development of the architecture by a team, which may be distributed geographically. • Provide results that can be shared across a wide audience, either by direct access via a client or by publishing it as web pages or documents. • Display architectural information understandable by non- technical users. • Provide reasonably priced options for users to access, display, and view the architecture using client software, viewers, web publishing, or some other means. • Be able to scale up and support a large, complex archi- tecture with good performance and reliability. • Be widely used, either within the transportation domain or by other government agencies. This provides some guarantee that the tools will continue to be supported by a vendor. A-1 CHARACTERIZATION OF EXISTING TOOLS There are basically three types of tools that are potential candidates: enterprise architecture tools, computer-assisted software engineering tools (CASE), and generic tools. Enterprise Architecture Tools Some of these tools evolved from enterprise modeling tools used for business process re-engineering; the rest are newer tools developed to directly support federal architecture efforts related to Clinger-Cohen and OMB 96-17. These tools are often oriented toward the Zachman Framework (a widely used enterprise architecture model) and may provide support for generation of OMB Exhibit 300s. They may include an IT inventory capability. These tools are based on a database that captures information about all architectural elements and their interrelationships. In an ideal situation, the enterprise architecture is a high- level blueprint (i.e., of people, processes, technology, and their relationships) for transforming how an entity, or function that cuts across entities, operates. Coordinated enterprise architec- tures provide a vital means to a desired end—successful deliv- ery of information and service to customers. The disadvantage of these tools is that because of their her- itage, they tend to be strongest on organizational and process modeling and weaker on technology modeling. They may be limited to the analysis as a single enterprise. They are often costly and require significant training and ongoing consult- ing help from the vendor. Computer-Assisted Software Engineering Tools Many existing CASE tools are being remarketed as “archi- tecture” tools. The capabilities of these tools generally have not been expanded in any serious way to address enterprise architecture modeling. As originally designed and sold, these tools are oriented toward capturing the requirements and design for software systems. With some difficulty, they can be used to capture requirements and design of enterprises or larger systems. The intended audience for these tools is software developers, and the diagrams and output from the tools are generally less understandable to non-technical users than the products of enterprise architecture tools. These tools may be “object oriented,” based on network and process analysis, or based on project management. Object-oriented tools tend to provide flexibility and scalability; however, users may be required to understand object-oriented design APPENDIX OVERVIEW OF POTENTIAL ENTERPRISE ARCHITECTURE APPLICATION TOOLS AND RECOMMENDATIONS

concepts. Several of the object-oriented CASE tools were identified and included in the assessment for use in develop- ing the e-transit reference enterprise architecture. Others, such as CORE by Vitech, were not part of the detailed assess- ment because of time and budget constraints. These tools are based on a database that captures information about require- ments and design “objects” and their interrelationships. Because a competent enterprise architecture is a high-level blueprint (i.e., of people, processes, technology, and relation- ships) for transforming how an entity operates, a CASE tool that manages a very detailed model of a small portion of an entity may not be appropriate to aid in the transformation of an entity. Transformation of an entity’s operations requires understandable communications and coordination through- out the entity and across interfaces to related entities. Generic Tools Generic tools are designed to support the visual represen- tation of process models, data models, and other diagrams. Tools like Visio are very flexible and can be used to create any sort of diagram, allowing users to create their own cus- tom representation formats. More specific tools like BPWin for process modeling and ERWin for data modeling could be used to represent one or more aspects of the architecture. These tools are inexpensive and widely used. Models de- veloped in them could be easily maintained by the govern- ment. Training needs are minimal. However, these tools do not support an underlying database of architectural objects and do not provide reporting or analysis. They are not multi- user and do not support team efforts explicitly. Their flexibil- ity and minimal training is a hidden liability. A drawing style, a modeling style, and a methodology must be imposed at the outset to effectively use the output of these tools to assemble an enterprise architecture. This is necessary so the indepen- A-2 dently created results will mesh when they are collected and presented as components of an enterprise architecture. In assessing available tools, the contractor will focus on those that are most commonly selected for use in recent years, with special focus on the enterprise modeling tools, since they appear to provide a better fit. Tools selected for assess- ment against the architectural requirements include Frame- work by Ptech, Adaptive, Metis by Computas, Systems Architect by Popkin, Rational Rose, and Visio. Table A-1 identifies current products in each of these categories and summarizes their characteristics. TOOLS IN USE IN THE TRANSPORTATION DOMAIN In assessing candidates, it is worth reviewing the tools that have been developed by the U.S. DOT ITS Joint Program Office for reference and use by state and local agencies. National ITS Architecture The National ITS Architecture is a reference architecture for implanting the ITS user services included in the National ITS Program Plan. The current National ITS Architecture was built using the CASE tool, Teamwork (which is no longer available). It uses ITS market packages as building blocks that can be chosen to implement the ITS user services in an integrated fashion. The artifacts produced, data flow diagrams, p-specs, and entity-relationship diagrams in the case of the ITS help users understand what information flows must take place, what each stakeholder must do, and how components may be integrated for successful deployment and operation of the overall system. However, the National ITS Architecture does not address how the ITS system relates to the business objectives of an agency or the roles and TABLE A-1 Characterization of enterprise modeling tools Category Enterprise Architecture CASE Generic Tools Examples - Framework by Ptech * ~ 100K - Adaptive by Adaptive, Inc. - Metis by Computas * ~ 20K - Systems Architect by Popkin * ~ 20K - Rational Rose by IBM - Enterprise Architect by Sparx Systems - Corporate Modeler 8e by Casewise - Visible Advantage by Visible Systems - Visio by Microsoft - BPWin by Computer Associates - ERWin by Computer Associates Focus Organization-level model of business, including IT as an element Requirements and design of custom software Visual representation of complex information Cost Range* $10,000 - 100,000 $1,000 - $25,000 $250 - $1,000 * Total cost is highly dependent on features, supplemental modules, training needs, staff training needs, and ongoing consultant support (sometimes onsite for days or weeks).

processes required to provide the information flows and interfaces required. As discussed in Chapter 3, the National ITS Architecture will therefore be used as a source of infor- mation for the development of the e-transit reference enter- prise architecture, but is not a tool per se. Turbo Architecture Turbo Architecture is a tool developed under the ITS Joint Program Office Architecture Program to assist state and local entities in developing regional ITS architectures that are based upon the National ITS Architecture and that are tai- lored to the specific ITS user services that the entities plan to implement in their regions and their supporting concept of operations. The tool comes with a predefined set of questions designed to help identify the user services, the market pack- ages that will be used to implement them, and the integration and information interfaces that are necessary for operations. Since Turbo Architecture was developed and tailored to specifically address the scope of the National ITS Architec- ture, it has limited utility and application for other uses and limited capability for extension into other layers of inter- A-3 action (non-ITS processes, roles, and responsibilities) or requirements. It is also a single-user tool with limited ability to produce custom views or drill-down analyses. TOOL COMPARISON Table A-2 compares the above tools that meet the mini- mum requirements and are therefore potential candidates for use in this project. The table excludes Turbo Architecture and others that did not pass the initial screening. The degree of support for the requirement is measured on a 0–5 scale, with 5 being complete support for the requirement and 0 being no support. In some cases, the tool does not provide explicit support of the requirement, but can be used easily in a way that would be consistent with the requirement. In these cases, an asterisk is included. TOOL SELECTION Based upon the analysis, the use of Metis by Computas (see Figure A-1) is recommended for development of the e-transit architecture. Metis is a family of client and server Requirement Fr am ew or k A da pt iv e M et is Sy st em s A rc hi te ct R os e V isi o Supports multi-enterprise architecture 2 5 5 5 3* 3* Consistent with OMB 96-17 5 2 5 5 4 3* Can drill drown from higher to lower levels 5 5 5 5 5 0 Supports depiction of evolution 1 5 5 4 1 3* Focuses on strategy and planning 5 5 5 5 0 0 Supports simultaneous development 0 5 5 5 5 0 Produces results that can be “published” 3 5 5 5 3 5 Has information that is understandable by non- technical users 4 4 4 4 2 3* Has a reasonable price 1 3 3 3 2 5 Is scalable 5 5 5 5 5 2 Is widely used 2 1 4 4 5 5 Unweighted sum 33 40 46 45 36 29 * The tool does not provide explicit support of the requirement, but can be used easily in a way that would be consistent with the requirement. TABLE A-2 Rating of selected tools against requirements

products for creating, visualizing, changing, sharing, and managing visual enterprise models and comes the closest to meeting task requirements. It also has the ability to support the evolution from today to the future vision, which is an important requirement for this effort. Popkin’s System Archi- tect is also a viable candidate and has many desirable features. It, however, is very closely tied to the Zachman Framework and may be slightly less flexible than Metis. Additional tools that best meet the needs of specific tasks may also be needed for some specific parts of the research. However, regardless of how the initial research is carried out, it is recommended that Metis be used as a repository for the final results. The following aspects of Metis make it a good choice: • Supports Multi-Enterprise Architectures. Metis has a very flexible concept of organizations that supports dif- ferent stakeholder groups. Its very flexible drill-down capability makes it good for capturing complex multi- enterprise architectures. For example, Metis is currently used by the Department of Commerce to maintain an A-4 architecture that spans all of the department’s diverse organizational components. • Can Drill Down from Higher to Lower Level: Metis supports a user-friendly drill-down capability that lets users hide details or expose them at the individual object level. • Supports Depiction of Evolution. Metis has powerful support for capturing and depicting architecture evolu- tion. Each element of the architecture can be marked as planned, operational, or in development. Designers can specify a date range when each element is valid. View- ers and designers can then filter the architecture to show only elements that are valid at a given point in time. This capability allows designers to develop an architecture that captures years of planning in a single diagram and then filter views to show what it will look like at any given point in time (e.g., in 1 or 2 years). • Supports Simultaneous Development. Metis is based on a client/server architecture. The designer and editor tools access a centralized database that contains the Figure A-1. Metis’s model development interface with navigation tool tree on left.

architecture models. Many developers can work on the architecture models simultaneously. • Produces Results That Can Be Published. Metis dia- grams can be printed or plotted. In addition, for $42 a set, a reviewer capability can be purchased that supports full viewing of the architecture and provides a comment capability. The viewer can be downloaded free as a trial for short-term use. Reviewers access a server-based copy that allows them to see the latest version at all times and view each other’s comments. • Is Widely Used. In recent years, Metis has frequently been selected over other enterprise architecture tools by federal agencies. Metis is used by the following gov- ernment agencies for representation and management of enterprise architecture: – Environmental Protection Agency; – The National Oceanic and Atmospheric Administra- tion; A-5 – Bureau of Engraving and Printing; – U.S. Department of Defense; – Bureau of Alcohol, Tobacco, and Firearms; – U.S. Mint; – U.S. Census Bureau; – Inspector General for Tax Administration; and – National Institute of Standards and Technology. Metis was competitive in price with other tools—around $8,000 a set for developers and $42 a set for reviewers. This is a bigger investment than using tools like Visio or Turbo Architecture. However, the tool is likely to pay for itself in reduced development costs. Metis does not have the weaknesses that many other enter- prise architecture tools exhibit. It supports technology archi- tecture just as well as process architecture. It appears to have been designed to support activities like e-transit.