Using Metamodels to Improve Enterprise Architecture

Case Study

By Lynn Uzzle

Abstract This case study article describes the rationale for the development, use, and benefits of a metamodel to provide the underlying data model for Enterprise Architecture (EA) content. The case study uses the “EA3 Framework” (Bernard 2004, 2005) to illustrate these points. Metamodels enable integration among models and other artifacts that constitute most EA content. Integrated EA content enables repeatable and reliable analysis and reporting, mapping content to frameworks or reference models, and transitions among EA tools for upgrades or conversions. The initial publication of the EA3 Framework in did not define a metamodel or prescribe artifact content in detail. Artifact content and examples were added in the second edition of the EA3 Framework in 2005, including 46 artifact types that document the five layers and three thread areas of this framework. Though the relationships between the layers and threads were described in the 2nd edition of the EA3 Framework, this case study article provides the first detailed meta-model. The proposed EA3 Metamodel that is described in conceptual and diagrammatic form was developed to support the use of the EA3 approach by the author within a federal government agency using a bottom-up approach based on tool capabilities and reporting obligations. The metamodel described in this case study has been implemented using a commercially-available modeling toolset, and required no tool customization.

Keywords enterprise architecture models, framework, data model, metamodel, EA3

INTRODUCTION framework, predecessor to the DoDAF, was driven by the need for comparable architecture Since the inception of Enterprise Architecture descriptions to improve interoperability among (EA) as a discipline, many frameworks have command and control systems supporting been developed and thereafter have evolved. military and intelligence operations. Their purpose is to shape the domain of concern by defining the concepts of interest. Although Spewak’s Enterprise Architecture Planning these frameworks all point in the same general (EAP), 1992, while not a framework per se, direction, they do not all address the same set of influenced many frameworks and related problems. Their differences and similarities can methodologies with its emphasis on identifying be at least partially explained by motivational the current (“as-is”) state, the target (“to-be”) and organizational differences in their origins. state, and the transition from current to target.

The Zachman (1989) and Department of The Federal Enterprise Architecture Framework Defense Architecture (DoDAF – 2007) (FEAF) (CIO Council, 1999), derived from the frameworks focused initially on systems Zachman framework and EAP, was motivated architecture although they have both been by the need to ensure alignment of federal IT to adopted as EA frameworks. Zachman’s work business goals and added both the notion that was inspired by the need to manage complexity the architecture evolves, driven by changes in in information systems. both business needs and technology, and that an enterprise architecture could be approached The Command, Control, Communications, in segments as a way to manage the size and Computers, Intelligence, Surveillance, and complexity of the problem. Reconnaissance (C4ISR) Architecture

© Journal of Enterprise Architecture – February 2009 49 The Open Group Architecture Framework highlight the inherent relationships among (TOGAF) 2009 has historically focused on the business, data, and technology, but most of architecture development methodology and them remain at a conceptual level. Greater ongoing concerns such as governance (TOGAF precision requires deeper specification of the Version 9, released in February 2009, now exact content of business, data, and technology includes a metamodel). models which would enable their interconnection. Likewise, the National Association of State Chief Information Officers (NASCIO) architecture Of the publicly available frameworks, the DoDAF framework (NASCIO, 2004) also focuses on the is the most precise in terms of the information methodology and includes governance. Of these content needed to support EA. By defining both frameworks, only the DoDAF specifies the a product set and its underlying data model, the precise information content of conforming CADM, the DoDAF points to a critical element architecture descriptions. that has yet to be fully realized within the EA discipline. The underlying data model for EA DoDAF prescribes information content by content, or metamodel, is critical for defining defining the data content of specific architecture both information content and interrelationships work products in terms of its underlying Core among architecture work products. The term, Architecture Data Model (CADM). Many of the “metamodel” will be used in this article to DoDAF products are model-based including distinguish the data model for EA content from business process, data, and technical solution enterprise-specific data models to be found functions. Other DoDAF products are inventories within that EA content. of information some of which is available from the models. Additional products represent the Bernard’s (2005) Enterprise Architecture Cube results of analysis combining content from other Framework (EA3), as an evolutionary products. descendant of DoDAF, EAP, and Zachman, addresses information content, the evolutionary Reference models, such as the Federal nature of EA as driven by strategic planning as Enterprise Architecture (FEA) Reference Models well as technological change, and the (OMB, 2007B) and the Network-Centric importance of security and the workforce in the Operations and Warfare related guidance (see mix. Many of the artifacts described in EA3 are DISA) provide additional scope and focus to based on similar DoDAF products. EA3 does their respective domains. In the communities to not, however, adopt the CADM or specify an which these reference models apply, the underlying data model for architecture work reference models provide common terminology products. This article describes an initial version and organization to extremely broad enterprises. of an EA3 Metamodel. The common ground that these reference models provide will help to ensure coherent evolution among independent enterprises within PROBLEM STATEMENT communities. In the absence of a standard, prescriptive, and

