Enterprise Architecture Design and the Integrated Architecture Framework

http://msdn.microsoft.com/en-us/library/aa480017.aspx

ummary: Describes Cap Gemini Ernst & Young's Integrated Architecture Framework, and describes a model for enterprise architecture and its importance in helping software architects understand the business as a whole. (8 printed pages)

Contents

Enterprise Architecture in Context
Cap Gemini Ernst & Young's Integrated Architecture Framework
Communication and Architecture Governance
Linking Architecture and Design
Summary
Further Reading

Enterprise Architecture in Context

Over the past few years, and as software and systems engineering has matured, it has become accepted that there is a clear need for an 'architectural view' of systems. This need has grown as a result of the increasing complexity of systems and their interactions within and between businesses. Furthermore, continued pressure to reduce IT costs and deliver real, quantifiable business benefit from solutions necessitate a clear understanding of how systems support and enable the business.

The 'architectural view' of systems (both business and IT systems) is defined in the ANSI/IEEE Standard 1471-2000 as: 'the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution'. Further to this high-level definition, and in the same way as there are different levels of architecture within building (city plans, zoning plans and building plans), it is important to classify business and IT architecture into a number of different levels:

Enterprise Architecture. Defining the overall form and function of systems (business and IT) across an enterprise (including partners and organizations forming the extended enterprise), and providing a framework, standards and guidelines for project-level architectures. The vision provided by the Enterprise Architecture allows the development of consistent and appropriate systems across the enterprise with the ability to work together, collaborate, or integrate where and when required.

Project-Level Architecture. Defines the form and function of the systems (business and IT) in a project or programme, within the context of the enterprise as a whole and not just the individual systems in isolation. This project-level architecture will refine, conform to and work within the defined Enterprise Architecture.

Application Architecture. Defines the form and function of the applications that will be developed to deliver the required functionality of the system. Some of this architecture may be defined in the Enterprise and Project-level Architecture (as standards and guidelines) to ensure best-practice and conformance to the overall architecture.

When considering how organizations typically manage business change and IT enablement, traditional approaches to strategic business change use a top down view of the business in terms of its people and processes. However, the traditional software and systems engineering approaches tend to focus on identifying and delivering the specific functionality required to automate a task or activity. Less importance is attached to how the resulting system will interact with other systems and the rest the business in order to deliver wider business benefit. As a result, there is often a gap between the high level vision and structure of the business, and the systems implemented to support them (in other words the alignment between business and IT is poor).

To bridge this gap, many organizations are developing an enterprise architecture to provide a clear and holistic vision of how systems (both manual and automated) will support and enable their business. An effective enterprise architecture comprises a comprehensive view of the business, including its drivers, vision and strategy; the organization and services required to deliver this vision and strategy; and the information, systems and technology required for the effective delivery of these services (see Figure 1).

Figure 1. Business and Systems Alignment

Defining an enterprise architecture is complex, because it encompasses the systems within the context of the whole enterprise. To simplify this, an enterprise architecture is typically structured by considering a business or system as a series of components (or services) with inter-relationships, without having to consider the detailed design within the individual components.

Both the components and their inter-relationships must be viewed in terms of the services that they provide, and the characteristics, such as security, scalability, performance, integration, required of those services. These components can then be grouped by service characteristics, distribution and other business-driven aspects as well as functionality.

Although enterprise architecture should ideally be designed using a top down approach, many organizations have severe budget constraints for strategic IT initiatives which do not readily offer short-term return on investment or quantifiable business benefit. For this reason, many enterprise architectures are initially created as part of an approved large project or programme. Once in place there are opportunities to refine it further and to start demonstrating benefit and value by providing standards and guidelines for subsequent projects.

Cap Gemini Ernst & Young's Integrated Architecture Framework

Cap Gemini Ernst & Young has, over the past 10 years, developed an approach to the analysis and development of enterprise and project-level architectures know as the Integrated Architecture Framework (IAF). This approach, now its third major revision, has been developed at a global level-based on the experience of Cap Gemini Ernst & Young architects on real projects, together with a formal review process including academics. IAF has been successfully used on many hundreds of engagements, both large and small, across the globe.

IAF breaks down the overall problem into a number of the related aspect areas covering Business (people and process), Information (including knowledge), Information Systems, and Technology Infrastructure, with two specialist areas addressing the Governance and Security aspects across all of these. Analysis of each of these areas is structured into four levels of abstraction: Contextual, Conceptual, Logical and Physical, as shown in Figure 2.

Figure 2. Integrated Architecture Framework

