Enterprise Architecture Alignment Heuristics

 

Pedro Sousa
Carla Marques Pereira
Jose Alves Marques

Link Consulting, SA

January 2005

Summary: The alignment between Business Processes (BP) and Information Technologies (IT) is a major issue in most organizations, as it directly impacts on the organization's agility and flexibility to change according to business needs. The concepts upon which alignment is perceived are addressed in what is called today the "Enterprise Architecture," gathering business and IT together. The focus of this paper is to show how alignment between Business and IT can be stated in terms of the components found in most Enterprise Architectures. (11 printed pages)

Contents

Introduction
Enterprise Architecture Frameworks
Identifying Enterprise Architecture Components from an Alignment Perspective
Alignment Heuristics
Final Remarks
References
About the Authors

Introduction

The alignment between Business Processes (BP) and Information Technologies (IT) is a major issue in most organizations, as it directly impacts on the organization's agility and flexibility to change according to business needs. The concepts upon which alignment is perceived are addressed in what is called today the "Enterprise Architecture", gathering business and IT together.

Many Enterprise Architecture Frameworks have been proposed, focusing on different concerns and with different approaches for guiding the development of an IT infrastructure well suited for the organization. Each Enterprise Architecture Framework has its own concepts, components, and methodologies to derive the component all the required artifact. However, when the main concern is alignment, we may consider simpler architecture concepts and simpler methodologies because the focus is not to define development artifacts but only to check their consistency.

The focus of this paper is to show how alignment between Business and IT can be stated in terms of the components found in most Enterprise Architectures.

In the next section, we briefly introduce three well-known Enterprise Architecture Frameworks, namely: The Zachman Framework, Capgemini's Integrated Architecture Framework and the Microsoft Enterprise Architecture. We do not intend to fully describe them, but solely present the main aspects.

Next, we present the basic concepts common to these frameworks, focusing on their generic properties and leaving out specificities of each framework. We will consider four basic components of an Enterprise Architecture: Business Architecture, Information Architecture, Application Architecture and Technical Architecture.

Finally, we show how alignment between Business and IT can be disaggregated into alignment between these basic components, we present general heuristics defined in terms of the architectural components and present the work in progress. We will not address the Technical Architecture; the main reason being that technical alignment is mostly dependent on the technology itself.

Enterprise Architecture Frameworks

The Zachman Framework

The Zachman Framework for Enterprise Architecture (www.zifa.com) proposes a logical structure for classifying and organizing the descriptive representations of an enterprise. It considers six dimensions, which can be analyzed in different perspectives, as presented in Figure 1; the rows represent the perspectives and the columns the dimensions within a perspective.

The Framework is structured around the views of different users involved in planning, designing, building and maintaining an enterprise's Information Systems:

