Snyders.US

Measureable Results

Successful enterprise architecture will improve the decision-making process for management as a result of performance metrics. For example, tracking the time to respond to customer inquiries before and after a technology deployment project can provide measures of success (or failure). Indicators linked to specific service components mapped to TRM service standards offers additional insight for managers. Consider that the improvement in inquiry response time might be due to enhancements in the user interface, new network infrastructure, a server upgrade, or the purchase of handheld devices. The ability to break-down metrics to specific elements allows for a more comprehensive analysis of IT investments.

Incorporating attributes into the TRM that the enterprise architect and the solution architect will use ensures traceability. It is traceability from the high-level concept to the low-level implementation that allows a Technical Reference Model to become tangible. Tagging specific identifiers in the TRM to services is the most effective indicator of how the technology deployment affected the service delivery.

Reference and Notes

  1. E-Gov, Federal Enterprise Architecture. http://www.whitehouse.gov/omb/e-gov/fea/
  2. Office of Management and Budget, FEA Practice Guidance. Nov 2007.
  3. Office of Management and Budget, FEA Consolidated Reference Model Document, Version 2.3. 2007.
  4. Federal Segment Architecture Methodology Overview, Dec. 2008.
  5. OMB EA Assessment Framework 3.0.

Note how the Technical Reference Model is closest to the point where the enterprise architecture is realized, so this model must be the bridge between the EA and the implementation.

The following list describes an example of how the reference models are interrelated and provide traceability to the strategic objectives of the business case (simplified for this example):    

  1. The Performance Reference Model has indicators for each line of business in the Business Reference Model;
  2. The Business Reference Model Each maps lines of businesses and sub-functions to investment items in the Exhibit 53;
  3. The Service Reference Model maps service components to investment items in the Exhibit 53;
  4. The Technical Reference Model indicates what standard, vendor, and product support service components listed in the Service Reference Model.


Attributes of a Tangible Technical Reference Model

From the top-down enterprise architecture perspective, elements in the TRM must map into IT investments. The ability to trace from the TRM into other FEA reference models facilitates measurement--demonstrating the TRM aligns with the enterprise architecture objectives. Typically, the Technical Reference Model will trace to service types or service components in the Service Reference Model. This traceability is documented in the Exhibit 300 TRM table, where the TRM service standards that support SRM service components are listed. Moreover, the Exhibit 300 requires that vendor and product information from the TRM be mapped to the TRM service standard in the Exhibit 300 “service specification” field.

From the bottom-up solution architecture perspective, the TRM needs to convey what technologies-standards should be implemented in applications and infrastructure. By deploying technologies-standards listed in the TRM, solution architects can demonstrate they are realizing the enterprise architecture. The TRM offers the solution architect applicable rules, guidance, and standards for implementation. Traceability then, occurs from the deployed solution architecture, to the TRM, to the Service Reference Model, to the IT investment in the Exhibit 300.

Just as the viewpoints of business and technology focused stakeholders are opposite, so are the attributes that stakeholders desire in an effective TRM.

The enterprise architect's salient TRM requirements:

  • Information organized in the hierarchy prescribed by the FEA:  service areas, service categories, and service standards.
  • Service standards that reference the three-digit codes prescribed by the FEA Consolidated Reference Model.
  • Mapping of a vendor and a product to the service standard (for the “Service Specification” field in the Exhibit 300).
  • Mapping to cross-agency acquisition initiatives, or to SmartBUY procurements, if applicable.
  • Traceability to the solution architecture.   


The application architect's salient TRM requirements:

  • Information organized in a format that is consistent with solution architectures, (for example the model, view, controller paradigm, or application tiers: business, presentation, data, security, and so on).
  • Archetypes, patterns, and guidance so that implemented designs are consistent with the EA intent.
  • Standardized, consistent technology choices that promote interoperability and reuse. 
  • Technologies that reduce the number of inter-dependencies (coupling) between components.
  • Traceability to the enterprise architecture.  


Traceability is the key element in a tangible Technical Reference Model. Without traceability into the TRM, it becomes difficult to demonstrate achievements at the solution level. Improvements in service delivery or program performance must be measured at a level above the IT implementation--which is ironic given the EA focus on IT investments. Tagging specific TRM standard deployments to services is the most effective indicator of how that technology affected the service delivery.


Recent versions of the reference models provide for the addition of 3-digit codes into the TRM for explicit, unique mapping elements3 (refer to the Consolidated Reference Model version 2.3 for a complete listing of the TRM categories-codes). These codes allow easy mapping between the TRM, other reference models, program or project plans.


The following figure offers an example of how the elements in the TRM become the tangible implementation of the enterprise architecture with traceability. In this illustration, the project needs to deploy services related to all of the elements in the SRM service type: "(731) Content Management". In order to accomplish this implementation, digital certificates need to be acquired, installed, configured and maintained. The solution architect will look to the TRM for technology guidance when realizing this requirement and find applicable rules, guidance, and standards. In this example scenario we see guidance for three acquisition sources (standards) illustrated under the service category: "(884) Certificates-Digital". (The details of the actual TRM listing are obfuscated in the graphic for simplicity).   

