Enterprise Architecture Design and the Integrated Architecture Framework

Click here for larger image.

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

Source: msdn.microsoft.com
Category: Architecture

Similar articles: