Chapter Seventeen. Integration Systems

Everything should be made as simple as possible, but not simpler.

Albert Einstein

The integration systems competency addresses the need for managing the life cycle of integration systems as a distinct class of systems that provide a sustainable operating infrastructure to support the free flow of information in an organization in an integrated manner. Here are some of the key characteristics of a functioning integration systems model:

• There is a shared infrastructure where applications can use and share integration components with relative ease.

• A common hardware/software infrastructure is in place that can be easily scaled.

• Development standards are in place to name objects in a standard format for easy identification.

• Operational SLAs exist where there is a specific availability that matches business requirements such as high availability or fail-over capabilities for 24/7 applications.

• Service definitions such as metadata availability, expert assistance, model management, and methodology can be expected as part of the support services.

• A migration and control function is defined for moving objects easily to production.

• Backout capabilities are in place should any migration fail.

Governance of these activities is usually managed by either an Integration Competency Center (ICC), Center of Excellence (COE), or another organization chartered with the responsibility to manage the environment over and above just production support. The concept of identifying, managing, and sustaining an integration system is key to achieving the benefits of reliable data integration.

In the context of Lean Integration, integration systems are in effect elements of the Integration Factory. Recall that the Integration Factory involves problem-solving tasks, information management tasks, and physical transformation tasks. The integration systems are the “machines” that perform the physical transformation tasks for day-to-day conversion of raw materials (source or unintegrated data) to finished product—meaningful, consistent, and integrated data in the hands of the customers or applications.

Integration systems also play a key role in the information management tasks by providing information about data processed, messages transmitted, failures encountered, service levels met, and so on. Some of this data may be of interest only to the operations staff who are operating the systems or to the ICC that is governing the overall environment and driving continuous improvements. Much of it is also of interest to the customers of the integration services, especially when something goes wrong and they want to understand what happened. The disciplines for managing, controlling, and operating integration systems are an essential competency for Lean Integration and the Integration Factory.

What Is an Integration System?

An integration system is a collection of components that are managed as a unit (usually by an ICC) for the purpose of data, application, or systems integration. Integration systems are separate from, and provide a service to, other systems within an enterprise. The services may include data migration, data consolidation, data synchronization, data cleansing, data replication, extract transformation and load for data warehousing, application synchronization and process orchestration, to name just a few. This contrasts with the traditional view of integration components that are managed as part of a business application (i.e., integrations managed as point-to-point elements with custom agreements between the cooperating applications) or are not managed at all (orphan integration components).

An integration system views the integration components from a holistic perspective. It defines clear boundaries around each business application and explicitly defines all the components that collectively represent the integration system and its functions—regardless of how distributed those components might be. A core rationale for managing integration components as systems is that it provides the ability to sustain integration across applications after initial projects are completed as they invariably change over time. Integration systems are characterized by the classification of components (i.e., transformation service, integration service, etc.), their function (i.e., message conversion, ETL, etc.), and the tools interface (i.e., design-time interface, run-time interface, etc.).

Figure 17.1 shows how information exchanges between two business applications are often depicted at the conceptual whiteboard level. At a conceptual level this makes sense, but the question is “What is the line in real life?” Figure 17.2 is a simple depiction of how integration systems can be isolated from application systems. This is how the information exchange might look at a real-life physical level. In the example, the “line” is really an integration hub that directly accesses the database associated with the source system and the target system.

Figure 17.1 Conceptual view of information exchange between business systems

Figure 17.2 Example of a “simple” integration system

In the next and more complex scenario in Figure 17.3, the simple “line” in the conceptual diagram is really a complex set of interactions between multiple components. There is a separate extract program that is associated with the sales system. The load program for the finance system has, by agreement, been assigned to be part of the integration system. Note that in this example, the queues that are part of the transport network as well as the security server have also been designated as part of the integration system.

Figure 17.3 Example of a complex integration system including a variety of components

Questions that should be clarified in this example include these:

• Is the extract program part of the sales system or part of the integration system?