rigorous definition of the work products that Other guidance, including The Practical Guide to represent EA content, organizations must create the FEAF (Thomas, 2001), the FEA Practice their own. Without one, individual architects and Guidance (OMB 2007a), and the Federal engineers will generate models and other ad hoc Segment Architecture Methodology (FSAM) content using the tools and techniques with (CIO Council, 2008) builds on the foundation which they are most familiar, or to which they provided by frameworks and enhances their have easy access. In the worst case, meaning and value. organizations will find their EA content to be ill-

defined and un-integrated. An enterprise in All of these frameworks and associated which more than one organization participates guidance have contributed to a growing body of will have the same problems multiplied by the knowledge and experience concerning EA number of organizations involved. Ill-defined and development and use. All are intended to un-integrated EA content impedes support architects in identifying and describing communication, cannot be reliably analyzed, the elements of concern; they help to shape the and cannot be used to support investment conversation about those elements. All of them

© Journal of Enterprise Architecture – February 2009 50 decision making. When organizations enter new Business Process Modeling Notation (BPMN) collaborative arrangements driven by mergers, allows an activity in a BPMN model to be new business initiatives, or changes in mandate, associated with data objects defined in that ill-defined EA content offers little or no value to same BPMN model. To integrate the process investment decision-makers, solution planners, model with a relevant supporting data model, the or designers. Ironically, an EA program can re- BPMN data objects must somehow be create exactly the kinds of problems within its connected to entities or classes in a separate own work products that it purports to help data model. A new relationship type must be resolve for the business and IT communities: un- created in the metamodel to provide that integrated, un-interoperable work products, connection between BPMN models and Entity- redundant data, and unreliable results. Relationship or other types of data models. Similarly, activities represented in a BPMN Not only must organizations identify the content model may be supported by human-machine of models and other work products that define interactions. New relationship types are needed their EA content, they also need to establish the to connect the activities to model components types of interrelationships needed among the describing the supporting tools or applications. work products so that they can be integrated. These inter-model relationships are analogous Integration among models allows architects to to the interrelationships between business and capture and reflect the complexity inherent in the IT that EA is intended to identify and strengthen, EA content. Integration allows architects to or create within the enterprise. identify and to make explicit the issues arising from a lack of integration among actual business Additional benefits of an EA metamodel include processes, data, and technical solutions. improved clarity in communication among EA Alignment, via interrelationships among model team members. The EA team can communicate components of different categories of concern better with business owners based on a deeper (known as views in the DoDAF), enables understanding of the information being collected, architects to demonstrate the presence or modeled, and analyzed. The metamodel clarifies absence of integration within the enterprise. The the expectations to be met by EA content ability, for example, to link performance goals to developers and providers, and establishes the business activities, roles, information flows, scaffolding for EA content. Architects can derive applications, and infrastructure that support consistency and completeness criteria from the achieving those goals enables valuable metamodel to evaluate and improve model communication among architects and business quality. The increased rigor in EA content owners who make investment and technical supported by a well-defined metamodel enables solution decisions. automated analysis to answer predictable business questions. Finally, a metamodel Modeling tools employ metamodels for well- facilitates mapping EA content to reference known modeling formalisms such as those in the models or other frameworks for reporting, Unified Modeling Language (UML) (OMG, 2007) training, or content conversions. and UML-based profiles such as SysML (OMG, 2008), various structured methodologies based on data flow concepts such as IDEF-0 (NIST, APPROACHES TO 1993), structured analysis, and methodologies DEFINING A METAMODEL that support object oriented analysis and design. In the abstract, a metamodel consists of Most tools support integration among the concepts and their interrelationships. A models they produce by enabling explicit metamodel, for an actual EA, must specify how relationships among their components. Many the EA concepts and interrelationships are products also support user-defined extensions to represented. For many organizations, much of their data models as well as to their analysis and the metamodel may be determined by the reporting capabilities. environment. A framework and one or more tools may already be in place. Defining an Useful integration among EA work products explicit metamodel can help to unify an EA requires an understanding of the metamodels program and can provide the benefits outlined underlying the modeling formalisms to be used previously. and insight into the relationships that will integrate them. For example, the metamodel for

