EAM: Realize Benefits Using the Standards Portfolio

Given increasingly large, distributed, and heterogeneous application and infrastructure landscapes, standardization is getting particular attention from enterprises and their enterprise architecture management (EAM) initiatives. It has become even more essential in today’s economic times, where enterprises are forced to cut costs wherever possible. For these challenges to be overcome in an enduring way, EAM needs to build upon a defined process for managing a standards portfolio.

Standards Management: An Integral Part of EAM

EAM has been gaining increasing significance in the business world as a great facilitator of a stronger alignment between business and IT. While this remains a focal point of EAM, there are additional benefits that may arise from EAM, including:

• Consolidation through establishing, communicating, and monitoring standardization and re-use.
• Acceleration of transformations through dedicated support of projects and decision processes.
• Compliance with regulatory, strategic, and technical requirements through advanced governance mechanisms.

To achieve these benefits, however, enterprises must embrace both strategic and operational architecture management. While strategic architecture management usually documents, analyzes, and plans different states of the enterprise architecture, operational architecture management implements guidelines and decisions made in the strategic process and is done at the project level.

Although strategic and operational architecture management can be considered as two sides of the same coin, one may often face a gap between corresponding processes in practice. Projects intended to implement decisions made in strategic architecture management are subject to long start-up and completion times or have difficulties in achieving set goals, such as cost efficiency and re-use. This is where standards management as a dedicated part of EAM comes into play. Standards management allows this gap to be bridged and strategic goals to be achieved in an accelerated and sustainable way.

Thus, the realization of EAM’s benefits may actually have a strong dependence on the maturity of the provided standards management services. Before diving into these services, however, the following question should be answered: What is the subject of an enterprise’s standards management approach, i.e., which constituents should a standards portfolio consist of?

The Standards Portfolio

While many answers to this question may focus on infrastructure components and devices, fewer are likely to take deployment methods or technology principles into consideration. The standards portfolio may, however, not only involve solution elements, but also methodology and directives. Further, an enterprise’s standards management may be ill-advised to limit the solution elements being in scope to the above building blocks and to stop short of defining patterns such as platforms and reference architectures.

But how can the architect successfully select the appropriate reference architecture in a specific project? The key is to make sure to define reference architectures for specific usage scenarios (i.e., considering business processes, products, and markets) and to consider any prior experiences made with this architecture in fulfilling particular requirements. This brings us to another issue: What about the role of business architecture in standards management? Since the business architecture represents one major domain of the overall enterprise architecture, it should definitely also play an important role in standards management. On the one hand, decisions regarding the standardization of IT components should always be made in consideration of the affected business service, process, and so on. On the other hand, the business architecture itself may be the subject of standardization, such as in the form of process building blocks or standard operating models. This is also reflected in TOGAF, for example, which features business principles, such as business continuity, service orientation, and a common use of applications.

It should be pointed out that every object of the standards portfolio runs through a specific life cycle and, as already indicated, features a particular scope of application. Figure 1 illustrates a high-level structure of the standards portfolio.

This high-level structure can, of course, be broken down into a lower taxonomic level. Infrastructure components, for example, may involve sub-categories such as runtime environments and test components. This categorization, as well as the overall focus of the standards portfolio, should be developed in an organization-specific way reflecting the key stakeholder needs. It should lay the foundation for developing, maintaining, and using the enterprise’s standards portfolio, which is sketched by the following dive into the main services of a standards management.

Standards Definition and Maintenance

Basically, a key standardization aspect is enabling the construction and maintenance of a consolidated IT landscape. If standards management has not yet been established, this, first of all, requires capturing the as-is state, i.e., filling the defined sub-categories of the standards portfolio with those pieces that currently exist within the organization, such as a certain infrastructure component.