• Is the load program part of the finance system or part of the integration system?

• Are the queues part of the integration system (all of them or just some of them)?

• Is the security and encryption component part of the integration system?

Since a system is a purely abstract concept, there is no right or wrong answer to these questions. The important consideration is that there be an explicit definition and common agreement among the owners and those responsible for managing, operating, and sustaining each of the components. The key is to ensure that there is no ambiguity and to assign clear accountability for all components.

Integration Systems Taxonomy

Figure 17.4 further clarifies the term integration systems by showing a framework that contrasts integration systems with business systems. Business systems provide capabilities to support business functions such as accounting, marketing, manufacturing, sales, and so on. Integration systems provide capabilities to integrate the individual business systems into a cohesive whole by consolidating, adapting, cleansing, and transforming data. Integration systems also control and monitor end-to-end business processes and provide an integrated experience to users or external customers. In other words, integrations between applications are viewed collectively as a “system” rather than as point-to-point appendages of the business applications.

Figure 17.4 Taxonomy of integration systems

The six integration systems shown in the reference model are in fact a high-level taxonomy referred to as “systems families.” They in turn decompose to a more granular list of systems.

Note: There is not necessarily a one-to-one alignment between a given vendor product and one of these systems. Many off-the-shelf products provide functionality from more than one integration system category. This framework provides a common reference for classifying, comparing, rationalizing, and managing the various integration systems in an organization.

Some of the key ICC services that must be provided by the Lean team in support of the integration systems are

• Ongoing production support and SLAs for operational systems

• Migration processes that support the transition between development, system test, and production

• Data rationalization of new systems to reuse existing data and process components to achieve strong levels of integration

• Catalog services such as a business glossary of metadata for business, technical, and operational metadata

• Development and architectural support in scoping out new projects that will use the integration services platform

The goal is to manage the operations of the integration platform developed by the integration methodology competency and to sustain it as an efficient operating environment. Other items to consider include the availability of the integration platform, whether it is during business hours or 24/7 operations. As information flows naturally through an organization, the goal is to move the platform more toward a 24/7 operation.

Table 17.1 shows the integration systems maturity model adapted from ICC: An Implementation Methodology.¹ It provides a high-level framework for assessing an organization’s current level of maturity in managing integration elements in a systematic fashion and for defining a future-state target. As the level of maturity increases, the focus of design and corporate information flow becomes more vital to the lifeblood of an organization. Application delivery, operational results/support, and metadata/data governance become parts of a mutual ecosystem rather than separate entities. One goal is to have its standards and disciplines become accepted community methods rather than enforced checkpoints.

1. John Schmidt and David Lyle, Integration Competency Center: An Implementation Methodology (Informatica Corporation, 2005), p. 38.

Table 17.1 Integration Systems Maturity Model

Challenges

A number of the challenges associated with integration systems, such as funding and architectural alignment, are dealt with in other chapters. Here are several of the top challenges that are addressed explicitly in this chapter:

• Shared infrastructure demands higher levels of service: Consider these two scenarios: five separate and redundant integration hubs serving five different application teams, and one central and more efficient integration hub serving all five application teams. In the first scenario, if one integration hub is down, it impacts only one-fifth of the applications. In the second scenario it would impact all applications. Shared infrastructure requires more careful planning and sizing, increased availability, and so on than individual systems. On the other hand, consolidating systems into a shared environment often affords the organization the ability to implement high-availability and disaster recovery capabilities that should have been in place for each of the individual systems but may not have been cost-effective when considered separately.

• Maintenance upgrades are a thankless job: Maintaining a shared integration system at the latest revision level is critical, but many perceive maintenance activities as low-level, routine, and less rewarding—particularly in contrast to high-profile projects that often receive most of the management attention and accolades. Nonetheless, upgrading shared infrastructure is in many respects more demanding than project work and requires experienced and expert staff.

• New product features often don’t provide a compelling reason to upgrade: Maintaining systems to keep them at the current software patch level and supported by the vendor can be expensive, but the hard benefits of new releases sometimes don’t provide a compelling case to upgrade. Nonetheless, falling too far behind on upgrades is a risky practice and cannot be tolerated in a high-availability shared environment.

