8 Customization of Architecture Contents and Metamodel

The TOGAF framework identifies two central concepts: a Content Framework and a Content Metamodel. The TOGAF Content Framework describes the types of work products that will be consumed and produced by an EA Capability. A subset of these will be a formal description or architecture description of a system including the components and their inter-relationships. This subset is the Content Metamodel. Both must be customized based upon the purpose of the EA Capability and the enterprise context.

An EA Capability focused on supporting decision-making for strategy will use a different set of work products than an EA Capability chartered to support governance of projects. This is a critical distinction. The Content Framework and Content Metamodel should be adjusted to align with the charter of the EA Capability. Further, the links between an EA Capability and other functions within an enterprise, such as finance, compliance, and operations aspects, require the EA Capability to fit-in and fill-out.

The TOGAF Content Framework identifies two sets of work products. First, work products that are used by others that impact planning, change governance, and purposeful benefits realization. Second, work products that are used within the EA Capability to produce the first set. An EA Capability produces value in direct relation to the consumed work products that improve planning, change governance, and purposeful benefits realization.

Understanding the EA Capability’s information requirements requires the following questions to be answered:

• What is the EA Capability’s purpose supporting decision-making and governance?
• What is the enterprise Content Metamodel?
• What is the structure of the architecture repository?
• Are there any other considerations pertinent to the enterprise?
• What are the authority, access, and planning divisions for the EA Capability?
• How formal should the documentation and work products of the EA Capability be?

For Leaders working for an enterprise that has a well-established Content Framework, such as defense with DoDAF, this chapter may not add value. Apart from the question of formality, all of the decisions regarding Content Metamodel and Content Framework have been made by DoDAF.

8.1 What is the EA Capability’s Purpose Supporting Decision-Making and Governance?

With the understanding of the outcomes expected from the EA Capability, consider the information the EA Capability requires.

As a rule-of-thumb, the more high-level decision-making the EA Capability supports, the less detail and consistency are required in documentation and supporting information. The more it focuses on governance of change project and solution delivery activity, the more detail and consistency are required in supporting information and documentation.

The level of detail required will directly impact the choices on the structure of the architecture repository and how formal the team delivering the EA Capability needs to be. The need for detail and consistency drives formal architecture modeling techniques for traceability and consistent documentation stored in a well-structured repository.

Consider that detail and consistency come at a price regarding tooling, process integration, and skill within the team that delivers the EA Capability.

8.2 Are there Specific Questions to be Addressed?

EA Capability is established for a purpose. That purpose helps define the questions that the EA Capability is expected to answer.

Keep in mind that this Guide deliberately does not refer to an EA team or organization. It is very common that organizationally associated resources answer many of the questions asked of an EA Capability.

Some of the typical questions asked of the team delivering the EA Capability to support decision-making at a portfolio level include:

1. To execute on strategy “A”, what are the the size and scope of impact on organizational changes, process, procedures, and technologies?
2. What if the enterprise switched the service provider from “A” to “B”? How soon can change be initiated and completed? Who should be involved? And so on.
3. What should be done in response to one of the technology suppliers changing its product?
4. A vulnerability has been identified in the product sourced from a key supplier. The supplier has provided a mitigation option. What is the exposure from the vulnerability? How soon should the fix be applied? What would be the potential impact during and after the mitigation process has been operationalized?
5. What are the possible root causes of complaints from the customers regarding product “A”?
6. How should the delivery against the portfolio be aligned to optimize operational cost?
7. How can the enterprise maximize differentiation by aligning delivery of the portfolio?
8. How can the enterprise minimize time-to-market by modifying delivery options on the portfolio?
9. How can the efforts on innovation be maximized by adjusting delivery against the portfolio?
10. What is the optimal level and ease of communication amongst technology and material suppliers to maintain the operational stability of the enterprise?
11. Is there any wasteful work done or latency introduced with any process flow related to delivery of products and services to customers?

Each of these questions requires the EA Capability to have different information. The different expectations from the team providing the EA Capability will shape the information that is required and the different work products to be produced. In short, these questions will identify the concerns that the EA Capability must address.