This approach allows the pragmatic deployment of the framework in many different scenarios, both by using only the relevant parts of the framework and by supporting iterative working across the streams. This flexibility minimises the traditional effects of a waterfall approach and ensures coherency across the aspect areas. For example, a project architecture using IAF will, in many cases, only need to use sufficient of the Business and Information aspect areas to provide the overall context for the project. An enterprise architecture will concentrate mainly on the contextual, conceptual and logical levels.

The Contextual level brings together the business and other drivers, vision and strategy and their resulting priorities into a set of principles all of which are described with their implications and priorities. This comprehensive set of statements is then used in a consistent manner in the decision making process, providing traceability back to the original business drivers, strategy and vision, and demonstrating the required business-systems alignment.

Although much of the work done at this stage is concerned with data gathering, the importance of this stage cannot be overstressed. It will provide the basis for the entire architecture design by creating and documenting an understanding of the scope from an overall business perspective.

The Conceptual level details the services and the interactions between these services in support of the principles defined in the Contextual level. As the models defined in the Conceptual level are service-based (that is they do not detail specific products or standards), they remain stable unless the business itself fundamentally changes its vision and objectives; providing a solid foundation from which the logical architecture can be derived.

Key decisions taken at this level include:

• What areas of the business to use IT to support?
• Which overall business architecture (e.g. moving to a front-office, mid-office, back-office model) will be used?
• How systems will reflect the organization/business architecture, the level to which department systems are consolidated into a suite of core applications or are allowed departmental flexibility with a central integration service?

The Logical level describes the solution as product-independent services or components, includes a clear definition of the integration and collaboration contracts between these services or components. By remaining independent of products, this level of the architecture can remain relatively stable. It can change to reflect top-down changes, including new fundamental business models (for example a move towards a Customer-Centric model), as well as bottom-up changes, such as opportunities for technology enablement (such as CRM) or fundamental changes in technology paradigm (for example Services Architecture or Grid). Through this, the impact of change at the business or technology level can be assessed in a clear and consistent manner.

Key decisions taken at this level include:

• How should the logical components be grouped (for example, providing a multi-channel customer logon service with separate channel-specific/optimised authentication components alongside a common authentication support component using a central directory)?
• How will logical components be shared across systems (these components could be presented as Web services)?
• How a central integration hub supports the various business systems, or the way in which collaboration tools are used alongside databases applications and integration to support virtual team?

Typically, at the logical level, there might be more than one way to approach the solution (which reflects the various drivers, for example cost, flexibility, security, manageability). The key decision at this level is then to select (with the business) the solution alternative that delivers the services required, in a way that best addresses the guiding principles.

The Physical level details the design principles, standards and guidelines, including component grouping in critical areas as well as deployment models. This provides the framework within which the detailed design can be undertaken, as well as selection criteria (not functional specifications) for products to be either developed or purchased.

It is at this level that solution frameworks and architectures such as the Microsoft Systems Architecture (MSA) can be used at this level to accelerate development of the physical architecture, improve the quality of the architecture (by using proven solutions) and reduce project risks.

Examples of key decisions taken at this level are:

• Which physical components will be part of a package solution (e.g. using physical components from the ERP solution).
• What additional components will be required around this package, and the standards and guidelines for developing these components (e.g. language, tools, etc.)?
• What are the standards and detailed product selection criteria for the infrastructure products to be deployed?—leading onto a candidate list for selection. If there is a clear product or vendor strategy, this candidate list becomes the product standards to be taken forward.

Communication and Architecture Governance

Because of the large number of potential stakeholders, the enterprise architecture needs to be communicated at many different levels, using the appropriate visual representations and language: For senior management, the architecture must show how the business goals and drivers will be supported, and how benefit can be derived. The focus of business users is more on their own individual business areas and is more functionally biased. IT management and staff will want to focus on the technical components, including how they will be able to provide the required levels of support. Project-level architects will be concerned with the standards and guidelines, which will provide re-use opportunities or impose constraints on their individual designs.

Programs and projects must conform to the enterprise architecture to ensure that business benefits can be realized, and that the systems and software engineering activities can benefit from the analysis already done in defining the enterprise architecture. Furthermore, as with all architectures, the enterprise architecture requires ongoing maintenance, especially around the more physical areas such as technical standards. This ensures that the enterprise architecture remains valid and relevant to the business as it changes. The enterprise architecture should be under the control of an enterprise-wide governance function that ensures its maintenance and verifies the ongoing conformance of systems. Even where, for clear and justified business reasons, conformance is not possible, this function is then able to make sure that the business understands the real costs of implementing non-conformant systems, for example increased running costs or lack of future flexibility.