• Portfolio rationalization: The task of consolidating multiple independent integration systems (or hand-coded point-to-point integrations) into a consistent shared environment is not easy. The financial and organizational challenges that have already been mentioned are significant, but additional technical issues such as naming standards, security controls, and coordination across a complex portfolio of business systems that are constantly changing are also major challenges.

• Evolving technologies (for example, EAI—enterprise application integration—and ETL product space): The life cycle of new technologies is roughly 7 years; the past 30 years or so have demonstrated that most technologies are replaced by better, faster, and lower-cost technologies approximately every 7 years. This applies not just to integration systems but to the business systems they serve. Since it is not practical to replace all the business systems every 7 years, the net result is that integration systems must deal with a vast array of standards and must constantly stay current with the last technology that any given business system adopts.

• Systems become “disintegrated” over time: When a new integrated solution is first implemented, all the dependencies and information exchanges are well integrated (assuming the systems integrator did a good job on the project). But over time, as the individual and separate components evolve and change, the integrations can become fragile from an operational perspective and with reduced data quality. A governance organization must address the challenge of maintaining integration quality once the initial project implementation team has disbanded.

Industry Practices

With the advent of application-to-application middleware software, integration systems started to be recognized in the industry as a distinct class of systems in the 1990s. Some integration systems such as data warehouses were around much earlier, but it was the introduction of application-to-application middleware (also commonly referred to as EAI) that spurred the rapid growth in integration systems as a separate class of application systems. The general idea behind the industry trend is that custom-developed (hand-coded) point-to-point interfaces are not scalable, and at a certain level of complexity it becomes more efficient to treat the integration elements collectively as a system with its own life cycle that is independent of the business applications that are being integrated.

A related industry trend is the concept of managing systems as a service, that is, to describe the functions performed by a system as a set of value-added services and to formalize the operational commitment to provide the services in an SLA. One of the notable contributions to this idea was the work that originated in the UK known as the Information Technology Infrastructure Library (ITIL). ITIL is a set of concepts and techniques for managing information technology infrastructure, development, and operations. Of most relevance to the integration systems competency is the portion of ITIL that addresses infrastructure management. It recommends best practices for requirements analysis, planning, design, deployment, and ongoing operations management and support of technology infrastructure.

Another industry trend is the concept of ERP for IT. An ERP system is an automated solution supporting a major business process or functional area and is commonly seen in many major business functions such as finance, manufacturing, and distribution, to name just a few. The general idea is that IT also is a critical business function with complex processes associated with how it operates within the enterprise supply chain. As a result, IT should also have a formalized set of processes that are automated or semiautomated and enabled through application systems. Integration systems are a natural out-cropping of this concept, which has been widely referred to as “ERP for IT.”

Activities

Establishing an integration system capability involves a number of steps such as identifying the integration systems, establishing an ICC scope, and defining operational and rationalization procedures. The enterprise competencies are focused on preparing for the role of an ICC when applicable in an organization and building a sustaining operational model. Figure 17.5 shows the nine-step approach to achieving a Lean Integration systems capability.

Figure 17.5 Steps to establish a sustaining integration systems capability

Step 1: Define the Systems Framework

When defining a systems framework, first build the taxonomy of business and integration systems much like what is shown in Figure 17.4. This taxonomy helps to differentiate between business applications and integration systems and provides a classification structure.

The framework shown in Figure 17.4 is a recommended starting point. The primary task in step 1 is simply to gain agreement across relevant stakeholders (i.e., the ones who will use the definitions) about exactly what name and description to give to each category. Note that this reference model does not describe either the current state or the future state of the enterprise integration systems. Rather, it is a reference or common dictionary used for the purposes of classifying and categorizing IT systems.

This step should be completed fairly quickly since the value is in applying the model (there is little value in having a well-defined framework that is not used). As a general rule, step 1 should not take more than one week and no more than one to two review meetings with the interested stakeholders.

