Relating Architecture to the Enterprise

Introduction    Challenges    Meeting the Challenges    IT Governance    Summary

Introduction

This section gives an overview of the strategies and techniques that are involved in successfully relating IT architecture to the enterprise it is intended to serve. Each strategy or technique is described in detail in a separate, free-standing section, hyperlinked from this section, but the set of techniques is also summarized here, since they are in many ways inter-dependent and mutually re-inforcing.

Key Challenges

To be successful, a Technical Architecture must address two key challenges: it must be (and be seen to be) actionable and actioned across the enterprise.

• On the one hand, the architecture must recognize, and be seen to respond to, the needs of the business, and of the managers - the people - who run the business. There are two aspects to this issue:
  • Detailed decisions embodied within the Technical Architecture must be clearly linked to high-level principles and business requirements of the enterprise, and the architecture must track changes to those principles and requirements.
  • Senior corporate and line-of-business managers must understand the role of the Technical Architecture in enabling the business to achieve its objectives.
• On the other hand, it is important to ensure that business units within the organization act on the IT Architecture, and do not treat it as some academic exercise that has no relevance to real business operations.

These challenges are to some extent inter-dependent, in that it is easier to ensure that the architecture is actioned if its responsiveness to the needs of the business is clearly demonstrated.

Meeting the Challenges

A variety of strategies and techniques are available to ensure that these challenges are addressed successfully.

To demonstrate that the Technical Architecture is linked to high-level business requirements and enables the business to achieve its objectives:

• The Technical Architecture must be shaped by Architectural Principles that reflect the principles that the enterprise as a whole embraces.
  • Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. As such, they provide the context within which business requirements are expressed.
  • The Architectural Principles should be derived from and clearly linked to the overall business objectives and business scenarios, and embodied in the Business Architecture.
  • The Architectural Principles section provides example architectural principles for consideration as a starting point, as well as the rationale for and the impact of implementing each principle.
• The characteristics of the Technical Architecture should be derived from the high-level requirements of the business.   Business scenarios may be used prior to, and as a key input to, the development of the architecture in order to achieve this.
  • Business Scenarios are primarily a technique for identifying and understanding business requirements, prior to (and as a key input to) the architecture development.
  • They may be used during Phase A of the ADM, if requirements are felt to be not sufficiently understood.
• Among the various architecture views that are developed, a Business Process Domain view should be used, describing the Technical Architecture from the perspective of the enterprise's key business process domains. This will verify that the architecture really does link to and underpin each key business area.
  • Business Process Domain Views are used during architecture development as a means of verifying, and demonstrating, that the architecture being developed is addressing the business requirements. (Specifically, they are an output of Phase C, and are used in Phase D of the ADM.)
  • Thorough and detailed application of the business scenario technique in the early stages of architecture development should provide an excellent foundation for an effective set of Business Process Domain views.

To ensure that the Technical Architecture is actioned:

• An effective IT Governance strategy must be put in place, and an effective organization for implementing the strategy, to ensure compliance with architecture axcross the enterprise. This in turn involves the following:
  • A cross-organizational Architecture Board must be established with the backing of top management to oversee the implementation of the IT governance strategy.
  • A comprehensive set of Architectural Principles should be established, to guide, inform and support the way in which an organization sets about fulfilling its mission through the use of IT.
  • An Architecture Compliance strategy should be adopted - specific measures (more than just a statement of policy) to ensure compliance with the architecture. Specifically:
    • The Technical Architecture document should include a set of  Project Impact Assessments, to clarify the impact of the architecture on key projects imminent or underway within the organization.
    • A formal Architecture Compliance Review process should be implemented.

The importance of an effective enterprise IT Governance strategy is elaborated on below.

IT Governance

Purpose

The purpose of IT governance arrangements is to ensure that the senior management of an organization retains control of, and responsibility for, its IT operation. The arrangements clarify who owns the enterprise's IT resources, and in particular, who has ultimate responsibility for their integration to create the synergy that is essential for business success.

IT governance is much broader in scope than architecture, but it has important ramifications for the success of the archiectture function within the enterprise.

There is a similarity between technical architecture and architecture in the physical world, in that politics has an important role to play in the acceptance of both architectures. In the real world, it is the dual politics of the environment and commerce, while in the world of the technical architecture a consideration of corporate politics is critical.

A technical architecture imposed without appropriate political backing is bound to fail. In order to succeed, the technical architecture must reflect the needs of the organisation and recognize that those needs must be derived from consensus. Technical Architects, if they are not involved in the development of business strategy, must at least have a fundamental understanding of it and of the prevailing business issues facing the organisation. It may even be necessary for them to be involved in the system deployment process and to ultimately own the investment and product selection decisions arising from the implementation of the technical architecture.

Elements

As explained above, there are three important elements of IT Governance strategy that relate particularly to the acceptance and success of architecture within the enterprise:

• A cross-organizational Architecture Board must be established with the backing of top management to oversee the implementation of the IT governance strategy.
• A comprehensive set of Architectural Principles should be established, to guide, inform and support the way in which an organization sets about fulfilling its mission through the use of IT.
• An Architecture Compliance strategy should be adopted - specific measures (more than just a statement of policy) to ensure compliance with the architecture, including project impact assessments, and a formal architecture compliance review process.

Summary

The following table summarizes the techniques that are relevant to the challenges described at the
beginning of this Section.

Strategy / Technique __________________________ Challenge / Issue	Architecture Board	Architecture Compliance Reviews	Architecture Principles	Business Process Domain Views	Business Scenarios	IT Governance Strategy	Project Impact Assessments
Ensure decisions within Technical Architecture are clearly linked to business principles and requirements.
Ensure role of Architecture in enabling business objectives is understood.
Ensure Architecture is actioned.

Copyright © The Open Group, 1999, 2001