Successful, high-functioning EA Capability teams maintain a viewpoint library that identifies such questions, and the information the team providing the EA Capability must have to answer. The information to which the EA Capability team must have ready access will define the Content Metamodel and repository approach.

One of the steps in establishing a high-functioning EA Capability is defining the viewpoint library. Consider the purpose the EA Capability is being established to serve. This purpose will likely highlight classes of stakeholders and their consistent concerns. This set of consistent stakeholders and concerns will identify the information the EA Capability must have to answer stakeholder concerns. This will drive the design of the Content Framework, Content Metamodel, and the formality of the EA repository.

8.3 What Constitutes the Content Metamodel?

Regarding information management, the purpose defines what information the EA Capability must have at hand. In practical terms, information needs are derived from the viewpoint library and the information that supports the viewpoints. Consider what information is required to answer these two questions:

• How can the enterprise maximize the differentiation by aligning delivery of the portfolio?
• What should be done in response to one of the technology suppliers changing its product?

The Content Metamodel is used to structure architectural information in an orderly way so that it can be processed to meet stakeholder needs. The majority of architecture stakeholders do not actually need to know what the architecture Content Metamodel is and are only concerned with specific issues, such as: “How can the enterprise maximize differentiation by aligning delivery of the portfolio?”.

The difficulty comes when, to answer this question, the EA Capability may need to answer:

• Which processes are orchestrated by the differentiating capability?
• Which processes require an application change?
• What functionality does an application support?
• What is the impact of using cloud infrastructure for the application on information security?

There are two approaches to defining the Content Metamodel. The most successful practice ensures that the central questions the EA Capability is established to address concern the focus. In this case, look at the questions the EA Capability is established to answer, and identify the concerns and the viewpoints that address these concerns. The resulting viewpoint library defines the Content Metamodel. Anything more is noise and results in unnecessary work in future.

Following this approach leads to smaller information demands and crisply focuses the EA Capability on expected value. Any expansion in the range of critical questions the EA Capability is expected to answer will expand the information requirements. The majority of Enterprise Architects and analysts who have gone ahead to capture more information than what is required have consistently failed.

An alternative practice is to use an established Content Metamodel. This approach enables the EA Capability to address a broader set of questions. However, this approach typically leads to a great deal of superfluous model development and information management. One of the key pitfalls to avoid is assuming that an existing Content Framework is complete and will answer the questions the enterprise is asking of the EA Capability. If you undertake to use an established Content Metamodel, in order to minimize information management, identify the minimum information the EA Capability requires.

In either case, it is important to keep in mind that the information needed is infinite, and resources are finite. Minimize the information the EA Capability must maintain and focus on the purpose for which the EA Capability was formed. Address just those key questions. Take comfort in the fact that development of the Content Metamodel and viewpoint library will feed the evolution of each other.

Every component that is added to the enterprise’s Content Metamodel comes with relationships that must be maintained and comes with attributes that must be tracked. The number of interim architecture states and options multiplies the amount of information that must be maintained. To succeed, the Leader should identify and define the absolute minimum information the EA Capability must maintain to deliver the stated purpose.

Recommendation from collective experience of The Open Group is that the Leader should start with the most likely set of questions from sponsors and stakeholders based upon the enterprise context and the purpose of the EA Capability to build the viewpoint library.

Explore the minimum information needed to answer the most pressing and recurrent questions. When the questions appear to be hard to answer, refer to other models used in the enterprise like strategy development, operating model, business capability, process model, project management model, and systems development lifecycle model to validate whether they would provide the answers. Add only those additional reference models that are required to answer the new set of questions. As stated before, keep the scope limited to what is necessary and nothing more.

Consider what minimum information the EA Capability must have at hand, and what information it will need to gather upon demand. The information required at hand is the mandatory minimum. For the other information, ensure that there is a consistent way to gather and relate them to the mandatory minimum. This allows for traceability across more aspects of the enterprise.

The exercise is not to fill out all the information that might be needed in the future, but rather to identify the information that must be available to describe an EA to address the stakeholders’ questions. Test the kind of catalogs, matrices, and diagrams required to capture, analyze, and answer the questions asked of the EA Capability.

