An Introduction to Enterprise Architecture

Enterprise architecture relates to the practice of business optimization that addresses business architecture, performance management, organizational structure, and process architecture. It consists of describing the current and future structure and behavior of an organization's processes, information systems, personnel, and organizational business units so they align with the organization's strategic direction, going beyond information technology.

Enterprise architecture is most commonly associated with information technology. In this article I will describe a simplified, top-down approach of enterprise architecture in the context of SOA (service-oriented architecture), focusing on information technology with the objective of providing a better alignment between business and IT.

I will be presenting:

• the different concerns in a top-down enterprise architecture approach
• enterprise architecture goals
• a methodology in brief
• the relation with the BEA SOA 6 domains model

By the end of this article you will have a good understanding of a top-down enterprise architecture approach driven by the business strategy, the advantages of this approach, and the organizational considerations related to it.

The Different Concerns in a Top-down Enterprise Architecture Approach

In a top-down approach, going from the business to IT, it can be practical to separate the different concerns of business and IT on different plans, providing a common ground in between. The business-related plan can be named business processes plan, the IT plan can be named applications plan, and the plan in between—the most significant in this approach, since it has the intention of providing a better alignment of business with IT—can be named the functional plan. A technical plan can be added relating to the description of hardware, networks, operating systems, application servers, and databases. I won't describe the technical plan in detail, my main objective being to propose an approach promoting a better alignment of IT to business through a common ground.

Figure 1 illustrates these plans and how they are related. I will describe them in more detail.

Figure 1. The different concerns in a top-down enterprise architecture approach

Business processes plan

This plan focuses on the business processes in the context of a business strategy. Starting from business needs defined by the business strategy, an enterprise architect, working closely with the different lines of business in an organization, can start modeling the major enterprise business processes. The enterprise architect can achieve this on the design level using AquaLogic BPM designer, for example. This will help the architect understand the global and major processes of an enterprise and will promote the approach by involving business representatives. Using AquaLogic BPM Designer, business analysts can simulate the business processes, providing a measurement of the optimization that occurs when doing process reengineering. The business processes plan is owned by the business. The architect's role consists mainly of capturing the business needs and identifying common business services usable through different business lines in an organization.

Taking an example in the context of the banking business, you start designing the processes with the different lines of the banking business, such as loans and import/export operations. These two lines of business have completely different processes but will be sharing common services. Identifying common services is done by designing the processes on the organization level. At some point it will be clear that the authorization system and the accounting system should be reused in different processes such as the process of opening a letter of credit (LC) or the process of getting a loan approved. Both processes should be using common authorization services and common accounting services.

Functional plan

After designing the major processes of an organization, major functional blocks can be identified. Some of these functional blocks will be offering business services that can be reused in different business processes. These business services are the ideal SOA building-block candidates. These services should have the necessary capabilities to be reused and recomposed, providing the agility required by the business. Lines of business participation in the choice of those functional blocks and the data that needs to be shared by those blocks should provide enterprise architects the necessary business knowledge to allow the canonical data models, domain UML models, and data repositories to be reused and understood by the entire organization. After that, business involvement in this plan is necessary.

This common work should lead to a common language and a common taxonomy shared holistically throughout the organization. Common entities and common domain models are defined in such a way that they have common meaning in the organization and can be reused in different lines of business. A city-planning metaphor can be used in this plan: Assembling the functional building blocks into quarters and zones relate to the different lines of business in the organization.

A common language will promote the reuse of the functional building blocks and the data that will be shared between those blocks. The canonical models should be shared in an enterprise repository. Governance considerations should define the way those models should be designed, accessed, validated, and amended. I will get back to those considerations later in this article.

Going back to our banking example, in this type of organization you may have one line of business dealing with payments, foreign exchange, and securities, another line of business dealing with loans, another dealing with import/export operations such as letters of credit (LCs) and collections, and a horizontal line of business dealing with authorizations, accounting, reporting, and risk management. Every line of business forms a quarter when applying the city-planning metaphor.

If you zoom in on the quarter of import/export, you will find the functional block related to LCs and the functional block related to collections. The functional block representing the LCs can be divided into different services you may expect of LCs. This block should provide functions (or services) such as opening an LC, amending an LC, using an LC, and reimbursing an LC. These functions are the business services of the LC block; these services will rely on functions provided by the authorization block, by the accounting block, and by the payment block.

The authorization block will offer the service of authorizing a line of credit to a client based on that client's status. The authorization block may rely on functions in the risk management block. The LC functions will also be using services provided by the accounting block and the payment block, and the payment block will also be using functions of the accounting and authorizations block.

The description on the functional plan is made in business terms, divided in such a way that it can be mapped to applications and services within applications. In the context of the banking example, the accounting services and the authorization services are being reused on the organization level.

After identifying those functional building blocks, communication between those blocks should also be defined, which means a canonical data model is defined. This canonical model can be described using UML models leading to XML representation of the data. This common language should be shared across the entire organization.

In the banking example, an account is the same whether it is used in the LC's block or in the loans block; the client is also the same. The account and client are the entities defined in the shared business models across the organization. Those entities will be represented by canonical models, one for the account data and another for client data. Those models will be shared holistically through the organization. They are accessed through common services that are part of the organization building blocks. Those services may be CRUD (Create Retrieve Update Delete) services or composed services. A good start for defining those canonical models is to refer to industry standards. The banking system uses the SWIFT standard. MT messages defined in SWIFT standards handbooks define banking operations in term of business cases using messages. Those messages can be easily mapped to XML messages that then can be used throughout the organization. Being close to the standard will help in the context of extending business operations used in an organization to B2B operations used between different organizations.

After defining those functional blocks and the data models used by those blocks, the assets should be accessible holistically to be reused by different lines of business in an enterprise repository. The BEA AquaLogic Enterprise Repository can be used for sharing the enterprise information's system assets.