Step 2: Establish a Repository Catalog

This step involves the definition of integration metadata that a governance group will need to capture and maintain in support of the systems inventory. Metadata is the key information that helps deliver value in an organization since it describes what kind of data about systems is relevant, what the attributes are, and what its uses are within the organization.

Some of the activities involved in this step are to

• Determine what metadata is being captured from each integration system (What level of detail is needed to support integration expertise?)

• Determine what is needed to relate each subject area and attribute (What type of subjects and services support each area? What are the attributes related to each subject area?)

• Buy/install the repository hardware and software

• Configure the repository (including extending the meta-model as necessary)

See Chapter 13, Metadata Management, for more details. Services provided include a glossary of metadata of the business as well as technical and operational metadata as part of the repository catalog service.

Steps 3 and 4: Inventory Business Systems and Integration Systems

The purpose of these steps is to identify business systems and integration systems and their associated stakeholders. Relevant metadata about each system should be captured so that a governance body has a record of its constituency.

The first part of this step is to identify all of the business application systems in the enterprise. Most organizations have one or more lists of systems, but they may not be complete or consistent. For example, there may be a complete list of all mainframe systems that is maintained separately from a list of applications on mid-range UNIX systems. Furthermore, there may be differences between naming conventions and the granularity of detail recorded for the systems. For example, a mainframe application may have a three-letter acronym as its name and consist of one COBOL program, in contrast to a Web application called “Customer Sales Portal” that consists of hundreds of software components distributed across dozens of servers. Finally, the existing lists of systems may be incomplete depending on how closely the information is controlled and how mature is the process of maintaining the list. Therefore, key steps are these:

1. Gather the existing lists of application systems.

2. Identify gaps and overlaps in the list and build a single common list.

3. Categorize the systems according to the taxonomy defined in step 1.

4. Normalize the list (for example, the mainframe COBOL program mentioned earlier may be part of a larger business application).

5. Capture relevant metadata about each system.

6. Load the data into the repository.

These steps are repeated for integration systems. The inventorying of integration systems and business systems can occur in parallel, but the two are shown as separate steps because the stakeholders involved are often different.

An optional (but recommended) activity is to also identify the technologies supporting the business and integration systems. This helps to identify gaps and overlaps in technology or function within an organization.

Step 5: Clarify Accountability

An ICC, or other appropriate Lean team, should have accountability for managing integration systems. In organizations that don’t have an ICC, the responsibility may be assigned to other appropriate governing groups or to other business application support teams. The key is to ensure that there is clear accountability for business systems and integration systems in the organization.

Once the inventory of business and integration systems has been completed, there are two key sub-activities for step 5:

1. Determine which of the integration systems will be the responsibility of the ICC and which will be the responsibility of another group (such as an infrastructure group or application team). The ICC scope framework in Figure 17.6 provides a structure that can be helpful for gaining agreement across the organization.

Figure 17.6 ICC functional scope framework

2. Define the precise boundary between the integration system and the business systems it serves in terms of exactly which components are in scope (according to the taxonomy in Figure 17.4). This should include the definition of what is in a business system and what portion is the integration component. For example, some integration code embedded in an application may not be easily supported by the ICC. This step is a fairly detailed technical activity, and the results of the analysis should be captured in the repository catalog.

Figure 17.6 is a framework for defining the scope of an ICC. In its broadest context, a fully functioning, mature ICC is responsible for sustaining all internal and external integrations in terms of both initial project implementation and ongoing maintenance, support, and operations. The ICC would have responsibility for these areas:

• Application-to-application integration solutions, where much of the real-time interactions between systems are managed

• Database-to-database integration: includes a range of solutions such as batch data migration, data synchronization, data consolidation, and business intelligence, to name a few

• Business-to-business integration: addresses the needs of extreme loose coupling with customer and supplier systems, adaptation to industry standard protocols, and handling of semistructured or unstructured documents