The TOGAF Content Metamodel provides a good starting point for examining the information the EA Capability requires. It provides a list of common components and common possible relationships the EA Capability may want to keep track of (motivation, role, event, activity, location, resource, platform services) and a set of relationships. Explore the alternative Content Frameworks listed in Appendix A (Partial List of EA Content Frameworks). They are designed to address different purposes that may better align with the EA Capability’s purpose.

To answer these stakeholder questions, the EA Capability will have to employ more than one technique and approach, to collate, classify, and represent back visually, verbally, and with appropriate context. To answer these questions requires an understanding and maintenance of capability, process, and application functionality models and a roadmap with appropriate intersections.

It is rare, but possible, to have a narrow scope for the EA Capability that leads to deployment of a narrow-domain approach like UML and BPMN or a pre-packaged Content Metamodel. Keep in mind that value questions supporting decision-making for strategy and portfolio require understanding cross-domain and multiple dimensions. They preclude use of narrow domain and pre-packaged metamodels.

8.4 Information Managed by the EA Capability

Managing an EA repository is often performed with EA modeling tools. Each item that is being produced should have a lineage to the question that demands a response. The need for a formal modeling technique is directly related to the level of detail required.

The needs of the data collated and the decisions to be taken dictate the needs and approach of the repository and analytic tools. To manage and analyze large volumes of complex sets of data requires automation. It is prudent to have the Content Framework and Content Metamodel suitable for the enterprise and then look for formal tools that support the EA Capability. A high-functioning EA Capability will be asked questions that demand use of automation tools. Use the tools to provide defendable analytics to support decision-making and traceability to support governance.

It is normal that the EA Capability will not manage all of the information required to support the purpose for the EA Capability. Interlinking all the necessary information via information governance channels will reduce the effort required to collect and manage the information. The EA Capability team needs to maintain the catalog and taxonomy only. Using a taxonomy and catalog of items, analysis about the landscape of processes and technology can be performed consistently, providing consistent and rich insights.

Respective disciplines manage detailed data like project financials and technical specification of a robotic arm. To operationalize the ability to mine such varied, in-depth data, it may be necessary to automate the capturing, management, and visualization of insights.

In most cases, assumptions and constraints are time-bound. Depending on the organizational structure, EA may hold the entire repository of data required for analysis or it may just link the structures that enable business operations effectiveness analysis.

The EA Capability should ensure that the notations, vocabulary, and concepts reflected in the work products can be employed to communicate within and outside the enterprise. The demand for alignment to a common vocabulary and framework arises from a need to promptly answer decision-making questions and support governance decision-making.

See Chapter 13 (Mapping the EA Leader’s Guide to the TOGAF Framework) to understand how answering questions raised in this Guide results in the population of the TOGAF Content Metamodel and broader Content Framework. This mapping is provided as an example of how the types of information required, and the iteration of the TOGAF ADM, can be structured.

8.5 Managing the Enterprise Repository

Information management is a critical task for an EA Capability. It is all too easy for an EA Capability to drown in a flood of unintegrated information, usually separated into divergent documents. Effectively managing the EA repository is dependent on effectively limiting the information needed to manage, automate, and apply appropriate standardization.

The priority is to minimize the information collected and maintained. See Section 8.2 (Are there Specific Questions to be Addressed?), and Section 8.3 (What Constitutes the Content Metamodel?). Including nice-to-have information will pose a substantive sustainability burden on the EA Capability team. This burden is particularly troublesome for an EA Capability that is IT-oriented and structured for the purpose of supporting projects. For these, a common pitfall is attempting to include design and operational information as part of the EA repository. If the information is not required to support the purpose, the essential questions, or any mandatory viewpoints, what is the value in collecting it? Design and operational information does not help to answer architecture or governance decision-making questions.

The second priority is determining the level of standardization and automation. Standardization is distinct from automation. Standardization can be performed with appropriate templates and a document repository. Automation requires implementation of an EA modeling tool.

Before any effort is made to capture information, define acceptance criteria for the content regarding completeness, integrity, flexibility, understandability, and ease of sustainment.