Standardization may then be achieved using two different approaches: bottom-up or top-down. Bottom-up standardization means identifying infrastructure categories of the standards portfolio that are particularly diverse and oversized. In consideration of existing business needs, this allows hot spots to be derived and prioritized—hot spots that call for standardization and may in a next step be used to define infrastructure systems, platforms, and, eventually, reference architectures. In contrast, the top-down approach represents standardization efforts that begin with a focus on usage scenarios (e.g., back office for a certain business product), for which then reference architectures are defined. These in turn can subsequently be broken down into several standardized components on the infrastructure level. Most importantly, this approach allows the definition of the right standards from a business perspective. Both approaches, however, demand a thorough understanding of the business. From my point of view, even a pure IT standardization should not be done without any consideration of the business.

Once the desired standards are defined, it becomes necessary to determine which of them should trigger the immediate consolidation of existing heterogeneous solutions, and which of them should just be required to be considered in future projects. The prioritized hot spots may serve as a reasonable basis for decision making. For those standards that are to be implemented immediately, a consolidation road map needs to be defined and handed over to operational architecture management for implementation.

So can standards management now rest on its laurels? Of course not! Since new standards may evolve and others may become phased out, standards management must assure that the standards portfolio remains up-to-date and that the IT landscape can advance on its consolidation path. New standards, on the one hand, may need to be defined in response to, e.g., new business processes or sales channels, technical innovations, or new architectures developed by operational architecture management. Existing standards, on the other hand, may need to be updated according to new experiences that have been made during architecture implementation and operation. In fact, this “harvesting” step has proven to be essential for the standards to become accepted because it allows resolving any issues that may arise from standards that were “not invented here.”

All in all, however, establishing and maintaining a standards portfolio and—as a one-off exercise—resolving the identified hot spots is unlikely to let consolidation efforts succeed in the long run. In fact, one should now reconsider the consolidation executors and preservers: the projects. To assure an adequate consideration of the defined standards within final implementation projects, the communication and promotion of the defined standards, along with the assurance of their application, requires first-order attention as well. Standards management addresses this issue providing two complementary services: project support and compliance checks.

Project support

In development projects of architectural relevance, standards management should play a key role. In fact, it may assist in the process of developing and evaluating different architectural designs. In a first step, this can be done by raising awareness of existing architecture principles, reference architectures, or infrastructure components that are compliant with standards. Beyond, further support can be provided by gauging the concrete usage scenario and evaluating whether suitable reference architectures are available that meet the particular architectural requirements of that project. This is where prior experiences can provide valuable insights.

This approach not only allows the construction of a consolidated IT landscape to advance, but also the accelerated completion of the enterprise’s IT projects. That is because it answers questions like: Which standards components are available? Which principles do I have to adhere to? Which reference architectures may suit my needs? Doing this, standards management helps practitioners avoid the development of architectural solutions that are duplicative, since there may be existing ones that already meet the requirements.

Compliance checks

Despite communication, advice, and assistance within the process of architectural design, the selected architectural solution may in the end contravene the defined standards. Thus, it is vital to assure that the standards that may have been proposed in previous project steps are eventually applied. If not, standards management needs to evaluate how to deal with this violation, with a particular focus on the resulting costs. In fact, one has to determine whether this violation is reasonable and should be accepted as an exception (at least temporally) or even as a new standard, or whether corrective action needs to be taken to create a new architectural design. Ideally, such compliance checks should not only be done during project execution, but also as a post-implementation action, which may take the form of regular compliance reviews of existing components within all architecture domains.

In conclusion, with a standards management approach that is characterized by an integrated offering of the above services, consolidation is unlikely to remain far from being a reality. Providing the glue between strategic and operational architecture management, this approach serves both the strategic architecture manager with insights on the current status of standards compliance and the operational architecture or project manager, who is required to put strategic decisions into practice. As for the latter case, this is facilitated by the possibility of a smooth navigation from strategy to action, which will mitigate the risk of scope creep in development projects as well as cope with compliance requirements (not only those internal, but also those external to the enterprise).

by Daniel Simon, a consultant with act! consulting, specializing in enterprise architecture management. He is TOGAF 9-certified and holds a diploma degree in information systems from the University of Cologne, Germany. He can be reached at ds@act-consulting.de.