The Reference Model Relationships


The FEA consists of a set of interrelated “reference models” designed to facilitate collaboration within and across agencies. The reference models provide a standardized framework (in the context of enterprise architecture) to document, organize, elaborate, and compare the elements of federal agency operations. The FEA is composed of five reference models listed in the following table.


Reference Model
Salient Purpose
Performance Reference Model (PRM)
Measure strategic initiatives
Business Reference Model (BRM)
Provide a functional view of serivces
Service Component Reference Model (SRM)
Classify service components
Technical Reference Model (TRM)
Categorize standards and technologies
Data Reference Model (DRM)
Standardize descriptions-management of data


Anyone with experience completing the Exhibit 53 and Exhibit 300 (in OMB Circular A-11) for a fiscal budget year will recognize the implicit hierarchy in the FEA reference models. The reference models are significant as OMB Circular A-119 (sections 53 and 300) requires Federal agencies to align their IT investments to reference model elements. The Exhibit 300 documents major, program IT investments; the Exhibit 53 documents IT investments at the project level. 

The hierarchical relationships develop as investments are mapped into the reference models for traceability. For example, IT investments must be mapped to the Business Reference Model (BRM), or to the Service Reference Model (SRM)--in each agency's Exhibit 53. The elements described by the Technical Reference Model and the Data Reference Model support the BRM and the SRM. The Performance Reference Model provides metrics (indicators) and measures for the BRM and the SRM line items. These relationships are illustrated in the following figure.


Copyright © Snyders.US. All rights reserved.

Traceability is the key element for a tangible Technical Reference Model.   

Building a Tangible TRM

Results-oriented architecture requires traceable reference models.


John R. Snyder, February, 2009

The development of a Federal Enterprise Architecture (FEA) began in 2002, led by the Office of Management and Budget (OMB). Seven-years into the mission, all Federal agencies have an Enterprise Architecture (EA). But the mere existence of enterprise architecture is not enough, as OMB rates agencies in three specific competencies:


  • Completion of an enterprise architecture;
  • Use of EA to drive improved decision-making; and
  • Results achieved to improve program effectiveness.


Federal agencies need to demonstrate proficiencies in the use of and benefits from enterprise architecture. But in order to demonstrate results, the concepts of EA must be realized in a tangible form at the application level. The focus of this article is how to link the high-level enterprise architecture with pragmatic, outcome-based implementations through the Technical Reference Model.


The Dichotomy

Enterprise architecture is a stepwise progression in the short history of software innovation. Now that enterprise architecture has been established, the next step is to transform it into a results-oriented archetype--some have coined this as "actionable architecture". Enterprise architecture came about as recognition that technology standardization means cost savings. However, there has typically been a schism between the people who create enterprise architecture and the people who realize it; that is, between enterprise architects and software engineers.

The dichotomy is obvious as by definition, enterprise architecture is high-level and conceptual; but the solution architecture must be detailed and tangible. Enterprise architecture is top-down; implementation of the architecture is bottom-up. Enterprise architecture articulates the business case with integrations into the strategic planning, capital planning and investment control (CPIC), program and project management. The solution architecture must realize the business case.

The top-down nature of enterprise architecture is apposite, as "business-led architecture is more successful in meeting strategic goals, responding to changing mission needs, and serving citizens’ expectations than technology- or budget driven architecture"2. OMB advises agencies to architect the big-picture, and then use the architecture to guide smaller segments of the enterprise. In contrast, the solution architecture is typically limited to a specific project. For example, solution architecture will guide the modification of a software application, or the deployment of new hardware-software. Solution architecture needs enough detail to support specific deployment decisions: what vendor, platform, framework, version, licensing model, and so on.    

The following table compares the attributes of enterprise architecture to solution architecture.


Enterprise Architecture
Solution Architecture
Management Activity
Technical Activity
High-Level
Detailed
Conceptual
Tangible
Top-Down
Bottom-Up
IT Requirements
IT Implementation
Long-Term Context
Immediate Solutions
Articulates the Business CaseRealizes the Business Case


As the layers of architecture are progressively elaborated top-down, the need for specifics builds from the bottom-up. At the lower level, solution architectures need to know what standards to follow and how to align deployed applications with the objectives of the EA. The progressive layers of architecture are:


  • Enterprise architecture: articulates how the business is organized to share assets and deliver services, while aligning common resources to meet strategic objectives efficiently;
  • Segment architecture: (often IT architecture in the private sector) describes a roadmap to deploy products to improve the delivery of services for one business case, or a group of business cases that support a core mission area;
  • Solution architecture: (application architecture) demonstrates how technologies fit together and can be deployed effectively for one project, or a single agency function.  


The following figure illustrates how progressive layers of detail compose the enterprise architecture, and the dichotomy of top-down bottom-up viewpoints