© Journal of Enterprise Architecture – February 2009 51 As an example, a Zachman-based framework layers representing business, data, and defines categories of stakeholder concerns applications. The core metamodel concepts (owner, planner, designer) in its rows, and within a layer can be identified by bottom-up interrogatives (what, how, where, when, who, analysis of existing tool capabilities or of existing why) through its columns. The row-column reporting obligations. An alternative is a top- intersections (cells) imply the concepts (things down conceptual analysis based on stakeholder produced, data managed, business processes concerns and information needs. Once the per- performed). Within a cell, one or more modeling layer metamodel is established, specific formalisms can usually support content business questions can be examined to identify representation, but relationships between the kinds of inter-layer relationships that can be concepts in different cells are not addressed by used to answer them. the framework. Bottom-Up Approach Unfortunately, it is exactly those relationships A bottom-up approach to developing the that need to be exposed to demonstrate metamodel could use a combination of reporting integration (or its absence) within the enterprise. needs and tool capabilities. Essentially, a For example, content for the “owner/what” cell bottom-up approach tries to match information can be supplied by any number of data modeling needs with available data. Additional data needs tools that support conceptual or semantic can be met as required. In many organizations, models. The “designer/how” cell content can be regular reviews of program and enterprise supplied by tools that support business process performance are based on whatever is of modeling (IDEF0, BPMN, or UML Activity interest to leadership and oversight models). Relationships between a process and organizations. The information needs of such the data it uses or generates are not reviews provide clues to help identify the represented in either cell. Other missing important business questions to be answered. In relationships include those between the process the public sector, for example, program and the technical solutions that support it, the effectiveness and budgets are common areas of components of the workforce that perform it, and concern that are rich in reporting obligations. the organizational goals that it supports. A metamodel based on this framework would be Measures of effectiveness can be derived from completed with specifications of those missing analyses of business models, defined as model relationship types, the entities and relationships elements, and built into data collection defined by desired modeling formalisms, and the mechanisms. Data management and tools to be used to produce conforming content, manipulation capabilities in modeling tools also and a way to manage all of the model data. provide clues to practical metamodel development. A first consideration is the data A metamodel definition encompasses: that the tools produce. Then, how is that data useful? Does it, or can it be made to relate to • a set of layers or categories of concern as other models produced by different tools? Are defined by a framework (such as strategy, there conventions or more automated business, data and applications) mechanisms that could enable this data to be • the concepts pertinent to each layer (such reused? as goals, objectives, and initiatives for the strategy layer) Many modeling tools provide some sort of • the interrelationships among the concepts interface including scripting languages or that populate each layer (such as “objective import/export capabilities to provide users helps meet goal” or “initiative fulfills access to model content. Many tools support objective”) multiple modeling formalisms and support integration among the models they produce. • the interrelationships that connect concepts UML tools, for example, support many different in different layers (such as business process kinds of models, and are designed to support “supports” goal, or entity “produced” by data-level integration among related models. process) Such support enables modelers to create models that share data elements, thus enabling Although the frameworks cited earlier differ in a model element to be defined once yet be many details, they all include categories or usable in different contexts.

© Journal of Enterprise Architecture – February 2009 52 many pieces of information useful to workforce Top-Down Approach training staff and other stakeholders interested A top-down approach to metamodel definition in institutional knowledge capture, harvesting, could derive metamodel relationships based on and use. analyses of the concepts and relationships embodied in stated principles and goals and A purely bottom-up approach can cover embedded in the information needs of EA foreseeable EA content needs, but may miss stakeholders. For example, a frequently-stated considering unforeseen needs that may emerge goal of EA is to improve IT support for business in the future. An entirely top-down approach may needs. Related concepts include business produce more satisfactory coverage, but risks processes, their information flows, requirements overkill by covering too much, specifying a too- for information retention, and process cycle time. capable solution that may be costly to develop Investment decision makers are interested in and hard to maintain. A hybrid approach is comparing proposed technical solutions in terms probably best to help meet foreseeable of how well they meet the business requirements with a comprehensive solution that requirements that drive these and similar can be extended as unforeseen needs emerge. concepts.

