What is an Enterprise Architecture?
There are a variety of definitions for an enterprise architecture. However, a general description might define an enterprise architecture as a framework that results in the production of a set of documents that define the enterprise. The enterprise architecture information collected includes the core mission areas, goals, principles, business capabilities/functions and processes. In addition, business solutions and technology are planned and implemented to support business capabilities and processes--no business decisions are made on a whim. A properly defined enterprise architecture should, at a minimum, provide information that allows an enterprise to do the following:
1. Purchase the right tools and maximize their use through stated needs, services provided by the business, strategic objectives, etc.
2. Understand shared services/processes to request and purchase tools that are implemented for the greater good.
3. Identify opportunities for process improvement to resolve bottlenecks (through automation or process re-engineering), retire redundant systems, identify and resolve threats and risks, and maximize opportunities.
EA Resources
Enterprise architecture is a topic that many organizations (federal, commercial and non-profit) have touched on. A few of the resources available online are listed below:
- The Federal Segment Architecture Methodology (FSAM) - FSAM includes a toolkit developed by the federal government. It provides steps along with the inputs/outputs to be collected and documented for each step. FSAM also provides templates to plan the project and document information collected from requirements gathering sessions. The templates also provide direction to define the target enterprise architecture. FSAM includes insight on recommended analytical activities and useful matrices that should be created.
- Federal Enterprise Architecture (FEA) Practice Guide - The FEA Practice Guide can be used to learn about segment architecture including what a segment architecture is, how to define a segment architecture and who should be involved in the project. It provides the ability to understand (at a high level) the steps that should be used to understand the agencies business problems, needs, strengths & weaknesses, etc. The guide presents understandable, best practices that provide the direction needed to implement an architecture in a way that supports federal government-wide initiatives including data sharing.
- Department of Defense Architecture Framework (DoDAF) - The DoDAF website provides a wealth of information for anyone seeking to gain expertise in defining a framework for a Department of Defense agency. It outlines the models that should be created; the roles needed to define and implement the DoDAF; specifications and matrices to be created; along with the level of detail that should be captured.
The above list is far from all inclusive; however, it does present enough information for even a novice IT professional to conclude that EA is a hot topic. Organizations that accurately define their enterprise architecture and use the information to make decisions will save money and operate efficiently.
Segment Architecture
As previously mentioned, the FEA Practice Guide provides an overview of EA concepts. But most importantly it provides best practices for implementing a segment architecture. It references the FEA Consolidated Reference models and how the BRM is used to define the core mission areas (vertical segments) and the supporting business services (horizontal segments) and enterprise services implemented across the agency to improve collaboration, knowledge, etc. The FEA Consolidated Reference Models are discussed in the following section.
FEA Consolidated Reference Models
The FEA framework includes 5 key models. These models include the Business Reference Model (BRM), the Performance Reference Model (PRM), the Service Component Reference Model (SRM), the Data Reference Model (DRM) and the Technical Reference Model (TRM).
The BRM provides four levels, enabling enterprise architects to break the agency into segments by navigating from the BRM Business Area (pertaining to Services for Citizens) to the LoB to the lowest-level sub-function (or segment). The Mode of Delivery component enables agencies to map the delivery mechanism. For example, the "General Retirement and Disability" would map its Mode of Delivery to (205) Federal Financial Assistance: 081: Direct Transfers to Individuals.
Not all agencies have segments under Services for Citizens. GSA, for example, will not map LoBs to the Services for Citizens Business Area since their customers are federal government agencies. However, most other agencies will find the sub-functions needed.
The BRM also includes the Support Delivery of Services Business Area and the Management of Government Resources Business Area. These two business areas are for agency support LoBs. Both are used to identify business services supplied across the enterprise. The business services are listed horizontally while the Services for Citizens segments are listed vertically. This provides a tool architects use to identify LoBs that perform the same business functions. For example, an agency may have LoBs to manage policy for Health Care, a separate LoB manage policy for Business Industry Development and Conservation, and different LoB manage policy for Marine and Land Management. Collecting information about the business functions helps identify policy work the LoBs do that is the same. This enables stakeholders to agree on one target process to do the same work the same way. And, the stakeholders can agree on a single system to support the work. This one act helps streamline business operations. Hence, all three groups are not separately managing processes with each making changes to the process when change is required. Instead, one LoB manages the process, makes the change and provides the updated process to all LoBs.
Once the BRM sub-functions are identified; they can be used as segments to map the segment architecture data--starting with the business architecture components. The business functions performed by the segment; and, the business processes used all provide a picture of how the work is currently done. However, the business problems stated point out that improvement is needed. If an industry best practices analysis was performed--a look at the principles, practices and tools adopted by "top performers" is insightful. Hence, the EA team already has ideas on what the "target" business architecture should look like.
Service Component Reference Model
The Service Component Reference Model (or SRM) provides a tool to define reusable software components without referencing a technology. This enables agencies across the entire federal government to define components that would ultimately enable them to share more than just data. When building a model from which to categorize the organization, the SRM presents the categories that can be listed as Enterprise Services. Architects can then easily identify services to be implemented across the entire enterprise.
The SRM is also used to define reusable software components. A list of software is used to break down the business applications into a list of reusable software components. The related capabilities are also added and associated with the supported business functions. Once the list is completed, a matrix is developed. The matrix shows the software components that provide the same capabilities. Agencies can then eliminate costs by decommissioning redundant systems. In addition, the tool can be used for governance. As change requests are received, the capabilities requested can be queried against the software component capabilities data-source. If a match is found, the Governance Board can then request further justification as to why duplicate capabilities are being requested.
The Data Reference Model (or DRM) provides a tool that is used to classify data. The primary objective of the DRM is to provide a framework that allows data to be shared across an agency or with a Community of Interest. The DRM calls for data to be classified by Subject Area and Information Class. Once the data is standardized and organized, it can then be reused and shared. To share the data, the Data Description (or Entity) is associated with a Data Exchange Package (DEP) that includes not only the data; but also relevant information such as header/trailer information specific to the data (or payload). In addition, provider/consumer information and interface that will access the data is also provided. Documenting the data includes associating it with the relevant information system(s) and segment(s).
Until the Technical Reference Model (or TRM) is used; the SRM is not associated with any technology. However, to reflect the true enterprise; the service components must be related to technology. The TRM provides the ability to describe technology-specific components that may include code-behind classes (i.e., Visual Basic .Net (VB.Net), Active Server Pages .Net (ASP.Net), etc.) the service; but also the technology used to deliver the service. Business logic services can be described as Enterprise Java Beans (EJB), Web Services for Remote Portals (WSRP), etc. Data access layer data providers, relationship to mechanism presentation delivery--whether it be a web browser or other mechanism. The technology is also associated with the segment to provide a complete picture of the technologies providing the support.
Business Reference Model
The BRM provides four levels, enabling enterprise architects to break the agency into segments by navigating from the BRM Business Area (pertaining to Services for Citizens) to the LoB to the lowest-level sub-function (or segment). The Mode of Delivery component enables agencies to map the delivery mechanism. For example, the "General Retirement and Disability" would map its Mode of Delivery to (205) Federal Financial Assistance: 081: Direct Transfers to Individuals.
Not all agencies have segments under Services for Citizens. GSA, for example, will not map LoBs to the Services for Citizens Business Area since their customers are federal government agencies. However, most other agencies will find the sub-functions needed.
The BRM also includes the Support Delivery of Services Business Area and the Management of Government Resources Business Area. These two business areas are for agency support LoBs. Both are used to identify business services supplied across the enterprise. The business services are listed horizontally while the Services for Citizens segments are listed vertically. This provides a tool architects use to identify LoBs that perform the same business functions. For example, an agency may have LoBs to manage policy for Health Care, a separate LoB manage policy for Business Industry Development and Conservation, and different LoB manage policy for Marine and Land Management. Collecting information about the business functions helps identify policy work the LoBs do that is the same. This enables stakeholders to agree on one target process to do the same work the same way. And, the stakeholders can agree on a single system to support the work. This one act helps streamline business operations. Hence, all three groups are not separately managing processes with each making changes to the process when change is required. Instead, one LoB manages the process, makes the change and provides the updated process to all LoBs.
Once the BRM sub-functions are identified; they can be used as segments to map the segment architecture data--starting with the business architecture components. The business functions performed by the segment; and, the business processes used all provide a picture of how the work is currently done. However, the business problems stated point out that improvement is needed. If an industry best practices analysis was performed--a look at the principles, practices and tools adopted by "top performers" is insightful. Hence, the EA team already has ideas on what the "target" business architecture should look like.
Performance Reference Model
The PRM includes performance measurement areas, measurements categories and measurement groupings that map to the BRM LoB segments. Agencies must define the indicators that will be used to measure performance for the IT Investment/Program, etc.Service Component Reference Model
The Service Component Reference Model (or SRM) provides a tool to define reusable software components without referencing a technology. This enables agencies across the entire federal government to define components that would ultimately enable them to share more than just data. When building a model from which to categorize the organization, the SRM presents the categories that can be listed as Enterprise Services. Architects can then easily identify services to be implemented across the entire enterprise.
The SRM is also used to define reusable software components. A list of software is used to break down the business applications into a list of reusable software components. The related capabilities are also added and associated with the supported business functions. Once the list is completed, a matrix is developed. The matrix shows the software components that provide the same capabilities. Agencies can then eliminate costs by decommissioning redundant systems. In addition, the tool can be used for governance. As change requests are received, the capabilities requested can be queried against the software component capabilities data-source. If a match is found, the Governance Board can then request further justification as to why duplicate capabilities are being requested.
Data Reference Model
The Data Reference Model (or DRM) provides a tool that is used to classify data. The primary objective of the DRM is to provide a framework that allows data to be shared across an agency or with a Community of Interest. The DRM calls for data to be classified by Subject Area and Information Class. Once the data is standardized and organized, it can then be reused and shared. To share the data, the Data Description (or Entity) is associated with a Data Exchange Package (DEP) that includes not only the data; but also relevant information such as header/trailer information specific to the data (or payload). In addition, provider/consumer information and interface that will access the data is also provided. Documenting the data includes associating it with the relevant information system(s) and segment(s).
Technical Reference Model
Until the Technical Reference Model (or TRM) is used; the SRM is not associated with any technology. However, to reflect the true enterprise; the service components must be related to technology. The TRM provides the ability to describe technology-specific components that may include code-behind classes (i.e., Visual Basic .Net (VB.Net), Active Server Pages .Net (ASP.Net), etc.) the service; but also the technology used to deliver the service. Business logic services can be described as Enterprise Java Beans (EJB), Web Services for Remote Portals (WSRP), etc. Data access layer data providers, relationship to mechanism presentation delivery--whether it be a web browser or other mechanism. The technology is also associated with the segment to provide a complete picture of the technologies providing the support.
Federal Segment Architecture Methodology (FSAM)
FSAM provides the guidance needed to develop artifacts in support of a segment architecture project. There is a rapid approach that can be used to shorten the length of time it takes to document the Business, Information, Application and Technology architectures. The FSAM artifacts include fields that request elements from the FEA Consolidated Reference Model for example the Segment Code (taken from the BRM) is requested. The FSAM Business Function Model is based on the BRM structure. The FSAM Service Component model requests the service domain and service type; both elements are taken from the SRM.
Lastly, FSAM includes a logical data model and data dictionary, which can be used to build an EA Repository. UML models can be stored on a shared drive with the Repository providing the path to the model. Alternatively, a tool (see the Federal Enterprise Architecture (FEA) Practice Guide for recommendations) can be used to generate the EA Repository. The FSAM EA Repository, once populated, enables agencies to generate the Exhibit 300 Investments Part 1 Section A, Integrated E-300 Milestones, Integrated Performance Information, AIT Investments (Exhibit 53) as well as Segment, PART and PAR Performance Reports.
Solution Architecture
The Solution Architecture is used to implement individual IT projects. Adopting the Solution Architecture Framework ensures the FSAM artifacts developed remain current and useful. As business applications are updated, the FSAM Service Components model, for example, is used to add the new service components. The Solution Architect works with the EA team to ensure EA-related artifacts (such as updated/new business process swim lanes, use case and activity diagrams, interface diagrams, logical data models, service component diagrams, etc.) are incorporated into the Repository it can serve as a knowledge center and does not become outdated. The Solution Architect also uses the existing FSAM Repository to extract data for IT project documents. For example, the FSAM Risk Capture template provides a list of risks for the segment. Relevant unresolved risks are complied and added to the IT Project Risk List and Mitigation Plan.
n