• Scope (Planner's Perspective): The planner is concerned with the strategic aspects of the organization, thus addressing the context of its environment and scope.
• Enterprise Model (Owner's Perspective): The owner is interested in the business perspective of the organization, how it delivers and how it will be used.
• System Model (Designer's Perspective): The designer is concerned with the systems of the organization to ensure that they will, in fact, fulfill the owner's expectations.
• Technology Model (Builder's Perspective): The builder is concerned with the technology used to support the systems and the business in the organization.
• Detailed Representations (Subcontractor's Perspective): This perspective addresses the builder's specifications of system components to be subcontracted to third parties.

While the rows describe the organization users' views, the columns allow focusing on each dimension:

• Data (What?): Each of the cells in this column addresses the information of the organization. Each of the above perspectives should have an understanding of enterprise's data and how it is used.
• Function (How?): The cells in the function column describe the process of translating the mission of the organization into the business and into successively more detailed definitions of its operations.
• Network (Where?): This column is concerned with the geographical distribution of the organization's activities and artifacts, and how they relate with each perspective of the organization.
• People (Who?): This column describes who is related with each artifact of the organization, namely Business processes, information and IT. At higher level cells, the "who" refers to organizational units, whereas in lower cells it refers to system users and usernames.
• Time (When?): This column describes how each artifact of the organizations relates to a timeline, in each perspective.
• Motivation (Why?): This column is concerned with the translation of goals in each row into actions and objectives in lower rows.

Figure 1.   The Zachman Framework, © John A. Zachman International (click for larger image)

Figure 2.   The Integrated Architecture Framework

Capgemini's Integrated Architecture Framewor

Capgemini has developed an approach to the analysis and development of enterprise and project-level architectures know as the Integrated Architecture Framework (IAF) shown in Figure 2 [AM04].

IAF breaks down the overall problem into a number of the related areas covering Business (people and processes), Information (including knowledge), Information Systems, and Technology Infrastructure, with two special 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.

The Contextual view presents the overall justification for the organization and describes the contextual environment. It corresponds largely to Zachman's Planner's Perspective row.

The Conceptual view describes what the requirements are and what the vision for the solution is. The Logical view describes how these requirements and vision are met. Finally, the Physical view describes the artifacts of the solution.

These views have no direct relation to Zachman's perspectives because in IAF, Business, Information, Information Systems and Technology Infrastructure are the artifacts of the architecture whereas in Zachman, Business, Information Systems and Technology are views (perspectives).

Microsoft Enterprise Architecture

Microsoft Enterprise Architecture shown in Figure 3, is a two dimensional framework, that considers four basic perspectives (business, application, information, and technology), and four different levels of detail (conceptual, logical and physical and implementation).

The business perspective describes how a business works. It includes broad business strategies along with plans for moving the organization from its current state to an envisaged future state.

Figure 3.   Microsoft Enterprise Architecture Perspectives

Figure 4.   Decomposing Business and IT Alignment into Architectural Components

The application perspective defines the enterprise's application portfolio and is application-centered. The application perspective may represent cross-organization services, information, and functionality, linking users of different skills and job functions in order to achieve common business objectives.

The information perspective describes what the organization needs to know to run its business processes and operations. The information perspective also describes how data is bound into the business processes, including structured data stores such as databases, and unstructured data stores such as documents, spreadsheets, and presentations that exist throughout the organization.

The technology perspective provides a logical, vendor-independent description of infrastructure and system components that are necessary to support the application and information perspectives. It defines the set of technology standards and services needed to execute the business mission.

Each of these perspectives has a conceptual view, a logical view, and a physical view. Elements of the physical view also have an implementation view. Microsoft Enterprise Architecture is described in detail in the MSDN Library.

Making a parallel between the Microsoft's and Zachman's Enterprise Framework, the Business perspective corresponds to Planner's and Owner's perspectives; Application perspective to Zachman Designer's perspective; Technology perspective to Builder's and Subcontractor's perspectives and finally, the Microsoft Information perspective corresponds to the Data column in the Zachman framework.

Identifying Enterprise Architecture Components from an Alignment Perspective

As we could see in previous sections, different Enterprise Frameworks have different ways to model artifacts of the Enterprise, their perspectives and the different levels at which they can be described.

The Enterprise Frameworks address a large number of problems and therefore have a degree of complexity far larger than needed if the sole problem is the alignment of the business and IT architecture. Thus we can simplify these models and just consider the sub-architectures which have a certain commonality. It is out of the scope of this paper to fully study and justify similar concepts in these Enterprise Architecture Frameworks. If alignment is the main concern, an Enterprise Architecture has four fundamentals components: Business Architecture, Information Architecture, Application Architecture and Technical Architecture. This is not new, and it has been long accepted in the Enterprise Architect Community (for instance see www.eacommunity.com).

We will address the issue of alignment based on the coherency between elements of Business Architecture, elements of Information Architecture and elements of Application Architecture. The more elements each of these Architectures has, the more rich and complex is the concept of alignment, because more rules and heuristics need to be stated to govern the relation between these elements. So, in order to build up alignment, one must first clarify the elements of each architecture (see Figure 4).

In what concerns the Technical Architecture, its alignment is mostly dependent on the technology itself. We are currently investigating how Service Oriented Architecture (SOA) concepts overlap with previous architectures and how alignment could be formulated in its model. This is ongoing work and is beyond the scope of this paper.

Business Architecture

The Business Architecture is the result of defining business strategies, processes, and functional requirements. It is the base for identifying the requirements for the information systems that support business activities. It typically includes the following: the enterprise's high-level objectives and goals; the business processes carried out by the enterprise as a whole, or at least a significant part; the business functions performed; major organizational structures; and the relationships between these elements.

In this paper, we consider a simpler case where the Business Architecture includes only Business Processes, each business process is composed by a flow of business activities and each activity is associated with information entities, time, and people. Business Processes have attributes such as criticalness, security level, delayed execution (batch), on-line, and so on.

Information Architecture

The Information Architecture describes what the organization needs to know to run its processes and operations, as described in the Business Architecture. It provides a view of the business information independent of the IT view of databases. In the Information Architecture, business information is structured in Information Entities, each having a business responsible for its management and performing operations like: Acquisition, Classification, Quality Control, Presentation, Distribution, Assessment, and so on.

Information Entities must have an identifier, defined from a business perspective, a description, and a set of attributes. Attributes are related to business processes (that use or produce them) and to applications (that create, read, update and delete them). Attributes are classified according to different properties such as Security, Availability and so on.

As an example, Client and Employee are typical Information Entities. Employee has attributes such as "courses taken", "competences", "labor accidents", and "career". Each of these attributes can be physically supported by a complex database schema in different databases used by several applications.

Application Architecture

The Application Architecture describes the applications required to fulfill two major goals:

1. Support the business requirements, and
2. Allow efficient management of Information Entities.

Application Architecture is normally derived from the analyses of both Business and Information Architectures.

Application Architecture typically include: descriptions of automated services that support the business processes; descriptions of the interaction and interdependencies (interfaces) of the organization's application systems; plans for developing new applications and revision of old applications based on the enterprises objectives, goals, and evolving technology platforms.

Applications also have required attributes, such as availability (up time), scalability (ability to scale up perform), profile-based accesses (ability to identify who does each tasks).

Alignment and Architecture Component

After identifying the major architectural components from an alignment point of view, we are now in position to address the relations between these components in terms of alignment.

Alignment between Business and Applications

In a fully aligned Business and Applications scenario, the time and effort business people spent to run the business should be only devoted to "reasoning" functions. On the contrary, misalignments force business people to perform extra and mechanic work such as:

• Inserting the same data multiple times in different applications.
• Logging in multiple times, once for each application they need to access.
• Recovering from a failed operation across multiple systems, requiring careful human analyses to rollback to a coherent state.
• Overcoming inappropriate application functionality. For example, printing invoices one by one because applications do not have an interface for multiple printing.
• Notice that alignment between Business and Applications in the above context, does not imply a flexible and agile IT Architecture, in fact, a measure of a flexible and agile IT Architecture is the effort IT people make to keep the Business and Applications aligned when Business is changing. This topic is addressed next.

Alignment between Information and Application

In fully aligned Information and Applications Architectures, IT people only spent effort and time coding business functions and logics. On the contrary, misalignments between information and application require IT people to do extra coding for:

• Keeping multiple replicas of the same data coherent, because they are updated by multiple applications.
• Assuring coherency from multiple transactions, because a single business process crosses multiple applications.
• Gathering information from multiple systems and coding rules to produce a coherent view of the organization's business information.
• Transforming data structures when data migrates between applications.

The extra coding is required to consistently modify both architectures. However, since the information critical to run the business (Information Architecture) is far more stable than the applications to support it (Applications Architecture), most effort really is put into changing in the Applications.

Alignment between Business and Information

Information and Business Architectures are aligned when business people have the information they need to run the business. This means accurate, with the right level of detail, and on time information. Unlike the previous misalignments, here the impact is neither time nor effort, but the impossibility of getting the adequate piece of information relevant for the business.

Examples are abundant; a CEO asks for some report, where sales figures need to be disaggregated by type of services. Assuming the report requested by the CEO has either actual or foreseen business relevance, the possibility/ impossibility to produce such report is an evidence of the alignment/misalignment between information and Business Architectures. To produce the report we must have the adequate basic data and data exploring applications, and thus this is an issue that should be dealt by the previous Alignments (Information/ Applications and Business/Applications).

Alignment Heuristics

We developed Alignment's Heuristics as a common sense rule (or a set of rules) to increase the probability of finding an easier way to achieve Business, Information and Application Architectures alignment.

Heuristics presented result from mapping our experience, both as academic teaching at university and professional consultancy services, into the context of the Business, Information and Application Architectures presented in this paper. We present the heuristics that we consider to have a greater value, given its simplicity and its results.

The main heuristics to consider when checking alignment between Business and Application Architectures are:

• Each business process should be supported by a minimum number of applications. This simplifies user interfaces among applications, reduces the need for application integration, and also minimizes the number of applications that must be modified when the business process changes.
• Business activities should be supported by a single application. This reduces the need for distributed transactions among applications.
• Critical business processes should be supported by scalable and highly available applications.
• Critical business processes/activities should be supported by different applications than the noncritical business processes/activities. This helps to keep critical hardware and permanent maintenance teams as small as possible.
• Each application's functionality should support at least one business process activity. Otherwise, it plays no role in supporting the business.
• Information required for critical processes should be also supported by scalable and highly available systems.
• Business processes activities requiring on-line/batch support should be supported by applications running on different infrastructures, making easier the tuning of the systems for operating window.

The main heuristics to check alignment between Application and Information Architectures are:

• An information entity is managed by only one application. This means that entities are identified, created and reused by a single application.
• Information entities are created when identifiers are assigned to them, even if at that time no attributes are known. For example, if the Client information entity may be created before its name and address and other attributes are known. Even so, the application that manages Client information entity must be the application that manages their IDs.
• Applications that manage information entities should provide means to make the entity information distributable across the organization using agreed-on protocols and formats.
• Exporting and distributing information entities across organization applications should make use of a "data store", rather than a point-to-point Application integration. Applications managing a given information entity should export its contents to the data store when its contents have changed. Applications requiring a given information entity should inquire the data store for up-to-date information. This allows for computational independence between applications, and make possible to size the HW required to run an application without knowing the rate that other applications demand information from it. Further, if the application goes down, it allows other to continue operation using best possible data.

Whenever possible, applications should manage information entities of the same security level. This simplifies the implementation of controls and procedures in accordance with the security policy. Finally the main heuristics to apply for Business and Information alignment are:

• All business processes activity create, update and/or delete at least one information entity.
• All information entities attributes are read at least by one business process activity.
• All information entities have an identifier understood by business people.
• All information entities must have a mean of being transformed for presentation to appropriate audiences using enterprise-standard applications and tools.
• All information entities must derive from known sources, and must have a business people responsible for its coherency, accuracy, relevance and quality control.
• All information entities must be classified and named within the Information Architecture.
• For each information entity, Business people should be responsible for assessing the usefulness and cost/benefits of information and sustain its continued use.

Final Remarks

The heuristics presented have been validated and tested in real projects. In some cases, different heuristics produce opposite recommendations. This means that, a compromise solution must be reached. In other cases, heuristics do not favor optimal solutions from an engineering point of view, because optimal solutions do not normally take into account flexibility and ease of change.

Another remark is the heuristics presented intend to validate alignment among architectures, but assume that each architecture is "aligned within itself". This means that we are not checking if, for example, the Business Architecture presents a good and a coherent schema of the business processes and activities. Likewise, we are not checking if Applications Architecture makes sense or not. This requires more complex models, such as the ones initially proposed in original Frameworks (Zachman, IAF and Microsoft).

The work presented was developed using the Zachman Framework as the general approach, but is strongly focused in the alignment issues. We have coded a large percentage of the heuristics presented in a modeling tool (System Architect from Popkin Software) and we are able to derive a measurement for alignment given a Business, Application and Information Architecture. We have started work to include these heuristics in Microsoft Visio.

We consider the heuristics to be valuable because they force architects to think about the justification of their decisions, leaving better documented and solid architectures.

References

[AM04] Andrew Macaulay, Enterprise Architecture Design and the Integrated Architecture Framework, JOURNAL1: Microsoft Architects Journal, Issue 1, January 2004.

About the Authors

Pedro Sousa
pedro.sousa@link.pt

Pedro Sousa is responsible for Enterprise Architecture professional services at Link Consulting SA, where he has been involved in several Enterprise Architecture projects for the past six years. He is an Associate Professor at the Technical University of Lisbon (IST), where he teaches on theses subjects in Masters of Computer Science courses. He has published a series of papers about Business and IT alignment.

Carla Marques Pereira

Carla Marques Pereira has a MSc in Computer Science at the Technical University of Lisbon (IST). She is reading for a PhD on the subject of "Business and IT alignment". Carla is a member of Link Consulting SA's Enterprise Architects team and a researcher in the Center for Organizational Engineering (ceo.inesc.pt).

Jose Alves Marques

Jose Alves Marques is CEO of Link Consulting SA and a full Professor at Technical University of Lisbon (IST). Technically, his main focus is Distributed Systems Architectures and Services Oriented Architectures. He has a long track of published papers and projects on these domains.

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

© Microsoft Corporation. All rights reserved.