To identify additional business questions that A BASIC METAMODEL FOR THE expose metamodels concepts and relationships EA3 ARCHITECTURE FRAMEWORK through all EA layers, it could be helpful to st consider the roles that EA fills in supporting The initial publication of the EA3 Framework (1 various classes of EA stakeholder, particularly edition - Bernard, 2004) did not define a those that also bridge the mission-IT gap, metamodel or prescribe artifact content in detail. including: Artifact content and examples were added in the second published edition of the EA3 Framework Capital Planning and Acquisition - EA often (Bernard, 2005) including 46 artifacts that provides or supports analyses of alternatives for document the five layers and the three thread new or to-be-enhanced IT investments. areas. Though the relationships between the Supporting content includes assessments of layers and threads were described in the 2nd gaps (such as interoperability, performance, or edition of the EA Framework, this case study functional) and duplications among existing article provides the first detailed meta-model. assets. The proposed EA3 Metamodel that is described IT Strategic Planning - EA can provide hereafter in a conceptual and diagrammatic form supporting detail for strategic IT initiatives during was developed to support the use of the EA3 their planning and execution. approach by the author within a federal Solution Designers and Developers - EA often government agency using a bottom-up approach supports business owners in developing based on tool capabilities and reporting business processes, rules, and requirements for obligations. The basic metamodel described new business activities. here has been implemented using a commercially-available modeling toolset, and Continuity of Operations (COOP) and Disaster required no tool customization. Recovery planners - While supporting business owners, EA can help them to identify and Reporting obligations for the agency in which separate essential from non-essential business this metamodel has been used include functions and their corresponding infrastructure information required by the federal budget needs to help with planning for undesirable process (OMB, 2008b), an EA assessment events. process (OMB, 2008a), mission performance Auditors - EA can meet the information needs of assessment (PART), financial management external data calls, and help to fulfill specific reporting (OMB, 2004 and 2009) and IT Security criteria embodied in security, financial reporting (OMB 2000). The budget process management, and mission effectiveness focuses on investments and the related assessments. reporting requirements including information about IT services used or produced, and Other Stakeholders - While exploring business performance measures of associated initiatives. level needs, EA practitioners are able to identify EA assessment is focused on the architecture’s

© Journal of Enterprise Architecture – February 2009 53 completeness, utilization for performance improvement, capital planning, and IT Strategic Goals and Initiatives Layer governance. Mission performance assessment In the EA3 Metamodel, the Strategic Goals and measures the effectiveness of agency programs Initiatives layer contains information from the against their statutory requirements. work products of strategic planning and performance measurement planning. Complete Overview of the EA3 Framework EA3 Strategic Goals and Initiatives artifacts such The EA3 Framework has five major sub- as the Strategic Plan or Concept of Operations architecture areas that are referred to in this are not explicitly represented in the strategy article as layers. Each layer is focused on a layer. Instead, elements of those artifacts, specific set of concerns and encompasses especially elements of the S-1 Strategic Plan, several artifacts that describe the concerns of are collected and interrelated using the concepts the layer. The layers defined in the EA3 described below and illustrated as entities or Framework are: classes in Figure 1.

• Strategic Goals and Initiatives • The Strategic Goals and Initiatives layer • Business Products and Services concepts include: • Data and Information • Strategic Goal – a statement of • Systems and Applications organizational intent. • Networks and Infrastructure • Objective – an achievable, measurable There are also three “threads” that affect and increment of progress towards fulfilling one involve all five of the sub-architecture layers: or more strategic goals.

• Security • Initiative – a project or program to be • Standards executed to meet one or more objectives. • Workforce • Investment – a business case, budget, and related items needed to execute one or Each layer and thread is described briefly the more initiatives. following section in terms of its conceptual basis, • Performance Measure – a quantifiable the EA3 products or artifacts supported in the indicator applied to one or more initiatives metamodel, and the related portions of the that helps the organization to determine the metamodel. Not all of the EA3 products are extent to which its investments are properly visible in the metamodel as described below. supporting its initiatives and the extent to The subset of artifacts that is included was which the initiatives are effective in chosen to meet a design goal of avoiding tool achieving objectives to meet goals. customization whenever possible. Future versions of the metamodel may include additional products.

supportedBy / supports Strategic Goal

supportedBy / supports Objective

measuredBy / measures supportedBy / supports Initiative

Performance Measure Investment

Figure 1. EA3 Strategic Goals and Initiatives Layer Concepts and Interrelationships