Linking Architecture and Design

As the use of the term 'architecture' has grown within business and IT, there have been many areas of confusion: for example, in many organizations, architecture and design are seen as being the same thing. It is Cap Gemini Ernst & Young's view that this is not the case because design and architecture offer different and complimentary perspectives on the solution—in fact, Cap Gemini Ernst & Young use IAF and the Rational Unified Process (RUP; a software development approach) on projects to deliver a complete design approach from architecture to code. Table 1 shows the comparison between architecture (IAF) and design (RUP, including application architecture):

Table 1. Comparing Architecture and Design

Delivers
Does Not Deliver

Architecture

• Non-functional requirements
• Functional scope and responsibilities (who does what)
• Key design and product choices
• High level design
• Design constraints

• Prototypes
• Comprehensive functional requirements
• Detailed data analysis
• Built and implemented systems

Design

• Functional requirements and how they will be met
• Detailed data analysis and data model as necessary
• System design documentation
• Built and implemented systems

• Solution Vision
• Comprehensive and traceable non-functional requirements
• Security and governance architectures

As with the architecture of buildings, software architecture and (detailed) design are, in fact, part of an overall 'design continuum' required to deliver a complete solution. Aligning IAF and RUP processes provides a comprehensive and consistent framework in support of this. Furthermore, the enterprise architecture will provide much of the context and other inputs required by the project architecture, whilst the project architecture will cater for the unique requirements of the solution.

In projects with significant potential risk, especially on complex or large projects, the use of the architectural approach at project-level will mitigate many of the risks by ensuring that there is a clear and holistic understanding of the overall context of the solution including external systems and drivers that may affect the solution.

With IAF, a project-level technical architecture uses the same basic approach as the enterprise architecture, albeit with different levels of detail, with more focus on the logical and physical level of information, information systems, technology infrastructure, governance and security aspects (using the context and business architecture defined in the enterprise architecture).

As a result, the output from the enterprise architecture can be used directly as the input into the project-level technical architecture. From the project-specific technical architecture, the detailed and specific design principles, guidelines, standards, and constraints, which then guide the detailed software and systems engineering design activities, can be derived. In the case of IAF, the output from the project-level technical architecture can be mapped onto RUP design artefacts such as business use cases, system use cases, and non-functional specification. These mappings typically are not one-to-one, but do provide traceability through from the architecture to the physical detailed design, as well as helping accelerate the overall design process from architecture through to delivered systems. This helps accelerate the design/development effort whilst continuing to mitigate project risks.

Figure 3. IAF and RUP

Summary

Enterprise architectures are becoming more important today as the level of complexity and inter-operation between systems and business increases, and as there is even more need for business-system alignment and cost-effective use of IT to deliver business benefit. Enterprise architecture (and project-level technical architecture) provides valuable input into application architecture and detailed design by helping architects understand the business as a whole and by placing the solution being designed into the overall business and technical context within which the project is being delivered.

The key objectives of an enterprise architecture are to understand ...

• The relevant parts of whole business, in context (incl. external partners)
• The end-to-end processes (including external processes/actors)
• Non-functional requirements (including security & governance)

which results in a solution that ...

• Supports the non-functional requirements. This may need specific component organization to support, for example, specific cross-domain security requirements, or a service-based approach to provide the required flexibility.
• Is seen in the context of the whole business and end-to-end processes. For example, service level objectives may exist for overall transaction times that span more than one business—understanding the limitations of this allow these measures to be refined.
• Links to, and is traceable to, the business principles so that the impact of changes, some of which may result from the design stage, can be evaluated in business terms.
• Drives, contextualises, and constrains the design. The design for the application or infrastructure will need to be governed by the architecture in order to fully deliver the complete solution including the non-functional requirements.
• Is clearly scoped, understood and clearly defines the responsibilities of each element.

and provides the rationale ...

• For decisions, standards and product selections that support the business goals and drivers.

Further Reading

Cap Gemini Ernst & Young Technology Services

Services Architecture

Adaptive IT

About the author

Andrew Macaulay joined Cap Gemini Ernst & Young as a Technical Architect in 1993 following ten years as a Technical Consultant. He has been an Architect and Technical Consultant on many major engagements, both at an Enterprise and the Project level, and has been instrumental in developing, delivering and training Cap Gemini Ernst & Young's approach to architecture, Integrated Architecture Framework. Andrew can be reached at andrew.macaulay@cgey.com.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit theArchitecture Journal website.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit theArchitecture Journal website.