Key factors to consider are the purpose, size, and geographic and organizational distribution of the EA Capability team and its stakeholders. The purpose of the EA Capability will drive the required level of repeatability of process, analysis, and representation, which in turn drives the level of standardization of the Content Framework. The geographic and organizational distribution of the EA Capability has the largest impact on the need for automation. A co-located organizationally unified EA Capability can rely far more upon informal collaboration than those who are organizationally and geographically dispersed. The need for automation drives deployment of multi-user model management and analytic tools.

Table 3: EA Repository Standardization Factors (Process versus Presentation)

How Repeatability Influences Standardization of the EA Content Framework
EA to Support …	Process	Analysis	Presentation
Strategy	Low	Low	Low
Portfolio	Medium	Medium	Medium
Project	High	High	Very High
Solution Delivery	Very High	High	Very High

It is common to assume a high-functioning EA Capability requires a high level of repeatability. Purpose heavily impacts repeatability. Architecture to support strategy and portfolio has a strong tendency to be addressing unique questions, using divergent information, and not be tightly tied to predictable execution patterns. This is especially true for EA supporting portfolio. Where there is a low need for repeatability, high levels of standardization are a barrier to value creation.

Conversely, an EA Capability supporting solution delivery engagement requires an extremely high level of standardization. Effective engagement with a solution provider must be predictable to the enterprise and the solution provider. Repeatability will not be possible without a consistently used viewpoint library, information gathering and analysis, and mandated use of reference models and reference architecture.

Table 4: EA Repository Standardization Factors (Team Model versus Analysis Needs)

How the EA Team Organization Model and Analysis Needs Influence EA Repository Standardization
EA to Support …	Impact of Geographic Distribution	Impact of Federated Organization Model	Impact of Level of Complex Analysis
Strategy	Limited Impact	Very Limited Impact	Very High
Portfolio	Some Impact	Significant Impact	Very High
Project	Significant Impact	Significant Impact	Low
Solution Delivery	Significant Impact	Massive Impact	Limited

There are EA Capability teams serving the entire spectrum – from supporting strategy to engaging with a solution provider (internal and external to the enterprise). Mostly, such teams are federated. These teams may be responding to financial planning questions, alignment with organizational goals, lifecycle tracking (project and operational management), and asset inventory tracking. Two kinds of EA team (Federated EA and Dedicated EA) have a significant need to standardize on taxonomy and data flow and be integrated across all toolsets (financial planning, contract management, project management, and asset tracking).

IT delivery is only part of the solution for the enterprise challenges. IT solutions alter enterprise processes and impact other organizations. Hence, an IT-focused team may require some level of continuity between portfolio planning and solution architecture development. Why an IT solution is being developed or modified and how the change is going to be absorbed by the enterprise are foundations the EA team must know.

In a well-run, creative organization many good ideas are not derived from gaps identified in architecture. In these organizations, a Request for Architecture Work comes from someone with a good idea for improving the organization. We call this the “Request from the Wild”. Normally such a request will be proxied by a champion for the stakeholder. The champion may not have visibility into all aspects of the request. Such requests demand a great deal of critical thinking to identify the appropriate spot within the EA Landscape. The EA repository is the most important tool to accelerate the analysis and subsequent conversation with the stakeholder regarding the impact of this request on the EA Landscape and the portfolio.

Evaluate the charter and EA team model before embarking on automation of the EA repository. Consider the tax on team capacity due to lack of automation or limited automation, but do not overemphasize ease of governance. Automation should focus on productivity and collaboration, not control or decision-making.

It is good practice to focus formal modeling to supporting analysis. This drives the use of catalogs and matrices, with a very strong use of component attributes. Normally a graphical model is a barrier to strong analytics and the development of a strong architecture specification. In fact, the current and target states often have the same graphical objects and connections, while the attributes that define the characteristics of the components and relationships are different. Useful visualization routinely requires far more involved techniques than diagrams showing boxes and connections. Evolving the EA Capability and identifying transition states are highly dependent on data analytics work.

Utilizing budding architects and analysts to maintain and manage the EA repository is recommended both from a development standpoint and capacity management standpoint. It is beneficial to employ specialized graphic design resources to support the creation of effective diagram viewpoints in comparison to using out-of-the-box visualizations from EA tools.

return to top of page

---

---