• Business-to-person integration: addresses “integration at the glass” by managing portal solutions, content management, presentation standards, and search capabilities

• Process orchestration: involves human workflow, management of long-running system-to-system flow-through processes, and coordination of processes across channels

• Information security: implements data encryption solutions, certificate management, authorization data, and single sign-on capabilities

Note that in the center are data quality and metadata. These are arguably the most important and critical aspects of an ICC, and they are positioned in the center because they impact all dimensions of data and process integration. Data quality should be addressed at all stages of a project’s life cycle and in all types of integration solutions. In a real-time ICC it is particularly critical to establish policies and practices to ensure that data is accurate and complete at the point of entry. From a metadata perspective, this means managing data as an asset and documenting both “data about data” and “data about data processes.” It maintains information about data at rest (application databases), data in motion (information exchanges between systems), data processes such as business usage (business glossary), and governance (policies and controls).

It is rare for an organization to have one ICC that is responsible for the full scope. A more common approach is to establish an ICC that focuses on an area that presents a specific opportunity or high-priority need for the business or to implement several ICCs, each with a different and nonoverlapping charter.

It is important that boundaries be clear regarding which group will support which component. Figure 17.7 shows some example frameworks for the ICC. Each scope definition framework helps to determine the scope of support for the ICC in terms of technology. Other methods for determining scope are more organizational in nature or based on application boundaries.

Figure 17.7 Example ICC functional scope

The scope of responsibility with which the ICC is chartered needs to be clearly defined. While each of the models in the figure can be implemented, they are simply examples of the ICC scope and definition that need to be determined when defining the initial charter.

Step 6: Develop Standards

After the inventory and ownership issues have been addressed, the next step is to apply common rules about when each technology and each system should be used. The recommended way to achieve this is to define usage standards and gain agreement across all relevant stakeholders. A technology decision tree is a useful way to capture the results of the agreement (refer to ICC: An Implementation Methodology² for details).

2. Ibid.

There are a number of checklists and standards activities related to the service. Chapter 12, Integration Methodology, describes several of the activities that are needed to set up a central-services organization. The following checklist shows key areas where we recommend that ICCs develop formal standards:

• Middleware technology selection (technology decision tree)

• Shared versus federated software configuration

• High availability and disaster recovery

• Development standards and naming conventions

• Migration control of development objects

• Data rationalization of new systems to reuse existing data and process components to achieve strong levels of integration

• Catalog services such as a business glossary of metadata of business, technical, and operational metadata

• Metadata management competency

Step 7: Establish Service Level Agreements

Step 7 is focused on establishing SLAs for the integration systems that have been assigned to the ICC for management and operational responsibility. SLA management includes discussion points around the following topics:

• Defining the SLA (or operation level agreement, OLA)

• Harmonizing the needs of diverse teams in a shared infrastructure

• Formality/informality of the SLA/OLA and expectations

• Impact on the organization of a missed SLA/OLA

• Design and build of systems that allow the SLA/OLA to be achieved

• Escalation path to resolve a missed or unachievable SLA/OLA

• Maintaining service levels and operation levels for growth

Each ICC technology should have a series of SLAs/OLAs as well as documented daily procedures for maintaining operations.

Step 8: Define Operational Procedures

Step 8 is focused on defining operational procedures for the integration systems that are within the ICC scope of responsibility. The operations manual should contain a high-level overview of the system (in order to familiarize the operations staff with new concepts) as well as the specific details necessary to successfully execute day-to-day operations. For data visualization, the operations manual should contain high-level explanations of reports, dashboards, and shared objects in order to familiarize the operations staff with those concepts.

Step 9: Plan the Migration Road Map

An objective of the ICC is to consolidate, centralize, and standardize (allowing for the reuse of objects and the simplification of development and operations). To achieve this goal, a decision must be made about which tool or set of tools and processes will be used and which others will be consolidated and/or retired. A further consolidation of servers and the reallocation of personnel may occur as part of the overall tool consolidation effort.