© Journal of Enterprise Architecture – February 2009 54 Strategy Layer concepts can be related to • B-2 Node Connectivity Diagram – concepts in other layers. Some relevant implemented as simple node objects with examples include: interconnections to represent needlines (a needline is an abstraction of one or more • A Strategic Goal or Objective can be information exchanges between nodes). assigned to a Workforce Layer • B-3 Swim Lane Process Diagram – Organizational Unit. implemented using tool support for Business • An Investment can be managed by a Process Modeling Notation (BPMN) or UML Workforce Layer Organizational Unit. activity models. • An Initiative, Investment, or Performance • B-4 Business Process/Service Model – Measure can be mapped to business layer implemented as a hierarchy of process concepts which it supports. areas in which leaf-level nodes correspond • A Performance Measure can be mapped to to BPMN models. a measurement plan or an external model • B-5 Business Process/Product Matrix – such as the FEA Performance Reference implemented as a matrix mapping Model. processes to persistent data objects or information products, with matrix cells Business Layer indicating input and output relationship The EA3 Framework’s Business Layer types. encompasses business processes and the flow of information to and from external stakeholders and within the organization. The EA3 artifacts at the Business Layer which are supported by the metamodel proposed in this article include:

Includes / IncludedIn

HasLeaf / ChildOf Process Area

Business Process HasInput / UsedBy Includes / IncludedIn HasOutput / ProducedBy

PerformedBy / Performs Activity Receives / ReceivedBy Role

Sends / SentBy RespondsTo / ImportantTo Contains / ContainedIn Data Object Causes / CausedBy

Event Contains / ContainedBy Info Exchange Implies / ImpliedBy

Needline

Source / SourcedBy Business Node Sink / SinkedBy

Figure 2. EA3 Metamodel Business Layer Concepts

© Journal of Enterprise Architecture – February 2009 55 The concepts embodied in these Business Layer Data Layer artifacts include: The EA3 Data Layer includes conceptual, logical, and physical representations of the • A “Process Area” represents a collection of persistent information managed by the Business Processes. The set of Process enterprise. There are explicit connections to Areas for the enterprise represent a both the Business and Systems and taxonomy of business functions for the Applications Layers. enterprise. • The “Business Process” is a set of activities, EA3 data artifacts currently supported in the events, roles, inputs, outputs which may use EA3 Metamodel include: and produce data or information and may • depend on the use of applications. D-2 Information Exchange Matrix – mapping needlines to sending and receiving process • “Information Exchanges” are flows of activities and supplying additional attributes information between activities within or such as frequency, format, and between business processes which may security/privacy requirements. cross organizational boundaries. • D-5 Logical Data Model – identifying the • Persistent “Data Objects” are those which entities/classes, their attributes, and are produced and used by activities which relationships are retained by the enterprise. • D-6 Physical Data Model – identifying the • A “Business Node” in the B-2 Node mapping of logical data model components Connectivity Diagram represents a collection onto relational or other data management of Activities and connects to other nodes via technologies. Needlines.

• A “Needline” in the B-2 Node Connectivity Data Layer concepts include: Diagram represents a collection of Information Exchanges. • Entity (class) – a category of data to be managed that typically has inherent aspects Business Layer concepts can be related to to be managed as attributes. concepts in the Strategy, Data, and Systems • Attribute – a property of an entity (class) and Application Layers as follows: such as name, size, color. • Relationship – an explicit connection • A Process Area can be the responsibility of between entities or classes. an Organizational Unit from the Workforce • Table – a physical data model Layer. component in which entities or relationships • A Process area can be the focus of a are stored. Strategy Layer Investment or Performance • Column – a component of tables used to Measure. house attribute values. • A Process Area can be mapped to an Has / PartOf external model such as the FEA Business Attribute Reference Model. ParticipatesIn • A Role can be mapped to one or more Entity Relationship Organizational Units or Positions from the

Workforce Layer. AppearsIn / Contains • An Activity can be mapped to supporting application(s) from the Systems/Applications Layer. AppearsIn / Contains Table • An Information Exchange is represented in a D-2 Information Exchange Matrix in the Data Layer. Includes Column • A Data Object (in a BPMN model) can be described by one or more Data Layer Figure 3. EA3 Metamodel Data Layer Concepts classes or entities.

© Journal of Enterprise Architecture – February 2009 56 Data layer concepts can be related to Business System Layer and System Layer concepts in the Contains / ContainedIn following ways: Sends / SentBy

