The enterprise integration architecture provides a blueprint for both strategic and tactical integration projects. It describes all the components of the architecture. Experience has clearly shown that tactical approaches to building technical infrastructure result in higher maintenance costs and inhibit business agility. Because of this, in the past five years many large organizations and government agencies have established enterprise architecture (EA) frameworks. The enterprise integration architecture fits within the overall framework of the enterprise architecture. Priorities for building the architecture are driven by business requirements and strategies.
A strategic enterprise integration architecture can be compared to city planning. It includes a set of building codes. There is a governance body to ensure that projects meet accepted standards, and there is a process for exceptions. This approach reduces the number of technical configurations and required skill sets, thereby lowering support costs. It also ensures that current and future technology investments are maximized at an enterprise level. In some cases it is not feasible to take a tactical approach. This is especially true in any community of interest that requires the interchange of information. Case Study 4.1 describes how the state of Minnesota started CriMNet as an initiative to provide complete criminal history on suspects and criminals. It links together 1,100 criminal justice jurisdictions in the state. The whole purpose of an initiative such as CriMNet is to enable enterprise integration.
A strategic approach to building an integration infrastructure is required so the components of the infrastructure seamlessly interoperate to provide integration across business processes and rapid deployment of integrated business solutions. Despite the benefits of the architectural approach, application integration is often viewed as a technical step within an implementation project. Moreover, the integration landscape is expanding and becoming more complex. Different types of business applications require different types of integration technologies. A tactical approach to enterprise integration will result in the coexistence of many technologies that were not necessarily designed to integrate with one another. An enterprise approach enables you to reduce support costs and maximize flexibility.
Enterprise integration does not come in a box. It is a term that covers an array of technology solutions, including: messaging middleware; message brokers/integration servers with data mapping, transformation, and routing tools; portals; information integration; application servers with integration capabilities; business process integration and management (BPM); business-to-business integration (B2Bi); mobile integration; and emerging technologies such as Web services and XML. Each of these technologies has its place in the overall integration architecture. Large companies with broad integration requirements may require most or all of the above. However, the goal of the integration architecture should be to avoid multiples of each. Redundancy in integration technology components increases implementation costs (including the cost of training and maintaining multiple skill sets), maintenance costs, and the cost of change (including costs for integrating and synchronizing redundant functions and technologies).
Contrary to the usual preconception that enterprise initiatives slow you down and cost you more money, an enterprise-wide approach to building an integration infrastructure actually accelerates tactical solutions and can significantly lower maintenance costs and total cost of ownership. Case Study 4.2 is about Keycorp's results from creating strategic enterprise integration architecture (Goldenberg 2003). The results reflect what to expect when enterprise integration architecture is correctly applied in an organization. It is important to note that major decisions are made at the strategic enterprise level. The enterprise integration architecture defines how new solutions plug into the enterprise resources. Individual projects do not need to spend time and money figuring this out. They can just focus on the functionality of the business solution. As long as they conform to the defined enterprise standards, they can easily and quickly access required information and resources across the company. This is a huge benefit to project groups, and the most efficient, cost effective, and successful way for companies to implement an agile integration infrastructure.
The enterprise integration architecture is multidimensional. The component architectures most relevant to integration each focus on a different domain of the integration architecture. Furthermore, the components interrelate and interact with each other. Figure 4-1 depicts the four component architecture's domains.
The technical integration architecture defines the underlying technologies for all integration solutions. This is the basic plumbing that needs to be in place to support the other components of an enterprise integration architecture. This includes messaging, application interfaces, translation and transformation, routing, and process monitoring and management. The technologies that deliver the integration infrastructure services provide an integration grid, similar in concept to the electric grid. When you get a new appliance, you merely have to plug it in and it works. You don't have to rewire your whole house. Yet in IT, rewiring was the approach most often used. The technologies that deliver the integration infrastructure services comprise the underlying integration grid. In the past, this has been difficult to achieve due to the proprietary nature of the technology, but with the emergence of accepted standards and market pressure to make sure products work together, this has become feasible. Chapter 6 describes the Technical Integration Architecture Specification template and provides guidance for defining infrastructure standards.
The service integration architecture is a subset of the enterprise application architecture. It defines loosely coupled, reusable business services. This application architecture is the most flexible and adaptable to business change. It enables rapid application integration. Although the benefits of SOAs have been known for over two decades, it is only recently that they are being widely deployed. The reason is Web services, the first universally accepted standard interface. Companies finally feel confident in making the investment in SOA because it does not also require betting on CORBA or J2EE or .NET. The real objective is to enable any programming language, any platform, any data source or target, at any location. Although not yet fully complete or mature, Web services are the clear winner. Chapter 7 describes the Service Integration Architecture Specification template and provides guidance for defining reusable services.
The information integration architecture provides an enterprise-wide view of data contained in disparate systems. The value of the data itself is dependent on maintaining the integrity of data across systems. There is little value in propagating corruptions throughout multiple systems in a fraction of the time it would have taken with nonintegrated systems. The solution to maintaining the value, meaning, and integrity of data across applications is metadata. Metadata is information about the data. The more descriptive, accurate, and complete the metadata is, the better the integration can be. For the purposes of integration, the metadata is presented in a canonical format so it can easily be mapped back to source systems. XML is becoming the widely accepted standard canonical data format. Chapter 8 describes the Information Integration Architecture Specification template and provides guidance for defining different levels of metadata that enable faster integration.
The business process integration architecture models the business processes that cut across organizational boundaries. The purpose of integration is almost always to improve a business process and increase efficiency. The business process architecture maximizes business agility because it enables changes to business processes to be implemented quickly—at a business process level rather than an infrastructure level. The process architecture includes process models, governance of cut across organizational processes, as well as process metrics that enable the company to track and improve efficiency. Chapter 9 describes the Process Integration Architecture Specification template and provides guidelines and benefits from process-driven integration.
Enterprise integration architecture is a journey, not a destination. It needs to be an ongoing effort to continue to support the changing priorities and needs of the organization. Therefore, it requires ongoing support. This means the organization must define the organization structure for defining and managing the integration architecture over time, a governance procedure for ensuring compliance with enterprise standards and managing exceptions, and an enterprise priority-setting process for managing enterprise infrastructure implementation.
Because integration requires specialized knowledge and skills, a recommended best practice is to create an integration competency center. The competency center provides integration expertise and coordination across organizational entities. It is responsible for defining the integration architecture, maximizing reuse, ensuring compliance with integration standards, and providing arbitration when organizational issues arise regarding integration.
The success of the competency center requires high-level sponsorship, such as the CIO or CFO. The competency center must be empowered to set and enforce integration standards across the organization if they are to succeed at all. The skill sets required in a competency center include an integration architect, data steward, and business/IT analyst who will act as the liaison between different organizational groups.
Integration architecture governance includes processes for ensuring compliance with enterprise standards and a grievance or arbitration process when a project needs to go outside the standards.
Design reviews are an excellent way to ensure project compliance. During the design review the integration architect can act as a consultant to the project, as well as ensure standards are being met. The integration architect is also in the position to help optimize reuse across projects. Integration architecture design reviews are an essential best practice for long-term viability and vitality of the integration infrastructure.
However, sometimes business requirements fall outside the scope of defined standards. Therefore, a grievance process is also an important part of architecture governance. There should be defined procedures for applying for exceptions, as well as guidelines and parameters for granting exceptions to standards.
Integration projects generally involve multiple organizational groups, each with its own priorities. Therefore, it is essential to establish a formal priority-setting process based on organizational goals and objectives. One method is to create a matrix of integration projects and organizational goals and objectives (from the Statement of Purpose). Rate each integration project according to the number of business goals it will enable. As not all goals are equal, this rating system can be weighted. For example, see Figure 4-2.
Although a large enterprise is likely to have many integration requirements and require a large variety of integration technologies, no company can implement the entire infrastructure in one fell swoop. Therefore, it will always be necessary to take a tactical approach to integration. However, while meeting the requirements of a funded project, it is important to comply with enterprise building codes, to ensure maximum return on current and future technology investments.
When the enterprise integration architecture is viewed as a strategic initiative, the integration capabilities of the organization can be used more easily across multiple projects. Also, the individual projects do not need to spend the time and expense on researching and choosing technologies, a task that is becoming more daunting as more vendors and technologies are available. The enterprise integration architecture serves as the guide to all implementations and leverages the knowledge and experience of each project across the entire organization.
A crucial next step is to do a current environment assessment (Chapter 5), as shown in Figure 4-3. It is very important to understand what is already in place when defining enterprise standards or building codes.
Each integration-architecture domain has its own specification template. Companies wishing to maximize business agility, reuse, and ROI will define the architecture for all the integration domains. Companies only interested in tactical solutions may instead decide to skip to Part III of the book: Enterprise Integration Solutions.