Part II focuses on creating the Enterprise Integration Architecture by applying the results of Part I. Because integration-driven system development requires interplay across a diverse set of enterprise assets, it is important to put an integration architecture in place that can guide each successive implementation. Without this architecture duplication will occur, significant costs will be incurred by each application to develop its own architecture, and reuse will be difficult to achieve. The architecture includes all the services and component technologies needed for different types of integration requirements. This section will provide a structure to guide the design of your architecture.
Chapter 4—Enterprise Integration Architecture Overview
Chapter 4 is an introduction to creating an Enterprise Integration Architecture. It explains the benefits of creating the integration architecture on an enterprise level, as well as different components of the Enterprise Integration Architecture, which include the Current Integration Environment Assessment, the Technical Integration Architecture, the Service Integration Architecture, the Information Integration Architecture, and the Process Integration Architecture. The chapter also includes a discussion of organizational structure and processes for architecture governance, and best practices for creating an Enterprise Integration Architecture.
Chapter 5—Current Integration Environment Assessment
No integration project should start with a clean sheet of paper. Chapter 5 focuses on how to conduct an assessment of the current integration environment. The specification included in the chapter provides an explanation of how to perform and document a current assessment. This current assessment is also used when creating the Technical Integration Architecture Specification, contained in Chapter 6.
Chapter 6—Technical Integration Architecture
The Technical Integration Architecture Specification provides guidelines and standards that constitute the enterprise building code for all integration projects. It is the specification that all projects will reference when choosing integration technology for their particular implementation. Chapter 6 includes the specification template for the technical integration architecture. It includes tables and specifications for defining all integration technologies, integrated applications, and types of integration. It includes conceptual, physical, and development views of the technical integration architecture and a standards profile. The architecture specification template provides an in-depth section on service-level requirements, including availability, integrity and delivery service, scalability, maintainability and manageability, usability, performance, transaction services, persistence services, and directory services. It also defines different levels of security and provides guidelines for capacity planning. Chapter 6 also includes best practices for creating a Technical Integration Architecture.
Chapter 7—Service Integration Architecture
The service integration architecture represents best practice for creating reusable and agile business applications. A service represents a piece of business functionality that can run on platform, and be accessed by other services and applications. Defining services is an essential part of creating a service-oriented architecture (SOA). Chapter 7 defines the benefits of SOA, and provides an event-driven method for defining functionally cohesive and loosely coupled services. Chapter 7 contains the Service Integration Architecture Specification. The specification focuses on the service definitions and interface definitions, and provides a template for using an event-based method for defining services. The chapter includes best practices for creating an SOA.
Chapter 8—Information Integration Architecture
Information integration lies at the heart of all integration projects. However, when information is integrated merely at a tactical level, the semantic mapping of data between systems may be locked in proprietary tools and not reusable across technologies. Chapter 8 defines the importance of managing integrated data as an enterprise resource, and explains the types of metadata that are important to organizations to create an integrated, managed, and reusable information architecture. Chapter 8 includes the Information Integration Architecture Specification that contains a framework for defining information integration patterns and data flows. The specification provides a draft metadata model for integrated information and a relationship model to define integrity rules across applications. Chapter 8 also contains best practices for creating the Information Integration Architecture.
Chapter 9—Process Integration Architecture
The Process Integration Architecture defines end-to-end business processes, which are then automated across existing systems on disparate platforms. The purpose of creating the process architecture is to enable the organization to manage, measure, and improve business processes over time. This requires modeling processes, verifying processes with all stakeholders, perhaps simulating processes to optimize performance, and real-time monitoring of key performance indicators, and continuous process improvement. Chapter 9 contains an overview on why process is important and different methods for defining business process metrics and measuring success, as well as different methods for modeling processes. Chapter 9 contains the Process Integration Architecture Specification. Although we recognize that most of the process specification will be kept in a modeling tool, the specification provides a guide to defining all the important aspects of the process architecture, and best practices for creating it.
The Enterprise Integration Architecture Specifications created in Part II of the book are then used to guide the integration solutions as defined in Part III of the book.