• Entities can be contained within Data Receives / ReceivedBy Application Data Flow Objects defined in the Business Layer. • Entities can be included in or mapped to the Uses / UsedBy Enterprise Data Models based on the FEA Solution Data Reference Model. Component

• Tables can be managed by Applications. Figure 4. EA3 Metamodel System/Application Layer Concepts Systems and Applications Layer The Systems and Applications Layer contains information which describes function, structure, Concepts in the Systems and Application Layer and organization. can be related concepts in other layers as follows: EA3 systems and application artifacts currently supported in the EA3 Metamodel include: • Applications and Systems can be provided by Investments that are defined in the • SA-1 System Interface Description Strategy Layer. illustrating logical or physical • interconnections among systems or Applications can be used by Activities in the applications. Business Layer. • • SA-2 System Communications Description Applications can manage data in Tables augments the SA-1 with specific defined in the Data Layer. communications technology assignments. • Applications and Systems can be hosted on • SA-3 System-System Matrix identifies the platforms in the Networks and Infrastructure status of planned or existing interfaces layer. among systems or applications. • Solution Components can be dependent • SA-4 System Data Flow Diagram upon or built using technologies identified in decomposes systems into applications and the Standards Layer. applications into communicating functions. Networks and Infrastructure Layer • SA-5 System/Operations Matrix maps The Networks and Infrastructure Layer functions from the SA-4 models to activities documents planned and actual physical from the B-3 models. infrastructure components. The EA3 artifacts supported in the metamodel include: The Systems and Applications Layer concepts include: • NI-1 Network Connectivity Diagram – illustrating physical network connections and • Application – a unit of functionality (which device types in the network. could be available as a service accessible to • other applications or as a traditional NI-2 Network Inventory – enumerating application accessible to humans). actual instances of hardware and software installed on the network. • System – a collection of applications.

• Data Flow – a relationship representing one Networks and Infrastructure concepts include: or more data exchanges among applications. • Device Type – a category of device such as server or router. • Solution Component – a part of an application, system, or data store that may • Device Instance – a specific item of a be managed separately (such as a COTS particular device type such as the desktop product used by one or more applications or PC named “DTXXX123.” systems). • Device Interconnection – a physical connection such as LAN or wireless.

HasInstance / InstanceOf DeviceType Requires / RequiredBy HasInstance / InstanceOf

In / Houses Device

ConnectedTo / Connects Requires / RequiredBy Interconnection Position KSAO Location In / Houses Figure 6. EA3 Metamodel Workforce Thread

Figure 5. EA3 Metamodel Networks and Infrastructure Layer Security Thread The EA3 Security Thread includes security and privacy plans, a catalog of security solutions, Workforce Thread COOP and DR plans, and the security The Workforce “Thread” a major element of the assessment documentation for deployed EA3 framework that affects and involves all five systems and applications. The EA3 Metamodel layers (Strategy, Business, Data, Systems, contains only a security solution description type Networks) describes the structure, organization, corresponding to the SP-2 Security Solutions and skills needs of the enterprise from the Descriptions artifact. Security solution instances human resources perspective. EA3 Workforce represent the security controls identified by the Thread artifacts include: National Institute of Standards (NIST 2009). The metamodel supports relationships between • W-1 Workforce Plan describing an applications and implemented security controls. organization’s plans for hiring, retaining, and developing its workforce. Standards Thread • W-2 Organization Chart depicting the The EA3 Standards Thread identifies relevant reporting structure of the organization. technology standards and their forecasted • W-3 Knowledge and Skills Profile mapping evolution as it pertains to the enterprise needs. positions within the Organization Chart to Only the ST-1 Technology Standards Profile is required levels of knowledge, skills, abilities, supported in the metamodel at this time using a and other qualifications. relationship between solution components in the Systems and Applications layer and technologies in the Standards Thread. Workforce Thread concepts include:

• Organizational Unit. • Position. METAMODEL USE AND FUTURE PLANS

• Knowledge, Skill, Ability, or Other As indicated earlier, the EA3 Metamodel has Qualification (KSAO). been in use for just under a year at one federal agency. A full view of the metamodel with Workforce Thread concepts may be related to mappings to the EA3 artifacts that are at least many concepts in the Strategy and Business partially represented in the metamodel is layers, including: provided in Figure 7 on the next page.

