Enterprise Architectures

Further information and references

Enterprise Architecture: organisational capability

The General Accounting Office of the US Federal Government has developed a "management maturity framework" for the development of Enterprise Architectures. The framework is based on five stages of management maturity, and enables organisations to measure their progress in the development and exploitation of Enterprise Architectures (EA). The stages of maturity are:

Stage 1:Creating EA awareness

There are either no plans to develop and use an EA, or there are plans and actions that do not yet demonstrate an awareness of the value of having and using an EA.

Stage 2: Building the EA Management Foundation

The organisation has assigned roles and responsibilities, and established plans for developing EA products. A Chief Architect has been designated, and a program office has been established and staffed to support EA development. A Steering Committee with IT and business representatives has been set up to direct and oversee development. A Framework has been selected as the basis for the nature and content of the specific products planned for development in the documentation of the EA.

Stage 3: Developing Architectural Products

The scope of the EA has been defined as encompassing the whole enterprise, and the EA has confirmed institutional commitment. Products in development are planned to describe current and future states, and the architectural transition plan. Products are subject to configuration control.

Stage 4: Completing EA products

The products are completed and approved, for use in helping to select and control the portfolio of ICT investments. The complete products describe the organisation in business, data, applications and technology terms. The products describe the current and future architectural status and the transition plan.

Stage 5: Levering the EA for Managing Change

The architectural products are evolved according to written and approved policy. The Enterprise Architecture is approved by the Steering Committee or Head of Department. The EA is incorporated into corporate decision-making, and metrics are established and used for measuring the effectiveness of the EA.

Processes

Development of the enterprise architecture, or any of the architectures within it, will typically involve:

• initially, analysing the current architecture; this will be a process of description, documenting the architecture "as-is", or "baseline" architecture;
• moving on to a definition of the architecture as it is planned to develop in the future - the architecture as it should be, or "target" architecture.

An essential element of the strategic thinking and detailed planning for the enterprise architecture will be the development of a transition plan showing how the organisation will progress towards the target architecture from the baseline architecture. This requirement may well form one of the "themes" of the IS Strategy for the enterprise. It should be recognised that the "target" architecture represents a vision of the future which will almost certainly never be achieved in its totality; as the enterprise architecture is developed, together with other elements of the organisation's IS Strategy, changes will arise in business requirements, organisational mission and available technologies which will shift the target for the architecture. It must therefore be subject to continuing monitoring and review.

An architecture, at whatever level, places commitments, obligations and constraints on the designer and implementer of the architected system. It is therefore a tool which supports decision-making in the organisation, and must be firmly based in the business needs and objectives of the organisation.

See also details relevant to this topic contained in the Requirements Management workbook.

The processes involved in the development, maintenance and review of the enterprise architecture are likely to be closely bound up with the processes concerned with development, monitoring and progression of the organisation's IS Strategy. The activities solely concerned with the enterprise architecture (IS and ICT/Infrastructure Architectures) can be summarised as:

• Obtain senior management buy-in and support
• Establish management structure for architecture development
• Define an approach and process for architecture development
• Describe baseline architecture
• Define target architecture
• Develop transition plan
• Use the architecture in IS/ICT developments, and monitor its use
• Maintain and evolve the architecture

Functions of the architect role
In some organisations the roles of business/organisational architect, Information Systems architect (or possibly separate roles of Applications Architect and Information Architect) and ICT and infrastructure architect will be separate functions. In others, some or all of the roles may be combined - for example, within the "Intelligent Customer" function. The roles may reside in separate parts of the organisation or even outside it; for example:

• the Business/Organisational architect role may reside within the Business Strategy and Planning function in the corporate HQ;
• the IS architect role may form part of the Intelligent Customer function with responsibility for handling relationships between the business and external suppliers and IS/ICT partners; a key responsibility of the Intelligent Customer function is the maintenance of the IS Strategy for the organisation, including the IS Architecture;
• the ICT/infrastructure architect role may reside in the supply-side partners or service providers who are responsible for the delivery of ICT infrastructure and ICT-based services to the organisation; or it may reside in the in-house IT function.

Even where the Intelligent Customer function is concerned primarily with the IS Architecture, this role will require an understanding of both the business/organisational and ICT/technology realms, in order to act as the "bridge" between them.

Research by OGC suggests the following functions of the architect role, covering the combined roles of the IS architect and the ICT/Infrastructure architect:

• Architecture definition and maintenance: architecture definition must extend beyond infrastructure and also define application, middleware and integration architectures, as well as "common" architectures such as security and management.
• Research: monitoring technology trends and developments, to ensure that the enterprise architecture remains suitably aligned with the ICT and telecommunications industries.
• Policy formulation and maintenance: policies relating to IS/ICT provide a framework for the way in which information systems and related technologies will be specified, acquired, implemented, used, managed, supported and enhanced. The architect and architecture team will need to be closely involved in the formulation and maintenance of corporate policies that directly or indirectly impact on the enterprise architecture, whether management or technical.
• Knowledge dissemination: this covers the wider dissemination of architecture documentation and standards, to serve as a prescriptive source of technology solutions.
• Consulting: the architecture team will be expected to have the necessary technology expertise and capacity to offer active support during the early stages of projects.
• Governance: rather than policing the architecture, the role of the architect is shifting to that of facilitator, providing technology expertise and guidance to help move projects forward.