Step 9 builds upon the results defined for the target architecture in step 6 by looking at technology gaps and overlaps and developing a road map to address legacy integration systems that don’t fit in the new target. The portfolio rationalization practice in the next section covers creating a process where technology meets the goals of the ICC so that the technology investment is efficiently leveraged both within and across data integration projects.

Portfolio Rationalization

Once the decision has been made to structure corporate integration activities into an ICC, an assessment of all software tools and their usage needs to be conducted. In this review, it may surface that the organization uses multiple tools, processes, servers, and human resources to perform similar tasks. An objective of the ICC is to consolidate, centralize, and standardize, allowing for reuse and simplifying development and operations. To achieve this goal, one must decide which tool or set of tools and processes will remain, and which will consolidate with the ones selected, and then be retired. In consolidating the portfolio of tools, there may also be consolidation of servers and reallocation of personnel. This section will cover the server and software tool consolidation efforts and in some cases refer to all these items as tools or tool sets.

There are a number of challenges regarding rationalizing this portfolio of integration tools, processes, and servers:

1. Selecting which tools and processes are a best fit for the organization

2. Retiring or managing the tools not selected

3. Migrating processing to the new tools and servers

4. Developer and end-user training

What Is Portfolio Rationalization?

Portfolio rationalization involves applying the principles of waste elimination and continuous improvement to the integration systems within an enterprise. It is applied as an ongoing process that allows the ICC to optimize the use of technologies and its features. Portfolio rationalization can be used to eliminate redundant technology or even to identify new technology gaps. The process of evaluating these tools, making the decisions on tool status, acting to migrate processing to the selected/standard tool set, managing the remaining and to-be-retired tools, and managing training on the selected tools is portfolio rationalization.

The business case for an ICC has already indicated the value of centralizing, standardizing, and consolidating integration activities. Similarly, consolidating the tool set adds to this value proposition with

1. Potential reduction in software license costs via bulk license agreements or a reduced number of total licenses

2. Reduced overhead for product training on a reduced number of software tools

3. Reduced complexity with a limited number of software tools and by standardizing on a common version of the software

4. Enabling resources to more readily provide coverage for each other, since standard methods and tools are common

5. Potential reduction in hardware maintenance costs with a reduced number of server footprints

Portfolio Rationalization Methodology

Based on the business drivers for portfolio rationalization, the ICC should initiate a process to evaluate the tools that are already part of the portfolio, as well as those that are candidates for future use. The process of inventorying the systems and tools and the selection process to define the target platform are part of the evaluation process. The same process is followed to resolve technology gaps as to select the standard tool used to consolidate the portfolio. Unused components can be retired or repurposed as they are no longer needed. This process is repeated continuously as new requirements surface and as market advances present opportunities to use newer technology.

Figure 17.8 shows the recommended seven-step process for achieving a Lean portfolio of integration systems in an enterprise.

Figure 17.8 Seven-step portfolio rationalization methodology

Step 1: Clarify the Business Needs

Document the business needs or problems that drive adding new technology to the portfolio.

Step 2: Inventory the Systems and Tools

Evaluate both in-house tools and tools that are new to the organization. Determine the best fit in terms of features, compatibility, and future potential to meet the business needs. Follow the same process of evaluation to resolve tool gaps. Current systems and tools should be classified in one of the following categories:

• Evaluation: technology that is under evaluation for use

• Selected: technology that has been selected for use but not implemented

• Standard: technology that is the recommended standard in the organization

• Deprecated: technology that is no longer standard in the organization but is still supported

• Unsupported: technology that is neither standard nor supported in the organization

• Retired: technology that has a defined exit strategy

Step 3: Define the Target Platform

Determine the classifications of the tool sets under consideration for new and existing tools, as well as tools to be replaced. Select the tool sets to use as the standards.

When technology gaps are recognized within the organization, begin an evaluation process for the tools to fill the gaps. Technology that can fill the gaps might already exist within the organization, or the resulting evaluation might require new software tools to be added to the portfolio. This situation is the simplest to manage with the ICC because consolidating or migrating the tools does not cause disruptions to existing systems.