• Organizational Units may be assigned Although the metamodel is often invisible to responsibility for specific strategic goals, most EA stakeholders, it is the basis for objectives or initiatives, and may manage organizing “composite” (Zachman, 1989) specific investments artifacts such as “storyboards” that provide a • Positions may fulfill roles described by comprehensive view of an organizational service the activities they perform in the Business from a business process, data exchange, and Layer. infrastructure viewpoint.

supportedBy / supports S-2 SWOT Analysis Objective

S-2 Concept of Operations Scenario S-3 Concept of Operations Diagram measuredBy / measures supportedBy / supports Initiative S-5 Balanced Scorecard Performance Measure

B-1 Business Plan Includes / IncludedIn W-1 Workforce Plan

B-2 Node Connectivity Diagram Investment W-2 Organization Chart Process Area B-3 Swim Lane Process Diagram HasLeaf / ChildOf W-3 Knowledge and Skills Profile B-4 Business Process/Service Business Process Model Includes / IncludedIn B-5 Business Process/Product Matrix B-6 Use Case Narrative & Diagram PerformedBy / Performs B-7 Investment Business Case Business Node Role Sink / SinkedBy Performs / PerformedIn

Source / SourcedBy D-1 Knowledge Management Plan RespondsTo / ImportantTo Needline Activity D-2 Information Exchange Matrix Causes / CausedBy D-3 Object State-Transition Implies / ImpliedBy HasOutput / ProducedBy Diagram Sends / SentBy HasInput / UsedBy D-4 Object Event Sequence Diagram Event D-5 Logical Data Model Data Object Contains / ContainedIn Information Contains / ContainedIn Exchange D-6 Physical Data Model Receives / ReceivedBy Organizational D-7 Activity/Entity CRUD Matrix Unit Requires / RequiredBy

D-8 Data Dictionary / Object Library Contains / ContainedIn System

Requires / RequiredBy Sends / SentBy SA-1 System Interface Diagram Position KSAO Receives / ReceivedBy SA-2 System Communication Application Data Flow Description

SA-3 System Interface Matrix Uses / UsedBy Solution Component SA-4 System Data Flow Diagram ST-1 Technical Standards Profile

SA-5 System/Operations Matrix ST-2 Technology Forecast

SA-6 System Data Exchange Matrix

SA-7 System Performance Matrix Technology Security Control Uses / UsedBy SA-8 System Evolution Diagram Product SP-1 Security and Privacy Plan SA-9 Web Application Diagram SP-2 Security Solutions Description HasInstance / InstanceOf SP-3 System Accreditation NI-1 Network Connectivity Diagram Device Type Document NI-2 Network Inventory SP-4 Continuity of Operations Plan HasInstance / InstanceOf NI-3 Capital Equipment Inventory SP-5 Disaster Recovery Procedures Device In / Houses NI-4 Building Blueprints ConnectedTo / Connects Interconnection NI-5 Network Center Diagram Location In / Houses NI-6 Cable Plant Diagram

NI-7 Rack Elevation Diagram

Figure 7. Mapping the EA3 Metamodel to Selected EA3 Artifacts

The EA3 Metamodel that has been described in Bernard, S. (2004). An Introduction to Enterprise this case study was developed to enhance the Architecture (1st ed.). Authorhouse, use of the EA3 Framework and associated Bloomington, IL. 2005. artifacts at a federal agency in the U.S. Government. The EA3 Metamodel has already Bernard, S. (2005). An Introduction to Enterprise been implemented and was able to be Architecture (2nd ed.). Authorhouse, Bloomington, IL. 2005. supported with commercially-available tool set, which reflects one of the initial design goals for CIO Council (1999), “Federal Enterprise the metamodel, which was to avoid tool Architecture Framework, Version 1.1”, Chief customizations. With a sufficiently feature-rich Information Officers Council September, 1999. tool set, meeting this goal has not been difficult. Available online Further evolution of this metamodel, however, at http://www.cio.gov/documents/fedarch1.pdf. will drive tool customization to define additional concept and relationship types to support a CIO Council (2008). “Federal Segment more robust subset of the EA3 framework’s Architecture Methodology”. Chief Information artifacts. Others changes that are envisioned Officers Council September, December, 2008. include enhanced analysis and reporting Available online at http://www.fsam.gov. capabilities. Defense Information Systems Agency - DISA. Various guidance on net-centric operations and EA content is the information that fuels the warfare. Available online evolution engine for an enterprise. As a at http://iase.disa.mil/policy- discipline, EA is evolving and maturing. More uidance/#netcentricity. innovation is needed to help organizations adopt and adapt so that they may more easily treat EA DoDAF (2007), “DoD Architecture Framework content development and maintenance with as Version 1.5” United States Department of much rigor as any other engineering project. Defense, 2007. Specific innovations needed include better tool NASCIO (2004). “Enterprise Architecture support for integrated models and extensible Development Tool Kit v 3.0” National metamodels. Additional standardization of Association of State Chief Information Officers, concepts and improved modeling formalisms October 2004. Available online could also help make EA development easier at http://www.nascio.org. and the resulting architectures more powerful. EA content must be accurate, precise, and well- NIST (1993). DRAFT Federal Information integrated to fully realize its mission to support Processing Standards Publication 183. 1993. decision making by leadership, business, and Withdrawn in 2002. Available online engineering components within the enterprise. at http://www.itl.nist.gov/fipspubs/idef02.doc. Metamodels encourage precision and NIST (2009). “Recommended Security Controls integration in EA content, which in turn supports for Federal Information Systems and improved communication, analysis, and Organizations”, NIST Special Publication 800-53 defensible decision-making. Revision3 Initial Public Draft, National Institute of Standards, US Department of Commerce. February 2009. Available online AUTHOR BIOGRAPHY at http://csrc.nist.gov/publications/PubsSPs.html.