Principles

"Architecture" is a term used in many different contexts. Here, "Architecture" is defined as:

the fundamental organisation of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. (from IEEE 1471)

A system as a collection of components
"System" in this definition is used in the most general sense: "a collection of components organised to accomplish a specific function or set of functions". So the system in which we are interested could be, for example, a whole organisation, a business function, a product line, a public service, an information system, an individual computer application, or a hardware component. Each of these systems will have an "architecture" as defined earlier, made up of the components of the system, the relationships between them (such as control interfaces, management commands, data exchanges and various forms of influence), the relationships between the system and its environment (political, organisational, technological, etc.), and the design principles which inform, guide and constrain its structure and operation, as well as its future development. Here, the system we are interested in is the "enterprise", or business organisation.

Any enterprise, such as a public sector body, is a complex system with many types of components including its staff, business functions and processes, organisational structure and physical distribution, information resources and information systems, financial and other resources including technology sub-systems, and the strategies, plans, management, policies and governance structures which animate the enterprise. The Enterprise Architecture would show how all these components (and others) are integrated in order to achieve the business objectives now and in the future.

The complete Enterprise Architecture description would typically be very large and complex. In practice, it is more manageable and practicable to distinguish a number of sub-sets of the total architecture, as the basis for strategic thinking and detailed planning in particular areas. There will be a number of different "perspectives" on the overall Enterprise Architecture, and each of these can be represented by its own architectural view, which is interested in only a sub-set of the components and relationships which make up the enterprise. Here we are interested only in those architectures concerned with the business of the organisation and the information systems which support it; each of these architectures calls upon distinct architectural disciplines and areas of expertise. They are illustrated in the diagram.

The Business/Organisation Architecture includes descriptions of the organisational structure, business processes, planning and control systems, management and governance mechanisms, policies and procedures of the enterprise. It shows how these components interoperate and contribute to the achievement of business goals and objectives, and provides the basis for identifying the requirements for Information Systems which support the business activities.

The Information Systems Architecture comprises:

• the Applications Architecture, which provides a blueprint for the development and deployment of individual applications, maps business and functional requirements on to applications, and shows the interrelationships between applications. Emerging Application Architectures are likely to be "service-oriented". Services can be viewed as building blocks that can be assembled and re-assembled to meet changing business requirements. Such an approach maximises re-use and helps to maintain flexibility in accommodating changes in sourcing policy.
• the Data/Information Architecture, which describes the logical and physical data assets of the enterprise, and the data management resources; it shows how the information resources are managed and shared for the benefit of the enterprise. The Data/Information Architecture will include consideration of data warehousing and knowledge management technologies which facilitate the exploitation of corporate information assets. It will increasingly cover content management and the facilities for delivery of information over multiple channels.

The ICT (Information and Communications Technology) Architecture describes the structure, functionality and geographical distribution of the hardware, software and communications components which underpin and support the IS Architecture, together with the technical standards applying to them. These components comprise the "ICT Infrastructure". The "Product Architecture" describes the particular proprietary products and industry standards which the enterprise uses to implement the infrastructure in conformance with the ICT Architectural principles. The relationships between these architectural perspectives can be seen in the diagram. The development, documentation and maintenance of business and IS architectures will typically form part of the processes of strategic thinking and strategy development in the organisation. This Briefing focuses on the IS and ICT Architectures.

Who is involved?

At the highest level, it is the responsibility of senior business management in the enterprise to ensure that Enterprise Architectures are developed, maintained and integrated within the processes of strategy development and IS/ICT planning.

Within the framework described earlier, it is possible to identify (at least) three architectural roles; these could all report to a senior "Enterprise Architect" in the organisation:

• Business/organisational architect: concerned with business models and organisational design - the structural and functional components of the organisation and their relationship, and how the business functions and activities of the organisation are distributed among them; also the governance of the organisation and the roles and responsibilities required;
• Information Systems architect (or possibly separate roles of Applications Architect and Information Architect): concerned with the information and application architectures - the logical architectures supporting the business, and the relationships between them;
• ICT and infrastructure architect: concerned with the physical technology model, and the infrastructure components and their relationships, including choices of technologies, interfaces and protocols, and the selection of products to implement the infrastructure.

The titles given to these roles will vary, depending on the organisation and its suppliers - for example, an enterprise architect might be known as a Chief Information Officer.

Success factors

The development of an enterprise architecture should be seen as an investment for the future - it will have a cost but should also yield real benefits if measured over time. The success factors for the enterprise architecture of an organisation will therefore reflect the organisation's business operations and objectives. Examples of such objectives, to which the enterprise architecture will contribute, might include the following.