If the ICC is mature, and the tools already exist as standards in the environment, use of these tools would merely be leveraging new functionality or capabilities. Possibly, licenses would be added to an existing contract. Perhaps the organization would leverage existing hardware, upgrade the existing hardware, or purchase new hardware. Capacity planning on the existing systems should leave room to add new applications and teams to the supported environment without reaching a capacity threshold.

If the technology you are adding is new to the organization, the infrastructure to support it within the ICC needs to be developed. Servers, processes, training, licensing, and standards will all need to developed and managed within the ICC framework. Starting from this fresh approach, new development can follow the standards and patterns put into place as the technology is introduced to developers and users.

Step 4: Select the Rationalization Approach

At this stage, tools have been evaluated, classified, and selected. Now it is time to decide how to move forward. The organization could take one of two approaches, described in more detail in Table 17.2:

1. Rationalize by attrition: Establish policies and procedures to contain any legacy components and simply build new (or modified) solutions on the target architecture. This could also be called the “self-funding” strategy.

2. Conduct a rationalization project: This is a proactive plan to shut down and migrate legacy components to the target architecture. This strategy generally requires a business case.

Table 17.2 Application Rationalization Table

The attrition approach is less disruptive to the organization because human resources remain focused on other priorities, new user training is handled at a slower pace and involves fewer people at each iteration, and outages on existing systems do not occur. However, this method moves more slowly and does not realize the benefits of reduced license cost, reduced server overhead, and other benefits of consolidating the portfolio. In fact, adding the new, shared components for the desired target systems may increase these costs in the mid-term, until a significant portion of the legacy systems have been migrated and consolidated and can be retired.

Step 5: Migrate and Consolidate

If the organization elects to conduct the rationalization project to consolidate and migrate the portfolio of tools, it needs to determine how best to do so.

Multiple versions of software tools may be in active use, and it is possible that each team has applied different standards. Bringing these disparate methodologies and systems together in a fashion that is logical and is least disruptive to the teams involved can be a challenge even when the same tool set has been used. An example of a road map that attempts to rationalize these issues is shown in Figure 17.9. End-user training, developer training, participation from the affected teams to test, and other logistics must be kept in mind.

Figure 17.9 Infrastructure migration road map

There are various scenarios for migration and consolidation:

1. Hardware consolidation using a single version of the existing software tool set

2. Hardware consolidation using multiple versions of the existing software tool set

3. Hardware and software consolidation to the defined standard tool set

Step 6: Retire Unused Components

Retire or reallocate the architecture components no longer used, remove application processing from servers, and terminate contracts for unused software. The benefits of standardizing and consolidating integration systems are not realized until the old software and servers can be retired.

Step 7: Repeat as New Business Needs Arise

As new products become available, the organization may decide to move to new standards and reclassify the existing elements in the portfolio. Portfolio rationalization is an ongoing process to evaluate and implement the best tools for the organization. As technology changes and as the organization’s needs change, continually review the approaches to software, hardware, and processing in the organization’s portfolio, and make adjustments.

Portfolio Rationalization Using the Metadata Framework

The ability to query an inventory of integration systems in order to identify waste and monitor a continuous improvement program would be possible if the portfolio were modeled within layer 1 of the metadata framework, shown in Figure 13.3. The chapters in Part III of this book have walked down the metadata framework from top to bottom, starting from the business view and working down to the physical systems, but several highly mature ICCs work from the bottom up. These ICCs effectively began with an inventory of their integration systems and an identification of the duplication and waste that existed in their hairball. By eliminating integration duplication, they freed up system resources and increased the stability of their systems, particularly during times of peak load.

While this chapter has discussed rationalizing the portfolio of integration systems, one could follow the same methodology to rationalize the portfolio of information systems. A by-product of the inventory of integration systems happens to be the inventory of the information systems being integrated. Rationalizing information systems can have potentially even bigger cost benefits than the rationalization of integration systems, but sometimes this is stepping outside the bounds of the responsibilities of the ICC.