Federal Enterprise Architecture Framework Version 2

Total Page:16

File Type:pdf, Size:1020Kb

Federal Enterprise Architecture Framework Version 2 January 29, 2013 Federal Enterprise Architecture Framework Version 2 Service Delivery Governance Enterprise Strategic Plan/Goals (PRM) StrategicRoadmap Plan/Goals (PRM) Strategic Plan/GoalsBusiness (PRM) Strategic Plan/Goals (PRM) Strategic Plan / PriorityBusiness GoalsServices Integration (PRM) Business Functional Services Method BusinessServicesData and BusinessData and Current ServicesInformation(BRM) Future (KSAs) Segments ServicesDataInformation and (SRM) Views (EVM) Views DataInformation andEnabling (Ex 53/(Ex 300) Resource Resource DataInformation andEnablingApplications(DRM) Reporting Optimization InformationEnablingApplications EnablingApplicationsHost EnablingApplicationsHostInfrastructure(ARM) ApplicationsHostInfrastructure HostInfrastructure Program Mgmt. Mgmt. Program Security Controls Security Controls HostInfrastructure(IRM) Capital Planning Capital Human Capital Mgmt. Human Capital Infrastructure Transition Plan Standards Authoritative Reference 1.1 2.1 3.1 4.1 5.1 Engage Sponsor and Iden fy Organiza ons Formalize Collabora ve Define Funding Strategy Operate with the New Assess Stakeholder and Service Providers to Planning Team and and Make Decision Capabili es Needs Engage Launch Planning 3.2 1.2 2.2 4.2 5.2 Refine the Vision for Analyze and Validate Analyze Opportuni es Obtain Resources and Measure Performance Performance and Needs to Leverage Validate Plan Against Metrics Outcomes 3.3 1.3 2.3 Analyze the Current 5.3 4.3 Formulate Case to Determine Whether to State, Determine Analyze and Provide Execute the Plan Address the Needs Leverage Adjustments, and Plan Feedback the Target State 3.4 1.4 Formulate the Iden fy and Engage Integrated Plan and Governance Roadmap 3.5 Ini ate Execu on Governance 1 January 29, 2013 Table of Contents 1 Introduction to the Federal Enterprise Architecture Framework (FEAF) v2 ......................................... 11 2 Overview of the Collaborative Planning Methodology ......................................................................... 13 3 Step 1: Identify and Validate .................................................................................................................... 15 3.1 Purpose ............................................................................................................................................. 15 3.2 The Planner’s Role............................................................................................................................. 15 3.3 Outcome ........................................................................................................................................... 16 4 Step 2: Research and Leverage ................................................................................................................ 16 4.1 Purpose ............................................................................................................................................. 16 4.2 The Planner’s Role............................................................................................................................. 16 4.3 Outcome ........................................................................................................................................... 16 5 Step 3: Define and Plan ............................................................................................................................ 17 5.1 Purpose ............................................................................................................................................. 17 5.2 The Planner’s Role............................................................................................................................. 17 5.3 Outcome ........................................................................................................................................... 17 6 Step 4: Invest and Execute ....................................................................................................................... 18 6.1 Purpose ............................................................................................................................................. 18 6.2 The Planner’s Role............................................................................................................................. 18 6.3 Outcome ........................................................................................................................................... 18 7 Step 5: Perform and Measure .................................................................................................................. 18 7.1 Purpose ............................................................................................................................................. 18 7.2 The Planner’s Role............................................................................................................................. 18 7.3 Outcome ........................................................................................................................................... 19 8 Overview of the Consolidated Reference Model ................................................................................... 20 9 Introduction to the Performance Reference Model .............................................................................. 23 9.1 Purpose of the Performance Reference Model ................................................................................ 23 9.2 Structure of the Performance Reference Model .............................................................................. 23 10 Using the Performance Reference Model Taxonomy ............................................................................ 24 10.1 Integrating CPIC (Exhibit 300) Performance Reporting with the FEA PRM .................................... 24 11 PRM Touchpoints with other Reference Models ................................................................................... 25 12 Associated Methods/Best Practices for the PRM .................................................................................. 25 2 January 29, 2013 12.1 Line of Sight ..................................................................................................................................... 25 12.2 Selecting a Balanced Set of Exhibit 300 Performance Measures.................................................... 28 13 PRM Summary ........................................................................................................................................ 28 14 Introduction to the Business Reference Model ................................................................................... 30 14.1 Purpose of the Business Reference Model ..................................................................................... 30 14.2 Structure of the Business Reference Model ................................................................................... 30 15 Using the Business Reference Model Taxonomy ................................................................................... 31 15.1 Identifying opportunities to share services government-wide ...................................................... 31 15.2 Reducing costs by eliminating duplication within the enterprise .................................................. 31 16 BRM Touchpoints with other Reference Models ................................................................................... 32 17 Associated Methods/Best Practices for the Business Reference Model ............................................... 33 17.1 Business Architecture for Decision Support ................................................................................... 33 17.2 Business Process Modeling ............................................................................................................. 34 18 BRM Summary ....................................................................................................................................... 34 19 Introduction to the Data Reference Model .......................................................................................... 35 19.1 Purpose of the Data Reference Model ........................................................................................... 35 19.2 Structure of the Data Reference Model.......................................................................................... 35 20 Using the Data Reference Model Taxonomy ......................................................................................... 36 20.1 Using the DRM to Compare Data Sources across Federal Agencies ............................................... 36 20.2 Using the DRM to Create a Standardized Information Exchange ................................................... 36 21 DRM Touchpoints with other Reference Models .................................................................................. 37 22 Associated Methods/Best Practices for the Data Reference Model ..................................................... 37 22.1 Data Description ............................................................................................................................. 37 22.2 Data Context ................................................................................................................................... 38 22.3 Data Sharing .................................................................................................................................... 39 23 DRM Summary ......................................................................................................................................
Recommended publications
  • Ewsolutions Enterprise Architecture, Data Architecture, Data
    EWSolutions Enterprise Architecture, Data Architecture, Data Governance, Metadata Management Case Study Leveraging Existing Investments in Systems, Data and Personnel to Improve Logistics and Supply Chain Management for Defense Operations Enterprise architecture planning and development, data architecture, metadata management, data governance, and enterprise data integration combined to ensure the success of the world's largest defense logistics and supply chain. EWSolutions, Inc. 1/25/2017 Developing and Implementing a New Defense Logistics Supply Chain: A Case Study in How EWSolutions Enabled Success for the US Department of Defense The Department of Defense (DoD) is America's oldest and largest government agency. It employs a civilian force of 742,000, along with over 1.3 million men and women on active duty; it is the United State's largest employer. Another 826,000 people serve in the National Guard and Reserve forces. The national security depends on defense installations, people, and facilities being in the right place, at the right time, with the right qualities and capacities to protect the security of the United States and allies. These military service members and civilians operate in every time zone and in every climate. More than 450,000 employees are overseas, both afloat and ashore. This complexity extends to the logistics, communication, and supply chain needed to connect and furnish these employees and dependents with all the required resources (food, clothing, weapons, etc.) The mission of the US Department of Defense is to provide the military forces needed to deter war and to protect the security of the United States. Fulfilling this mission requires a large variety of resources; securing and delivering those resources to the right place at the right time in the right quantities requires accurate information that comes from complete and valid data.
    [Show full text]
  • Enterprise Architecture
    Enterprise Architecture Dr. Adnan Albar Faculty of Computing & Information Technology King AbdulAziz University - Jeddah 1 Enterprise Architecture Methods Lecture 5 Week 5 Slides King AbdulAziz University - FCIT 2 Overview . Description Languages for Business & IT Domains . IDEF . BPMN . Testbed . ARIS . Unified Modeling Language . Service-Oriented Architecture (SOA) Slide 3 Description Languages . In domains such as business process design and software development, we find established description languages for modeling these domains. For software modeling, UML is of course, the single dominant language. In organization and process modeling, on the other hand, a multitude of languages are in use: there is no standard for models in this domain. We will focus on languages that either find widespread use or have properties that are interesting from the perspective of our goals in developing an enterprise architecture language. Slide 4 IDEF – Integrated DEFinition Methods .IDEF is a family of languages .Used to perform enterprise modeling and analysis .Currently, there are 16 IDEF methods. Of these methods, IDEF0, IDEF3, and IDEF1X (‘the core’) are the most commonly used. Slide 5 IDEF – The Scope it Covers .Functional modeling, IDEF0: The idea behind IDEF0 is to model the elements controlling the execution of a function, the actors performing the function, the objects or data consumed and produced by the function, and the relationships between business functions (shared resources and dependencies). .Process modeling, IDEF3: IDEF3 captures the workflow of a business process via process flow diagrams. These show the task sequence for processes performed by the organization, the decision logic, describe different scenarios for performing the same business functions, and enable the analysis and improvement of the workflow.
    [Show full text]
  • Enterprise Architecture
    www.aeajournal.org Journal of Enterprise Architecture November 2011, Volume 7, Number 4 FEATURES Editor’s Corner: John Gøtze Architect in the Spotlight: Robert Weisman ARTICLES Enterprise Architecture – Critical to Large Transformation Programs Suyog Mahendra Shah The Successful Enterprise Architecture Effort Mikkel Stokbro Holst and Tue Westmark Steensen Getting More out of Government Enterprise Architecture Wai Chung A Survey of Approaches to Virtual Enterprise Architecture: Modeling Languages, Reference Models, and Architecture Frameworks Amit Goel, Sumit Kumar Jha, Ivan Garibay, Heinz Schmidt, and David Gilbert Conceptual Outline for Rapid IT Application Information Discovery Michael Linke Rational Systems Design for Health Information Systems in Low-income Countries: An Enterprise Architecture Approach Henry Mwanyika, David Lubinski, Richard Anderson, Kelley Chester, Mohamed Makame, Matt Steele, and Don de Savigny CASE STUDY An Enterprise Architecture for Banking (in English and Spanish) Sonia González Journal of Enterprise Architecture Chief Editor: John Gøtze, PhD, IT University of Copenhagen Associate Editors Andy Blumenthal James Lapalme, PhD CTO, Bureau of Alcohol, Tobacco, Firearms and Explosives Enterprise Architecture Consultant and Researcher Tyson Brooks, PMP Haiping Luo, PhD School of Information Studies, Syracuse University International Trade Administration, US Dept. of Commerce Dick Burk Stephen Marley, PhD Enterprise Architect Harris Corporation Brian Cameron Thomas J. Mowbray, PhD Professor & Executive Director, Center
    [Show full text]
  • Integrating IT Portfolio Management with Enterprise Architecture Management 79
    Enterprise Modelling and Information Systems Architectures Vol. 8, No. 2, December 2013 Integrating IT Portfolio Management with Enterprise Architecture Management 79 Daniel Simon, Kai Fischbach, Detlef Schoder Integrating IT Portfolio Management with Enterprise Architecture Management The management of information technology (IT) as a business has become a crucial factor in today’s complex and dynamic environments. Many firms thus have implemented IT portfolio and enterprise architecture (EA) management practices, and academic research has paid increasing attention to these concepts. However, their integration seems poorly substantiated; this article therefore seeks to answer two main questions: (1) What are differences and common characteristics of IT portfolio and EA management, and in what way can they be integrated? and (2) what factors and types might describe an integrated process design of EA management and project portfolio management in particular? To answer these questions, this study synthesises previous research and surveys EA practitioners to propose an EA management process map, as well as three descriptive factors and four clusters, which provide an integrated process design with project portfolio management. The interrelations with organisational aspects and software tool support are also explored. This article thereby clarifies and systematises the subject area while also offering advice for researchers and practitioners. 1 Introduction structured, business-like approach to IT manage- ment that comprises application, infrastructure, The notion of managing information technology service, and project portfolio management (Ben- (IT) as a business (Lientz and Larssen 2004) has son et al. 2004; Kaplan 2005). attracted significant attention, particularly as IT environments grow steadily more complex and Integration is equally critical to EA management, thus more difficult to manage.
    [Show full text]
  • The History of Enterprise Architecture: an Evidence-Based Review
    Article The History of Enterprise Architecture: An Evidence-Based Review Svyatoslav Kotusev Abstract The conventional wisdom says that the concept of Enterprise Architecture (EA) originated from the pioneering work of John Zachman. He is frequently referred to as the “father” of EA and many consider the Zachman Framework to be the breakthrough that created the discipline of EA and provided the foundation for all subsequent EA frameworks and methodologies. Is Zachman’s “A Framework for Information Systems Architecture” really the seminal publication of the EA discipline? Is it really the first EA framework? Did it really profoundly influence modern EA methodologies? In order to answer these questions, in this article I describe an evidence-based history of EA and trace the origins of all essential ideas constituting the basis of the modern concept of EA. Keywords Enterprise Architecture, history, frameworks, Zachman Framework, Business Systems Planning divided into three distinct periods: Business Systems INTRODUCTION Planning, early EA, and modern EA. Almost every publication on Enterprise Architecture (EA) BUSINESS SYSTEMS PLANNING cites the Zachman Framework (Zachman 1987) as a seminal EA publication that fundamentally shaped the The idea of deliberate information systems planning is discipline of EA. Authors routinely call John Zachman far from new. Early planning approaches proposed the “father” of EA and consider his framework paper to various considerations on how to design corporate be the initial breakthrough publication that created the information systems based on an organizational strategy very concept of EA and significantly influenced its (King 1978), data flows between departments modern understanding. Moreover, many authors argue (Blumenthal 1969), suppliers and orders (Carlson 1979; that the Zachman Framework inspired all other Kerner 1979), critical success factors (Rockart 1979), subsequent EA frameworks and methodologies.
    [Show full text]
  • On the State-Of-The-Art in Enterprise Architecture Management Literature
    FAKULTAT¨ FUR¨ INFORMATIK DER TECHNISCHEN UNIVERSITAT¨ MUNCHEN¨ Technical Report On the State-of-the-Art in Enterprise Architecture Management Literature Sabine Buckl and Christian M. Schweda II Abstract The enterprise architecture (EA) and its management are topics receiving ongoing interest from academia, practitioners, standardization bodies, and tool vendors. Over the last decade and especially in the last five years, much has been said and written on these topics that nevertheless have a much longer history dating back to the nineties of the last century. In these days, John Zachman was one of the first to understand the ‘bigger whole’ in which IS architecting and IS development is embedded. Ever since these days, the canonic knowledge on this topic, which would later become known as “EA management”, has been furthered by many contributors originating from different philosophical, educational, and theoretical backgrounds, leading to numerous presentations and publications in this area. But while each article, paper or book extends the body of knowledge, it also ‘raises the stakes’ for anyone willing to enter this field of engagement. Especially, young researchers novel to this area that is not covered that much in university education than it perhaps should, find themselves confronted with a vast amount of ‘hits’, when they enter “EA management” as keyword in their favorite (scientific) search engine. This report aims at charting the landscape of EA management research and practice. Applying a generic framework for structuring the body of knowledge in the field into the two core areas of “method” and “language”, the work provides an overview on the state-of-the-art in the field, delineates interesting questions for future research, and shows how different approaches taken may be worthwhile subjects for researching how they may complement each other.
    [Show full text]
  • Business Reference Model of the Local Self-Government That Uses Process Management
    Business reference model of the local self-government that uses process management Markéta Zimmermannová Department of Information Technologies, Faculty of Informatics and Statistics, University of Economics, Prague, Czech Republic [email protected] Abstract. The objective of this paper is a brief introduction in the doctoral thesis of the author. The content of the thesis is the design of the structure for efficient management of the public administration. The author explores the options, how to combine the Enterprise Architecture elements with the business process management methodology MMABP. The output is the design of the optimal structure of the public administration office at the business level – Business reference model. Keywords: enterprise architecture, business process model, business reference model, public administration. 1 Introduction The subject of the doctoral thesis regards the Business process management and the Enterprise Architecture and the options of their application in the local self-government in the Czech Republic. In comparison with the private sector, the local self-government (and public administration in general) has a much broader set of competences. This also generates much complicated requirements on the process, functional, organizational and technological structure of the local self-government bodies. Implementation of such a structure can however be simplified by a certain form of business process standardization and by using of the Enterprise Architecture elements. The doctoral thesis therefore explores and proposes the options for usage of the process management (represented by MMABP methodology) based on the broader exploration of the very basis that the local self-government stands on and its combination with the Enterprise Architecture.
    [Show full text]
  • Enterprise Architecture for Project Managers
    Enterprise Architecture for Project Managers JK Corporate Services (JKCS) Authored by: Stan Ketchum, PMP Enterprise Architecture for Project Managers by Stan Ketchum is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License Enterprise Architecture for Project Managers Table of Contents Introduction .................................................................................................................................... 1 Purpose ........................................................................................................................................... 2 What Is Enterprise Architecture? ................................................................................................... 2 Why Is EA Needed? ..................................................................................................................... 2 What are the benefits of EA? ...................................................................................................... 3 EA vs Projects .............................................................................................................................. 3 What Does EA Consist of? ............................................................................................................... 4 EA Domains ................................................................................................................................. 4 Business Architecture ............................................................................................................
    [Show full text]
  • Architecting Software the SEI Way Twitter #Seiarchitecture © 2012 Carnegie Mellon University Outline Essential Problems for Architects
    Analyzing and Evaluating Enterprise Architectures John Klein Senior Technical Staff John has over 20 years experience developing systems and software. He joined SEI in 2008. Before joining SEI, John was a chief architect at Avaya, Inc. There his responsibilities included development of multimodal agents, architectures for communication analytics, and the creation and enhancement of the Customer Interaction Software Product Line architecture. Prior to that, John was a software architect at Quintus, where he designed the first commercially successful multi- channel integrated contact center product and led the technology integration of the product portfolio as Quintus acquired several other companies. See his full bio at: www.sei.cmu.edu/go/architecting-software-the-sei-way Architecting Software the SEI Way Twitter #SEIArchitecture © 2012 Carnegie Mellon University Outline Essential problems for architects - • How do we efficiently translate business goals into quality attribute requirements? • How do we ensure that these quality attribute requirements are reflected in the tradeoffs and decisions that shaped the architecture? Agenda • Review of the SEI perspective on architecture-centric engineering • Scaling from software context to systems of systems and enterprise architectures • An approach to developing quality attribute requirements for enterprise architectures • An approach to first-pass evaluation of enterprise architectures • Tying together EA and system/software analysis and evaluation Architecting Software the SEI Way 1 Twitter #SEIArchitecture © 2012 Carnegie Mellon University Architecture-centric Engineering – Software and Systems IMPLEMENT AND EVOLVE DESIGN IMPLEMENT BUSINESS AND MISSION GOALS ARCHITECTURE SYSTEM SATISFY CONFORM SATISFY Architecting Software the SEI Way Twitter #SEIArchitecture © 2012 Carnegie Mellon University Principles of Architecture-Centric Engineering Every system has an architecture, regardless of scale.
    [Show full text]
  • 4.3 NWS ENTERPRISE ARCHITECTURE Bobby Jones
    4.3 NWS ENTERPRISE ARCHITECTURE Bobby Jones*, Chief IT Architect Barry West, Chief Information Officer NOAA’s National Weather Service 1 INTRODUCTION An Enterprise Architecture (EA) is a comprehensive blueprint that aligns an organization’s business In 1996, Congress required Federal Agency Chief processes with its Information Technology (IT) Information Officers (CIO) to develop, maintain, and strategy. It is documented using multiple facilitate integrated systems architectures with the architectural models or views that show how the passage of the Clinger-Cohen Act. Additionally, current and future needs of an organization will be Office of Management and Budget (OMB) issued met. The key components of the EA are: guidance that requires agency information systems investments to be consistent with Federal, Agency, • Accurate representation of the and bureau architectures. Enterprise Architectures business environment, strategy and (EA) are “blueprints” for systematically and critical success factors completely defining an organization’s current • Comprehensive documentation of (baseline) or desired (target) environment. EAs are business units and key processes essential for evolving information systems and • Views of the systems and data that developing new systems that optimize their mission support these processes value. This is accomplished in logical or business • A set of technology standards that terms (e.g., mission, business functions, information define what technologies and flows, and systems environments) and technical products are approved to be used terms (e.g., software, hardware, communications), within an organization, and includes a sequencing plan for transitioning complemented by prescriptive from the baseline environment to the target enterprise-wide guidelines on how environment. to best apply these technology standards in creating business If defined, maintained, and implemented effectively, applications.
    [Show full text]
  • 030610 IAC EA SIG Information and Data Reference Model Bod…
    Business Integra tion Driven By Business Lines 06/10/2003 Business Integration Driven by Business Lines: A perspective on the Data Reference Model as it relates to Cross Agency Challenges. Standards Based Architecture to Support Federated Data Management. Concept Level WHITE PAPER Developed for the Federal Enterprise Architecture Program Management Office (FEA -PMO), Federal CIO Council, NASCIO, and Public Cross Government Initiatives Industry Advisory Council (IAC) Enterprise Architecture SIG May 28, 2003 Business Integra tion Driven By Business Lines 06/10/2003 DISCLAIMER While the Federation of Government Information Processing Councils/Industry Advisory Council (FGIPC/IAC) has made every effort to present accurate and reliable information in this report, FGIPC/IAC does not endorse, approve or certify such information, nor does it guarantee the accuracy, completeness, efficacy, and timeliness or correct sequencing of such information. Use of such information is voluntary, and reliance on it should only be undertaken after an independent review of its accuracy, completeness, efficacy and timeliness. Reference herein to any specific commercial product, process or service by trade name, trademark, service mark, manufacturer or otherwise does not constitute or imply endorsement, recommendation or favoring by FGIPC/IAC. FGIPC/IAC (including its employees and agents) assumes no responsibility for consequences resulting from the use of the information herein, or from use of the information obtained from any source referenced herein, or in any respect for the content of such information, including (but not limited to) errors or omissions, the accuracy or reasonableness of factual or scientific assumptions, studies or conclusions, the defamatory nature of statements, ownership of copyright or other intellectual property rights, and the violation of property, privacy or personal rights of others.
    [Show full text]
  • Open Issues on Information System Architecture Research Domain: the Vision
    OPEN ISSUES ON INFORMATION SYSTEM ARCHITECTURE RESEARCH DOMAIN: THE VISION André Vasconcelos CEO - Centro de Engenharia Organizacional, INESC, Lisboa, Portugal Email: [email protected] Carla Marques Pereira EST-IPCB, Av. do Empresário, Castelo Branco, Portugal Email: [email protected] Pedro Sousa, José Tribolet CEO - Centro de Engenharia Organizacional, INESC, Lisboa, Portugal Email: [email protected], [email protected] Keywords: Information System Architecture (ISA), ISA Evaluation, Business/System Alignment, Enterprise Information System, CEO Framework. Abstract: Currently organizations, pushed by several business and technological changes, are more concern about Information systems (IS) than ever. Though organizations usually still face each IS as a separately technological issue with slight relations with business domain. This paper discusses the importance of the Information System Architecture (ISA) as the tool for ensuring a global view on IS and for explicitly assessing alignment between technology and business processes and strategies. In this paper, considering the numerous topics, technologies and buzzwords surrounding ISA domain, we identify the major ISA open issues, namely: ISA Modelling, ISA Methodology, ISA Evaluation, IS Architectural Styles and Patterns, and IS/Business Alignment. We also present our advances in addressing some of these issues, by proposing an approach for ISA evaluation and IS/Business Alignment measure. This approach is supported on an ISA modelling framework and provides several indicators and measures for ISA evaluation. This approach is applied to an IS health care project evaluation. 1 INTRODUCTION enterprise knowledge handling. These new business needs have being forcing organizations to redesign their strategies, reengineering their business During the last decade several important processes and positioned efficient information technological progresses have been accomplished in handling in every organization agenda.
    [Show full text]