Lyn Uzzle is a practicing senior enterprise OMB (2000). Management of Federal architect with Citizant, Inc., a government Information Resources, Circular No. A-130, solutions provider with Enterprise Architecture, Transmittal Memorandum No. 4, Appendix III, Program Management, and Application Security of Federal Automated Information Development expertise, headquartered in Resources, Office of Management and Budget, Chantilly, VA. She currently supports enterprise November 28, 2000. Available online architecture engagements with federal and at http://www.whitehouse.gov/omb/circulars_default. defense agencies. Lyn Uzzle can be reached at [email protected]. OMB (2004). “Management’s Responsibility for Internal Control”, Circular No. A-123, Office of Management and Budget, December 2004.

© Journal of Enterprise Architecture – February 2009 60 Available online PART, Performance Assessment Rating Tool at http://www.whitehouse.gov/omb/circulars_default. web site, Office of Management and Budget. Available online OMB (2007a), “Federal Enterprise Architecture at http://www.whitehouse.gov/omb/part/. Practice Guidance”, Federal Enterprise Architecture Program Management Office, OMB, OMG UML (2007). “Unified Modeling Language, November 2007. Available online Version 2”. The Object Management Group at http://www.whitehouse.gov/omb/e-gov/fea 2007. Available online at http://www.omg.org OMB (2007b). “Federal Enterprise Architecture OMG BPMN (2009). “Business Process Consolidated Reference Model Version 2.3”, Modeling Notation, Version 1.2. The Object Federal Enterprise Architecture Program Management Group, January 2009. Available Management Office, OMB, October 2007. online at http://www.omg.org Available online OMG SysML (2008). “OMG Systems Modeling at http://www.whitehouse.gov/omb/e-gov/fea. Language (OMG SysML) Version 1.1”, The OMB (2008a), “Improving Agency Performance Object Management Group, November 2008. Using Information and Information Technology Available online at http://www.omg.org. (Enterprise Architecture Assessment Framework Spewak, S. (1992). Enterprise Architecture v3.0)” Federal Enterprise Architecture Program Planning: Developing a Blueprint for Data, Management Office, December, 2008. Available Applications, and Technology. Wiley & Sons. at http://www.whitehouse.gov/omb/e-gov/fea. Thomas, R. et al (2001). A Practical Guide to OMB (2008b), “Preparation, Submission, and Federal Enterprise Architecture. Federal CIO Execution of the Budget”, Circular A-11, Office Council. Available online of Management and Budget, June 2008. at http://www.cio.gov/documents/bpeaguide.pdf. Available online at http://www.whitehouse.gov/omb/circulars_default TOGAF (2009). The Open Group Architecture Framework, version 9. Available online OMB (2009), “The Federal Financial at http://www.opengroup.org. Management Improvement Act of 1996 OMB Implementation Guidance”, Office of Zachman, J. (1989), “A Framework for Management and Budget, January 2009. Information Systems Architecture” IBM Systems Available online Journal. Volume 26, Number 3, 1987. at http://www.whitehouse.gov/omb/assets/agenc yinformation_memoranda_2009_pdf/m09- 06.pdf.