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
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):
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:
The application architect's salient TRM requirements:
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).
Copyright © Snyders.US. All rights reserved.
Traceability is the key element for a tangible Technical Reference Model.
John R. Snyder, February, 2009
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.
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:
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.
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|
|IT Requirements||IT Implementation|
|Long-Term Context||Immediate Solutions|
|Articulates the Business Case||Realizes 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:
The following figure illustrates how progressive layers of detail compose the enterprise architecture, and the dichotomy of top-down bottom-up viewpoints