A common mistake made in many organizations is to start their enterprise integration architecture activity with a clean sheet of paper. This is neither feasible nor desirable in almost any situation. The current architecture, whether efficient or not, is the starting point for any activity. In fact, the main point of any integration architecture is to allow for reuse of the current IT assets for the use of new business functions. Also, existing software might be employed as part of the overall architecture.
This chapter is about how to structure your assessment of the current environment. It describes the major categories under which integration technology and approaches may exist in the organization. However, the complexity and lack of standards in the world of integration have led to many innovative approaches within organizations, and you may have others that fall outside the norm. These should be captured as well. In addition, the specification described provides a mechanism to take the classifications and document the findings for use in the enterprise integration architecture definition.
The current integration architecture assessment identifies all integration technology currently installed in the organization and applications currently integrated. The current assessment is useful in determining preferred technology components and associated vendors in the final enterprise integration architecture.
Integration vendors typically like to define their solution set in terms of a neatly ordered stack. Although the stacks of each vendor and analyst group differ slightly, a typical stack might look like Figure 5-1.
Unfortunately, integration technologies do not actually get deployed in a neat stack. Vendors often do not implement the whole stack and the manner in which they package the offering does not allow it to be used in a plug-and-play approach insinuated by a logical architecture. More often, the pieces of the infrastructure are deployed across the enterprise on different platforms, often coming from multiple vendors, and these technologies need to interact with each other. Figure 5-2 (page 78) depicts the components of enterprise integration architecture as they are more typically implemented in the organization.
At first glance, Figure 5-2 looks jumbled. That is because of the potential and likelihood that each of the components may call upon the services of other components of the infrastructure. In reality, enterprise infrastructures are even far more jumbled and complex than this diagram. This should be a convincing argument for an enterprise approach to an integration infrastructure.
Looking at the current environment with an eye toward the most common categories of integration software is a good way to structure your assessment; it can also accelerate the process. The most typical categories of software used to accomplish integration are messaging systems, integration brokers (also called servers), application servers, packaged application integration, enterprise service buses, data integration tools, adapters and interfaces, information integration technologies including the new enterprise information integration (EII) offerings as well as enterprise content management (ECM) with integration and workflow capabilities, enterprise and Web portals, B2B integration, BPM, and security integration. Point solutions, legacy middleware, and custom coding round out the most common technologies used in integration.
Each organization is different in its current approaches to integration. Although there may be obvious patterns that exist between different organizations, the selection of technology to implement an integration solution is often based on the knowledge and background of the person responsible. A Java developer is likely to select the use of an application server or portal for integration, while a mainframe architect would be more comfortable with a messaging-based approach. An enterprise architect would look at more all-encompassing solutions, like integration brokers, and still others from a business-analyst background might be more comfortable with a business process management toolset. The same problem would be addressed in very different ways in an organization. Capturing this information is important for putting in place a consistent set of guidelines. Chapter 6 through Chapter 9 will help to put in place the architectural framework for enterprise integration architecture. Part III of the book focuses on how to choose technologies for a specific integration problem. Patterns are identified and appropriate architectures are described more fully in Chapter 10 through Chapter 13. With this in place, then the organization is guided by an architecture and patterns to efficiently solve integration problems rather than the nuances and backgrounds of the staff assigned to any particular project.
The Current Environment Assessment Specification is the document that details the investments and usage of integration technology in the organization. It can have a variety of fundamental uses to the enterprise. First, it helps to understand where the points of investment leverage exist to reduce the costs of the enterprise integration architecture going forward. Second, it can be used in the design of any new application that requires integration to reuse what has already been completed. Finally, it is effective documentation to understand the investment in integration to date and justify any future enterprise-wide investments. See Appendix C for the full Current Environment Assessment Specification Template.
The introduction to the Current Environment Assessment should be a short executive overview of the specification. It should define the types of technologies that are being defined and any major constraints in the current environment, such as limitations imposed by legacy systems or the requirements for high security. Also, identify any known issues in the current environment. To create the introduction, answer the follow questions:
What is the current role of integration technology in the organization?
How is the current environment meeting business needs?
How is the current environment failing to meet business needs?
At the end of the introduction, the reader should have an understanding of the current state of integration technology in the organization.
The purpose of the Current Environment Assessment is to document and assess the current integration technologies that support the business functions of the enterprise. This assessment will be used when determining recommended technologies and vendors in the Technical Integration Architecture Specification.
The key participants of the Current Environment Assessment include the team responsible for the creation of the current environment assessment in its initial form, as well as for any ongoing improvements. Anyone that provided information or review should be included in this section. Lastly, identify the audience of this document and how they will apply the current environment assessment to their work. The audience includes senior IT managers and those who are responsible for creating the enterprise integration architecture and defining integration standards within the enterprise.
The scope defines whether the current assessment of integration technology covers the entire enterprise, a division, a line of business, or some other scope. We recommend that the company have a complete inventory of all integration technology and applications currently integrated across the enterprise.
Define all integration technologies currently used within the enterprise and all applications that are integrated using the technology. The purpose of this section is to take a complete integration infrastructure inventory.
The categories listed in Figure 5-3 are intended to be a guide to most of the common technologies or approaches. These should be tailored to the organization. For example, we combine data, information, and content integration into a single category. If organizations have developed a highly sophisticated information and content integration portfolio, each of these areas might be broken into separate categories. This is also true of the packaged application integration area where it might be broken up into categories based upon specific Enterprise Resource Planning (ERP) packages such as SAP or PeopleSoft. These decisions should be based upon the complexity of the environment in any category.
Older middleware approaches that are still being used can be captured at the end. An example of this would be the use of the Distributed Computing Environment (DCE). Also, point solutions that solve a specific problem should be identified. Finally, if the organization is using another approach including a fully custom-developed capability or hand-coded interfaces, this should be captured by adding this new category to the list provided.
The objective of this section is to determine which applications or data sources already have installed adapters or other interfaces (see Figure 5-4). Application and data source interfaces can include hand coded custom interfaces; application APIs; packaged adapters from integration vendors, or other third-party vendors;
Web services; or other component interfaces. This inventory should also determine whether the interface is reusable for other integration projects that may involve that application or data source.
After creating an inventory of each application that is integrated, create a matrix of integrations between applications, data sources, or users, as shown in Figure 5-5. This matrix will detail the level of integration between each.
Each of these connections may have been part of a separate tactical integration initiative, so the full scope of integration for each may not have been otherwise documented.
This diagram is a graphic representation of the integration matrix. It will graphically depict the scope and complexity of the connections between integrations.
Figure 5-6 (page 84) is a simple example that you can use. However, any notation that you are comfortable with can be used. This simple notation shows the component name and the connectivity with other components as well as the nature of the connection.
This section defines the security capabilities currently installed and the technology used to deliver the level of security. The specification summarizes the type of security usually required for each type of application, and specifies the current applications in that category and the technology implemented to deliver the required level of security. For example, internal data usually requires authorization. However, for more sensitive data confidentiality (encryption) and authentication might also be required. Figure 5-7 (page 85) is a simple example you can use to document your current security configuration.
This section is a summary of all key discoveries found during the assessment process. This should include any areas of risk identified, such as holes in security or hand coded interfaces, and what will not scale and cannot be easily changed. This section should also note any areas of technical redundancy, such as multiple messaging technologies or multiple integration brokers already installed. Finally, any current problems that involve end users' use of the existing systems should also be captured.
Aim to minimize redundancy in the infrastructure. Redundant technologies ultimately increase the maintenance costs, personnel costs, and the total cost of ownership.
Simplify wherever possible. Identify areas of overlap where technologies can be retired.
Identify system owners while creating the assessment. This is an essential step for both optimizing business processes and improving data quality across the organization. It also helps identify key participants in the architecture process.
Update the assessment when the architecture changes. The current assessment can be used as inventory of infrastructure technology.
Although the current assessment can actually be done concurrently with the enterprise integration architecture, it should take far less time to complete. Therefore, the next step is to complete the enterprise integration architecture (see Figure 5-8). The current assessment should provide input into the architecture, especially when defining preferred vendors and technologies.
