Applied Sciences P ROGRAM S UPPORT An FEA Briefing

1. Applied Sciences PROGRAM SUPPORTAn FEA Briefing 23 March 2005 by Verne Kaupp and Tim Haithcoat University of Missouri Charles Hutchinson University of Arizona

2. Part 1: Evolution of Enterprise Architecture Leading to the FEA reference model in its current instantiation.

3. Enterprise Architecture • Definition: An enterprise architecture describes the design of the components of an enterprise, their relationships and how they support the objectives of that enterprise. [http://www.seanet.com/~daveg/glossary.htm#sectE] • Positioning Enterprise Architecture "The leaders of the organization must have a clear vision of the desired future state of the entire system, including such dimensions as its business, its organization and its ways of working. This vision must be used as a common context both for diagnosing the needs for changes and for managing the process of change, so that it acts as an integrating force for the multitude of apparently disparate changes to be made. The plan for making changes must be an integrated one." (Beckhard and Pritchard, 1992)) • Bibliography See next 5 pages.

4. Enterprise Architecture Evolution • Zachman • In the mid 1980s, John A. Zachman, widely recognized as a leader in the field of enterprise architecture, identified the need to use a logical construction blueprint (i.e., an architecture) for defining and controlling the integration of systems and their components. • Accordingly, he developed a structure or “framework” for defining and capturing an architecture. This framework provides for six windows from which to view an enterprise, which he terms “perspectives” on how a given entity operates. Zachman also proposed six abstractions, “aspects” or “models”, associated with each of these perspectives. • OMB • In the late 1990s, OMB established the Federal Enterprise Architecture Program Management Office to develop a federated enterprise architecture from five “Reference Models”: Business Reference Model, Performance Reference Model, Data and Information Reference Model, Service Component Reference Model, and Technical Reference Model. • Together, the reference models are intended to facilitate government wide improvement through cross-agency analysis and identification of duplicative investments, gaps, and opportunities for collaboration, interoperability, and integration within and across government agencies. • FEA • CIO Council began developing the Federal Enterprise Architecture Framework in April 1998 to promote shared development for common Federal processes, interoperability, and sharing of information among the Federal Agencies and other Governmental entities. • CIO Council chose a segment architecture approach that allows critical parts of the overall Federal Enterprise, called architectural segments, to be developed individually, while integrating those segments into the larger Enterprise Architecture. • FEA commissioned on February 6, 2002, to: • Define and align Federal business functions and supporting IT via a set of common models • Identify opportunities to re-use and re-deploy IT assets across the Federal government • Improve effectiveness of IT spending to help yield substantial cost savings and improve service delivery for citizens. • National Applications • Today – Putting it all to use to derive benefit for citizens.

5. Federal Enterprise Architecture • What is FEA? • The Federal Enterprise Architecture (FEA) is a business-based framework for Government-Wide improvement being required by the Office of Management and Budget (OMB)to facilitate efforts to transform the Federal Government to one that is citizen-centered, results-oriented, and market-based. • The FEA is being developed by the FEA Project Management Office (FEA-PMO) through a collection of interrelated "reference models" designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across Federal Agencies. The “reference models” are: • Performance Reference Model (PRM), • Business Reference Model (BRM) v2.0, • Service Component Reference Model (SRM), • Data Reference Model (DRM), • Technical Reference Model (TRM).

6. Federal Enterprise Architecture • Why use FEA? • It is a powerful way to organize a system of interoperable systems. • The Office of Management and Budget (OMB) requires its use. • In contrast to many failed "architecture" efforts in the past, the FEA is entirely business-driven. • Its foundation is the Business Reference Model, which describes the government's Lines of Business and its services to the citizen independent of the agencies and offices involved. • This business-based foundation provides a common framework for improvement in a variety of key areas: • Budget allocation, • Horizontal and vertical information sharing, • Performance measurement, • Budget/Performance integration, • Cross-agency collaboration, • E-Gov, • Component-based architecture, and • More ….

7. FEA Reference Models There are five (5) reference models. They have a three- or four-tier hierarchy.

8. FEA Reference Models www.FEAPMO.gov

9. The Business Reference Model • "The Business Reference Model is a function-driven framework for describing the business operations of the Federal Government independent of the agencies that perform them.” • The BRM is the first layer of the Federal Enterprise Architecture and it is the main viewpoint for the analysis of data, service components and technology. • The BRM is a function-driven framework to describe the Lines of Business and Sub-functions performed by the Federal government independent of the agencies that perform them.

10. BRM Hierarchy 4 Business Areas Business Areas External Lines of Business 39 Lines of Business Internal Lines of Business 153 Sub-Functions Sub-Functions

11. Business Reference Model v2

12. The Performance Reference Model (PRM) • “The PRM is a "reference model" or standardized framework to measure the performance of major IT investments and their contribution to program performance.” • The PRM is a framework to measure the performance of major IT initiatives and their contribution to program performance. • The PRM has three main purposes: • Help produce enhanced performance information to improve strategic and daily decision-making; • Improve the alignment—and better articulate the contribution—of IT to business outputs and outcomes, thereby creating a clear "line of sight" to desired results; and • Identify performance improvement opportunities that span traditional organizational structures and boundaries.

13. PRM Hierarchy (4) Measurement Areas Measurement Area Measurement Categories (49) Measurement Category Generic Indicators (n) Measurement Indicator

14. Four Core Measurement Areas • Mission and Business ResultsThe Mission and Business Results Measurement Area of the PRM is intended to capture the outcomes that agencies seek to achieve. These outcomes are usually developed during the agency budget and strategic planning process prescribed under GPRA, and approved by the PART. • Customer ResultsThe Customer Results Measurement Area of the PRM is intended to capture how well an agency or specific process within an agency is serving its customers. This is a critical aspect of successful E-Government. • Processes and ActivitiesThe Processes and Activities Measurement Area is intended to capture the outputs that are the direct result of the process that an IT initiative supports. These outputs are much more under the control of federal programs and generally contribute to or influence outcomes that are Mission and Business Results and Customer Results. This Measurement Area also captures key aspects of processes or activities that need to be monitored and/or improved. • TechnologyThe Technology Measurement Area is designed to capture key elements of performance that directly relate to the IT initiative. An IT initiative generally can include applications, infrastructure, or services provided in support of a process or program.

15. Performance Reference Model (PRM) OUTCOMES: Mission and business-critical results Aligned with the Business Reference Model. Results measured from a customer perspective OUTPUTS: The direct effects of day-to-day activities and broader processes measured as driven by desired outcomes. Used to further define and measure the Mode of Delivery in the Business Reference Model. INPUTS: Key enablers measured through their contribution to outputs – and by extension outcomes.

16. The Service Component Reference Model (SRM) • “The Service Component Reference Model (SRM) is a business and performance-driven, functional framework that classifies Service Components with respect to how they support business and/or performance objectives.” • The SRM provides a common framework and vocabulary to characterize the IT and business components that collectively comprise an IT investment. • The SRM will help agencies rapidly assemble IT solutions through the sharing and re-use of business and IT components. • A component is a self-contained process service, or IT capability with pre-determined functionality that may be exposed through a business or technology interface.

17. SRM Hierarchy 7 Service Domain Service Domains 29 Service Type Service Types 168 Component Components

18. Seven Service Domains • Customer ServicesThe Customer Services Domain defines the set of capabilities that are directly related to an internal or external customer, the business’ interaction with the customer, and the customer driven activities or functions. The Customer Services domain represents those capabilities and services that are at the front end of a business, and interface at varying levels with the customer. This Service Domain consists of 3 Service Types and 21 Components. • Process Automation ServicesThe Process Automation Services Domain defines the set of capabilities that support the auto-mation of process and management activities that assist in effectively managing the business. The Process Automation Services domain represents those services and capabilities that serve to automate and facilitate the processes associated with tracking, monitoring, maintaining liaison throughout the business cycle of an organization. This Service Domain consists of 2 Service Types and 5 Components. • Business Management ServicesThe Business Management Services Domain defines the set of capabilities that support the management of business functions and organizational activities that maintain continuity across the business and value-chain participants. The Business Management Services domain represents those capabilities and services that are necessary for projects, programs and planning within a business operation to successfully be managed. This Service Domain consists of 4 Service Types and 20 Components.

19. Seven Service Domains • Digital Asset ServicesThe Digital Asset Services Domain defines the set of capabilities that support the generation, management and distribution of intellectual capital and electronic media across the business and extended enterprise. This Service Domain consists of 4 Service Types and 25 Components. • Business Analytical ServicesThe Business Analytical Services Domain defines the set of capabilities supporting the extraction, aggregation and presentation of information to facilitate decision analysis and business evaluation. This Service Domain consists of 4 Service Types and 19 Components. • Back Office ServicesThe Back Office Services Domain refers to the set of capabilities that support the management of enterprise planning transactional-based functions. This Service Domain consists of 6 Service Types and 47 Components. • Support ServicesThe Support Services Domain defines the set of cross-functional capabilities that can be leveraged independent of Service Domain objective and / or mission. This Service Domain consists of 6 Service Types and 31 Components.

20. Service Component Reference Model (SRM)

21. The Technical Reference Model (TRM) • "The Technical Reference Model (TRM) is a component-driven, technical framework used to identify the standards, specifications, and technologies that support and enable the delivery of service components and capabilities.” • The Technical Reference Model (TRM) provides a foundation to describe the standards, specifications, and technologies supporting the construction, delivery, exchange, and re-use of business or service components and e-Gov solutions.

22. TRM Hierarchy 4 Service Area Service Areas 17 Service Category Service Categories 52 Service Standard Service Standards Service Specifications 171 Service Specification

23. Four Core Technical Service Areas • Service Access and DeliveryService Access and Delivery refers to the collection standard and specifications to support external access, exchange, and delivery of Service Components or capabilities. This area also includes the Legislative and Regulator requirements governing the access and usage of the specific Service Component. This service area consists of 4 secondary, 14 tertiary, and 40 quartiary elements. • Service Platform and Infrastructure The Service Platform and Infrastructure Area defines the collection of platforms, hardware and infrastructure specifications that enable Component-Based Architectures and Service Component re-use. This service area consists of 5 secondary, 20 tertiary, and 60 quartiary elements. • Component FrameworkThe Component Framework Area defines the underlying foundation and technical elements by which Service Components are built, integrated and deployed across Component-Based and Distributed Architectures. The Component Framework consists of the design of application or system software that incorporates interfaces for interacting with other programs and for future flexibility and expandability. This includes, but is not limited to, modules that are designed to interoperate with each other at runtime. Components can be large or small, written by different programmers using different development environments and may be platform independent. Components can be executed on stand-alone machines, a LAN, Intranet or on the Internet. This service area consists of 5 secondary, 11 tertiary, and 46 quartiary elements. • Service Interface and Integration The Service Interface and Integration Area defines the discovery, interaction and communication technologies joining disparate systems and information providers. Component-based architectures leverage and incorporate Service Interface and Integration specifications to provide interoperability and scalability. This service area consists of 3 secondary, 7 tertiary, and 25 quartiary elements.

24. Technical Reference Model (TRM)

25. Volume I, version 1.0, ofThe Data Reference Model (DRM) is available The complete DRM is projected to contain 4 volumes and a data management strategy. Only version 1.0 of Volume I has been released to date. Accordingly, the following is only a sketch of what the complete set should contain.

26. Data Reference Model (DRM) • “The DRM’s primary purpose is to promote the common identification, use, and appropriate sharing of data/information across the Federal government.” • The Data Reference Model (DRM) describes, at an aggregate level, the data and information that support government program and business line operations. This model enables agencies to describe the types of interaction and exchanges that occur between the Federal Government and citizens. • The DRM categorizes government information into greater levels of detail. It also establishes a classification for Federal data and identifies duplicative data resources. A common data model will streamline information exchange processes within the Federal government and between government and external stakeholders.

27. DRM Structure Categorization of Data Business Context Exchange of Data Information Exchange Package Structure of Data Data Element

28. DRM Volume I • Volume One of the DRM provides a high-level overview of the structure, usage, and data-identification constructs. This document: • Provides an introduction and high-level overview of the contents that will be detailed in Volumes 2-4 of the model; • Encourages Community of Interest development of the remaining volumes; and • Provides the basic concepts, strategy, and structure to be used in future development. • The DRM is the starting point from which data architects should develop modeling standards and concepts. This volume establishes the foundation, which describes essential components, for subsequent DRM Volumes. These combined volumes support data classification - thus enabling horizontal and vertical information sharing.

29. DRM Roadmap Guide • The following table is a guide to the use of future volumes of the DRM. The table illustrates which volumes that users of the DRM will find most applicable. Volume I: DRM Overview and Purpose This volume identifies the high-level overview and purpose of the DRM. It applies to all users. Volume II: Exchange of Data Volume III: Technical Data Standards Volume IV: Technical Data Structure Data Management Strategy • Program Managers • Architects • Program Managers • Architects • Architects • CIOs, Senior Mgrs • Program Managers • Architects

30. The end of Part 1: Evolution of Enterprise Architecture Leading to the FEA framework in the current instantiation • Part 1 Conclusions • Enterprise Architecture dates back to the first half of the last century, • The Zachman framework (circa 1985), a general construct, is a powerful way to organize systems of interoperable systems, • Federal Enterprise Architecture (FEA) is an evolution of Enterprise Architecture sanctioned by the Office of Management and Budget (OMB), • It uses five (5) well-defined Reference Models for organizing the Federal government as a system of interoperable systems, • In contrast to many failed "architecture" efforts in the past, the FEA is entirely business-driven. • The FEA provides a structure for discoverability and re-use. • Its foundation is the Business Reference Model, which describes the government's Lines of Business and its services to the citizen independent of the agencies and offices involved. • This business-based foundation provides a common framework for improvement in a variety of key areas: • Budget allocation, • Horizontal and vertical information sharing, • Performance measurement, • Budget/Performance integration, • Cross-agency collaboration, • E-Gov, • Component-based architecture, and • More …. • The OMB requires its use,

31. Enterprise Architecture Bibliography - 1 • Ackoff RL: “Creating the Corporate Future”, John Wiley & Sons, New York, 1981 • Beckhard R and Pritchard W: “Changing the Essence: The Art of Creating and Leading Fundamental Change in Organisations”, Jossey-Bass, San Francisco, 1992 • Belasco JA and Stayer RC: “Why Empowerment Doesn’t Empower: The Bankruptcy of Current Paradigms”, Business Horizons, March-April 1994 • Berle A and Means G: “The Modern Corporation and Private Property”, McMillan, New York, 1932 • Brancheau JC , Schuster L, March T: "Building and Implementing an Information Architecture",: Data Base, Vol 20, No 2, July 1989, : 9-17 • Brancheau JC and Wetherbe JC: “Information Architectures: Methods and Practice”, Information Processing and Management, Vol 22, No 6, December 1986, pp453-463 • Brancheau JC and Wetherbe JC: "Key Issues in Information Systems Management," MIS Quarterly, Volume 11, Number 1, March 1987, pp23-45 • Burnham J: “The Managerial Revolution”, The John Day Co., New York, 1941 • Covey S: “The Seven Habits of Highly Effective People”, Simon & Schuster Ltd, London, 1992 • Davenport TH, Hammer M and Metsisto: “How Executives Can Shape Their Company’s Information Systems”, Harvard Business Review, March-April 1989, pp130-134 • Dickson GW, Leitheiser RL, Wetherbe JC, and Nechis M: “Key Information Systems Issues for the 1980’s”, MIS Quarterly, Vol 8, No 3, September 1984, pp135-159 • Dodds MME: “Competitiveness Does Not Lie In Downsizing - It Lies In Design”, Strategy Insights, Vol 1, No2, February 1993, pp1-3 • Drucker PF: “The New Society of Organizations”, Harvard Business Review, Sept-Oct 1992, pp95- 104 • Drucker PF: “Post-Capitalist Society”, Harper Business, New York, 1993

32. Enterprise Architecture Bibliography - 2 • Due’ RT: “In Pursuit of Enterprise Modeling”, Database Programming & Design, September 1991 • Due’ RT: “Enterprise Modeling: Still in Pursuit”, Database Programming & Design, November 1992, pp62-65 • Duncan RB and Weiss A: “Organizational learning: implications for organization design”, in “Research in Organizational Behaviour”, ed. B Straw, JAI Press, Greenwich, Conn., 1978 • Fayol H: “Industrial and General Administration”, Pitman and Sons, London, 1931 • Forrester JW: “Counterintuitive Behavior of Social Systems”, Technology Review, January 1971, pp52- 68 • Good D, Manley T: Managing Technical Architecture, Butler Cox plc, Bloomsbury Square, London, 1991 • Haeckel SH and Nolan RL: “Managing By Wire”, Harvard Business Review, Sept-Oct 1993, pp122-132 • Haeckel SH: “Adaptive Enterprise Design”, Whittemore Conference on Hypercompetition, The Amos Tuck School, Dartmouth College, September 1994 • Haeckel SH and Nolan RL: “Managing By Wire: Using IT to transform a business from ‘Make and Sell’ to ‘Sense and Respond”, Strategic Alignment in Practice, Ed. J Luftman, Oxford University Press, 1995 • Hammer M: “The Role of IS in Business Reengineering”, Prism Tape, April 1992 • Hammer M: “Succeeding at Reengineering”, Knowledgeware Conference Proceedings, April 1994 • Hartog C and Herbert M: “1985 Opinion Survey of MIS Managers: Key Issues”, MIS Quarterly, Vol 10, No 4, December 1986, pp351-361 • Hill P and Vitalari NP: “Reengineering for Fast-cycle Results”, PEP Paper 32, CSC Research and Advisory Services, London, April 1995 • Index Foundation: Building the New Information Infrastructure, Index Foundation, Final Report 91, July 1993

33. Enterprise Architecture Bibliography - 3 • Jacobs M: “Short Term America: The Causes and Cures of Our Business Myopia”, Harvard Business School Press, Boston, 1991 • Janz B, Brancheau JC , and Wetherbe JC: Key Issues in IS Management (interim report)”, IS World Net, April 1995 • Lyytintn L: “New Challenges of Systems Development: A Vision of the 90’s”, Data Base, Vol 20, No 3, Fall 1989, pp1-12 • Marx K: “Capital”, Vol 1, trans. Ernst Unterman, Kerr, Chicago, 1912 • Meyer C and Purser RE: “Six Steps to becoming a Fast-Cycle-Time Competitor”, Resource - Technology Management, September - October 1993, pp41-48 • McNabb R: “Rethinking Product Delivery”, Insurance Executive Report, Summer 1994, pp15-35 • Mc Farlan FW: “Information Technology Changes the Way You Compete”, Harvard Business Review, May- June 1984 • Mintzberg H: “The Effective Organisation: Forces and Forms”, Sloan Management Review, Winter 1991, pp54-67 • Mintzberg H: “The Fall and Rise of Strategic Planning”, Harvard Business Review, Jan-Feb 1994, pp107- 114 • New American Desk Encyclopedia: Signet, New American Library, New York, 1984 • Niederman F, Brancheau JC , and Wetherbe JC: Information Systems Management Issues in the 1990s," MIS Quarterly, Volume 15, Number 4, December 1991 , pp475-499 • Nolan RL and Mulryan DW : “Undertaking an Architecture Program”, Stage by Stage, Vol 7, 1987 • O’Sullivan L and Geringer JM: “Harnessing the Power of Your Value Chain”, Long Range Planning, Vol 26, No 2, 1993, pp59-68 • Pine BJ, Victor B, and Boynton AC: “Making Mass Customization Work”, Harvard Business Review, Sept-Oct 1993, pp108- 119

34. Enterprise Architecture Bibliography - 4 • Porter ME: “Competitive Strategy: Techniques for Analyzing Industries and Competitors”, The Free Press, New York, 1980 • Porter ME & Millar VE: “How Information Gives You Competitive Advantage”, Harvard Business Review, July- August 1985 • Rachoff N, Wiseman C & Ullrich W: “Information Systems for Competitive Advantage: Implementation of a Planning Process”, MIS Quarterly, December 1985 • Rapoport C: “Charles Handy Sees the Future”, Fortune, October 31, 1994, pp99-104 • Saarinen E: Time, 2 July 1956 • Senge PM: “The New Management: Moving from Invention to Innovation”, New Management, Summer 1986, pp7-13 • Senge PM: “The Fith Discipline”, Century Business, London, 1990 • Shrivastava P: “A typology of organizational learning systems”, Journal of Management Studies, Vol 20, No 1, 1983, pp7-28 • Sowa JF and Zachman JA: “Extending and formalising the framework for information systems architecture”, IBM Systems Journal, Vol 31, No 3, 1992, pp590-616 • Stata R: “Organizational learning - The key to management innovation”, Sloan Management Review, Vol 30, No 3, Spring 1989, pp63-74 • Sterman J: “Misperceptions of Feedback in Dynamic Decision Making”, Organizational Behavior and Human Decision Processes, April 1989 • Stewart TA: “Your Company’s Most Valuable Asset: Intellectual Capital”, Fortune, October 3, 1994, pp28-33 • Tapscott D and Caston A: “Paradigm Shift, The New Promise of Information Technology”, McGraw-Hill, 1993 • Taylor DA: • “Object Oriented Technology: A Manager’s Guide”, Addison-Wesley, 1990

35. Enterprise Architecture Bibliography - 5 • Vitalari NP: “Creating New Architectures for Anywhere, Anytime Information”, PEP Paper 30, CSC Research and Advisory Services, London, May 1995 • Weber M: “Theory of Social and Economic Organization”, trans. T Parsons, Oxford University Press, New York, 1947 • Zachman JA: “A framework for information systems architecture”, IBM Systems Journal, Vol 26, No 3, 1987, pp276-292