• to provide effective, efficient and timely support for business processes - including achieving fast time to market or operation for new business endeavours
• to facilitate interoperability between separately developed application systems - both within and outside the enterprise (e-business, joined-up government)
• to ensure suitable flexibility of the IS/ICT infrastructure to accommodate unforeseen new or changed business requirements, organisational change, changing market conditions (including new channels to market), etc.
• to facilitate (or at least not unduly constrain) necessary business process re-engineering (noting that the need for BPR is increasingly becoming evident with the move to e-business)
• to ensure maximum longevity/reuse of infrastructural components (and hence maximum ROI)
• to reduce the need for (and incidence of) radical change in terms of IS/ICT infrastructure, services, applications, management, etc.
• to maximise opportunities for exploitation of corporate information/data assets (such as for customer relationship management or improved decision-making); this may imply a move towards consolidated data warehousing/mining, analysis of online e-business transactional history, etc.
• to ensure the survivability of information/data and other assets, especially on change of supporting technology and/or service provider - i.e. avoiding 'lock-in'
• to ensure suitable support to users, whether internal or customers, including appropriate availability and ease of use
• to reduce the cost of execution
• to provide a suitable basis for service delivery to the citizen (Modernising Government target for enabling all citizen-government transactions online by 2005).

Architecture invariably implies constraints or restrictions - for example, in the choice of products, technology infrastructure and services (the technical nature of solutions, how they are sourced or developed, how they are implemented, how they are managed, etc.). Any such constraints must flow from business and architectural needs and must not be imposed arbitrarily on the assumption that they are invariably beneficial. In general, the more constraints that can be applied, the greater the leverage that the architectural investment delivers. There will often be a tension between local needs and the greater good of the enterprise. Hence, a critical success factor for an architecture programme is achieving 'buy-in' to the fundamental goals of the architecture. All personnel who touch ICT, starting with senior non-ICT management, must understand how and why such practices will benefit the enterprise.

What is an enterprise architecture?

In simple terms, an enterprise architecture identifies the main components of the organisation or a sub-set of it (such as its information systems), and the ways in which these components work together in order to achieve defined business objectives. The components will include staff, business processes, technology, information, financial and other resources, etc. If the architecture is designed to ensure the choice of appropriate components and to specify how they will operate together smoothly and efficiently, the enterprise will benefit. But if decisions about components and their interrelationships are uncoordinated, ad hoc or localised, the result is likely to be duplication of effort and resources, poor coordination and control, problems with management and business performance, inability to share important resources such as information, and inefficiencies in operation.

Appropriate architectures for the enterprise and its information systems can facilitate the changes required to progress the Modernising Government agenda; lack of attention to enterprise architectures can inhibit change, and inappropriate architectures can become barriers to progress.With the increasing emphasis in the public sector on joined-up working and the efficient use of resources, designing the right architecture for the enterprise and its information systems is becoming increasingly important.

Architectural frameworks for IS/IT development are becoming increasingly important in the public sector as a result of:

• the demands of e-government and the targets for electronic delivery of services;
• the requirements of "joined-up" government and the need to consider interworking and information sharing beyond the boundaries of the organisation;
• the recognition of the importance of information as a key resource, and the pressures to exploit and share information resources;
• the continuing emergence of new technologies, including developments in mobile computing and support for home working;
• pressures to reengineer business processes to achieve improved efficiency and greater customer focus [ref SDTK];
• the requirements for the ICT infrastructure to integrate legacy systems into the newer e-business applications;
• the requirement for information systems and the underlying ICT infrastructure to respond rapidly to changes in the organisation and the demands of the business;
• the development of elements of "common" applications and infrastructure across government, such as the Government Secure Intranet, the Government Gateway, the Knowledge Network, and the e-Government Interoperability Framework.

The development and exploitation of an enterprise architecture will assist the organisation in meeting these challenges through the benefits of:

• Alignment: ensuring that the design of the organisation and its information systems are aligned with the organisation's mission;
• Integration: ensuring that the business rules are consistent across the organisation, that the data resources are known and sharable where appropriate,interfaces and information flows are standardised, and connectivity and interoperability are managed across the enterprise and outside it where necessary;
• Change: facilitating and managing change to any aspect of the enterprise;
• Responsiveness and efficiency: reducing timescales for systems development, minimising requirements for new applications generation, reducing timescales for modernisation, and reducing overall resource requirements for IS/ICT;
• Convergence: moving towards organisation-wide standards (and government-wide where appropriate) for infrastructure, data interchange and common applications.

Senior management need to be reasonably certain that decisions made about IT will enable the organisation to 'join up' its IT, now and in the future, without risk of inflexibility and/or lock-in to a standard that may have been arbitrarily imposed. Architectural principles have to be documented in a framework that will inform, guide and constrain choices in IS and IT development.

Introduction

This briefing explains the concept of enterprise architecture as an essential planning tool in making sure that the organisation's IT will support the business. The term 'architecture' is most commonly applied to buildings; here it has an IT-related meaning.