Enterprise integration does not come in a shrink-wrapped box. Despite the promises and predications of the late 1990s, it is not a single product or technology, nor is it a final end point accomplished with a single project. Enterprise integration focuses on improving the efficiency and effectiveness of the processes that run the business. It includes improving the quality and timeliness of information and providing information on demand where it is needed, regardless of the source system. This level of business agility cannot be achieved simply by implementing integration technology on a project-by-project basis with out an overall strategy of how it all fits together. Rapid implementation of the business strategy requires an enterprise-level integration strategy. The enterprise integration strategy ultimately reduces the time and cost of managing information and IT resources.
Enterprise integration is really the natural evolution of computing. It began with networking in the 1980s, which enabled communication between computers as well as with humans, expanding the reach and capabilities of business applications. Improved database access and the ubiquitous browser followed networking, unlocking information and making access easier. The battles over architectural models and standards in these areas are now over and the focus has shifted to improving how information is shared among people and how applications and business processes are supported and improved. Enterprise integration is about laying the foundation for business agility. Like networking in the past, it is at the core of how information systems support an enterprise, and requires standards in order to be truly effective. At some point in the future every enterprise will have embraced enterprise integration in the same way that networking has become an accepted and routine part of an IT environment.
Companies that made good choices for networking and planned out how to design, organize, and use this infrastructure were rewarded with lower costs and a head start over their competition. The same is true for enterprise integration. Long-term success requires laying the groundwork to support both today's business initiatives and evolving needs. However, many companies are taking a tactical approach to integration. A study by the Yankee Group (Derome 2003) stated that enterprise application integration (EAI) demand is declining, resulting in more limited project-based integration spending. EAI implies a corporate-wide information infrastructure capable of managing complex interaction among disparate applications. This lofty IT goal, although technically attainable, has proven unrealistic for most organizations. Instead, companies are buying integration software to meet specific project requirements such as CRM or customer portal integration.
Although tactical initiatives may be the primary drivers of integration, companies that formulate an integration strategy will achieve a much higher level of business agility. Tactical solutions may reduce integration implementation costs on a per-project basis, but the long-term cost reduction will be less significant than an enterprise-wide integration strategy. Remember back to the early days of distributed computing when a project-level approach led to a lack of communication between departments, a multitude of technologies to maintain and understand, a multitude of skill sets required to maintain the systems, skyrocketing of IT support costs, an increase in IT failures, and a corresponding increase in outsourcing and packaged applications. In short, business lost confidence in their IT departments, which makes convincing business managers to invest in infrastructure more difficult, as these investments have not historically paid off. However, the bottom line is that designing for change and agility requires a higher initial investment.
Another problem is that enterprise integration is inherently complex. Different types of projects will require different integration technologies. For example, creating an enterprise portal that allows employees to view, change, and manage their health care and 401(k) plans will require a different technology than integrating electronic transactions from customers and suppliers. It is not possible to solve all integration needs with a single product or technology, nor is it possible to solve all present and future integration requirements with a single project. However, using a purely tactical approach will result in the need to integrate the integration technologies at some point. We have already seen this, and integration technology of the past is quickly becoming the legacy system of the future.
The focus on tactical solutions is the result of the combination of an economic downturn and the failure of large enterprise integration efforts to achieve a return on investment. Early failures were due to the immaturity of the technology and the gap between what vendors were promising and what they were delivering, the proprietary nature of the technology, the high costs, and the lack of suitably trained individuals. The purpose of an enterprise integration strategy is to enable the company to work smarter. Companies like CompuCredit are rethinking their integration strategies and tying them directly to their business strategies, resulting in a real impact on the business and greater satisfaction with IT. Case Study 3.1 describes the CompuCredit experience as related by Guido Sacchi. It provides a coherent and consistent approach to integration that will guide implementation decisions and reduce costs on tactical projects, while laying the groundwork for business agility and future projects. What will make the results different this time is that technology is finally catching up to support enterprise integration. Similar to networking in the early to mid 1990s, a successful enterprise integration strategy will provide a higher ROI and decrease the total cost of ownership over time.
The state of integration technology today mirrors that of local area networks a dozen years ago. Throughout the 1980s, analysts were proclaiming “the year of the network.” It was not difficult to predict that network technology would transform organizations by connecting employees and enabling sharing of documents and information far more efficiently than exchanging floppy disks, as well as expensive resources such as laser printers. However, it took almost a decade for networks to become ubiquitous and transform corporate communications. The limiting factor was proprietary technology. Vendors had their own proprietary protocols. The protocols did not interoperate. Network implementations tended to be departmental solutions. When the use of e-mail began to grow, companies realized that their networks didn't interoperate, and enterprise-wide communication across different network technologies required complex and expensive integration. The answer to this problem was standards. Ethernet and TCP/IP have become standard network protocols in virtually all organizations, solving the problem of network interoperability, and finally unleashing the full potential of networks to increase corporate efficiency of all types of communication and file sharing. What seems obvious to us today was anything but back then, when the winners were supposed to be OSI, SNA, and other proprietary protocols from Novell or Microsoft.
Enterprise integration is the next evolutionary stage of enterprise computing. Therefore, to succeed, it is important to understand the lessons of the past so we don't repeat the failures. The success of networking was due to the wide adoption of standards. The success of increasing access to data likewise revolved around the ascent of SQL combined with the emergence of the browser, HTML, and HTTP for improving human access to information. In each case there is an architectural construct, a process that has been absorbed into the IT organization, and standards that support it. In each case costs have declined dramatically and acceptance has become universal. In each case the winner was in doubt for a long time and today it has become intuitively obvious. Although few standards have really succeeded, these five (Ethernet, TCP/IP, SQL, HTML, and HTTP) are the foundations of enterprise architecture in business today. They each erased any proprietary or competing standards from the marketplace. Enterprise architectures that did not accommodate these standards were replaced over time due to marketplace realities.
We are now at a similar juncture with integration technology. Despite the plethora of technology now available, integration has yet to achieve the full potential of enabling straight-through processing and real-time visibility of transactions across applications and business units. Maximizing enterprise efficiency and competitiveness requires much more. But the answer is not to retreat to tactical solutions and give up on the goal of enterprise-wide integration. As with network technology, the answer lies in the emerging integration standards, centering on XML and Web services, which are poised to enable the widespread adoption and success of enterprise integration.
Enterprise-wide integration efforts of the past have not been fully successful because they were largely based on integrating proprietary technologies that were difficult to configure and implement, and difficult to change. It is clear that standards-based approaches are required to resolve that problem. However, simply deploying tactical solutions without an overall enterprise strategy of how they will all fit together in the future will doom companies to repeat the failures of the past.
Unfortunately, standards alone will not guarantee success and the current state of standards does not yet solve all integration solutions. Creating an enterprise integration strategy will help companies speed implementation and reduce costs by defining standards and approaches so that each project does not have to re-create the wheel for each new business initiative. Over time the architectures and process will come to be intuitively obvious, but given the nascent state of enterprise integration, some early guidance is required to be successful. The enterprise integration strategy will provide this guidance to the architectures and processes that are used to develop applications and systems. Creating an agile infrastructure that will meet current and future business needs requires an on going commitment. Competitive advantage requires an ongoing strategy that aligns technical solutions to business goals and drivers.
Although there have been a lot of early enterprise-level integration failures, many companies have succeeded in achieving an extremely high ROI from enterprise-wide integration. The models, techniques, and templates provided here are based on processes, methods, and techniques that are common best practices used in successful companies that have gained competitive advantage or significant ROI or both from their ability to leverage integration. They should be applied as a part of the enterprise integration strategy.
Create a road map. The road map should outline a strategy to make enterprise integration a successful and efficient process for the IT organization. This includes the culture, knowledge, processes, and architecture. An effective road map should cover a period of two to three years, never less than one year and never more than five years.
Create metrics for measuring the effectiveness of the strategy. There is an old business adage that you cannot manage what you cannot measure. We consistently see this theme at all levels of enterprise integration, from strategy through implementation. Although there are some common metrics like ROI and cost/benefit ratio, the best metrics at this level are those tied directly to the Business Strategies and Initiatives Specification.
Minimize redundancy. Redundancy is something that is never planned, occurs over time, is justifiable on a case-by-case basis, and is the cause of many major problems in IT organizations. Costs increase on a linear or worse basis, the ability to retain and find staff with the required diverse knowledge and skills leads to a lack of core competency in any one area, and any change results in a cascading of effort across all redundant elements, which often hampers the ability to meet business needs. The cost and complexity of redundancy is often not understood. Furthermore, it can have an enormous negative business impact. Case Study 3.2 (page 42) looks at the author's experiences working in a retail bank and the redundancy related to changing an address.
Minimize required skill sets. Maintaining multiple technologies requires maintaining skills in each. People are always the most expensive part of any system. Minimizing skill sets reduces personnel costs and maximizes investment in skills development. Defining technology standards at an enterprise level is the most effective way to minimize required skill sets.
Invest in reuse. 10% to 20% investment over the cost of a tactical solution can provide a much higher ROI in the future through reuse and business agility; the second usage of a solution can result in reductions in costs of 50% to 80% when the appropriate design is put into place. However, technology is not the core problem with reuse. Culture and processes need to support the idea of a system that supports reusability. Two key enterprise integration strategies that maximize reuse are service-oriented architectures (SOAs) and process-driven integration. (In this chapter we discuss the relevance of SOA and process-driven architectures to the integration strategy. In Chapter 7 and Chapter 9 we discuss them in more detail.)
Revisit and revise as business strategies change. Making enterprise integration a part of the normal way that business is conducted can be daunting. It often goes against the grain of the organization. It requires cutting across organizational boundaries and can add a coordination level that staff may not buy into in the beginning. As a result, the senior executives of the IT organization must lead change.
Each of these elements should be considered in the context of the enterprise integration strategy. They represent characteristics of the best companies in the industry. If we return to our Case Study of General Motors, we can see how they addressed each of these elements in Case Study 3.3 (Dragoon 1998; Moozakis 2001).
Service-oriented architecture (SOA) and process-driven integration are key strategic integration directions currently considered to be best practices in integration strategy. They are included here because they require an enterprise-wide strategic approach in order to be successful. If companies wish to reap the full benefits Web services, SOA, and process management have to offer, an enterprise strategy is required; technology alone will not provide the business benefits companies are seeking. This section defines these strategies and describes the benefits of adopting them.
Service-oriented architectures are not a new concept. They have been considered best practice for three decades. In a service-oriented architecture, business functionality is packaged as reusable services that can be accessed through standard interfaces independent of platform or programming language. However, SOAs were previously difficult to build. First, there was no consistent component model everyone could agree on. Companies would need to stake the enterprise architecture on choosing among COM, CORBA, and Java J2EE. In fact, these “standards” all competed in the marketplace, ensuring that no one would dominate or become ubiquitous, like TCP/IP is in networking. However, finally there is one standard everyone seems to be supporting—Web services. The Web service standard defines a standardized interface (WSDL), a standardized communication protocol (SOAP), a standardized message format (XML), and a standardized repository for registering and discovering Web services (UDDI). These standards enable a Web service to reside anywhere and be accessed from everywhere. Existing mission-critical applications currently on the mainframe and other platforms can be wrapped in Web services interfaces and then accessed from other applications or Web browsers. This enables business to create business services out of existing systems, and rapidly implement and integrate new functionality. Web services may finally unleash the full potential of SOA. The real benefit of Web services is creating an SOA based on the first universally accepted application-interface standard the industry has offered.
However, creating an SOA is the antithesis of the hype that surrounded the introduction of Web service technology. SOA requires enterprise commitment, planning, and hard work. It is a strategy—not a magic bullet. It is one of the cornerstones on which the architecture concepts of enterprise integration will be built.
The real-time enterprise needs to respond rapidly to business change, opportunities, and threats. This requires proactive management—responding in real-time to developments as they unfold. To accelerate business processes, reduce inefficiencies, and provide real competitive advantage, companies need to optimize, automate, and manage end-to-end business processes across applications, business units, and even enterprises.
Increasing the velocity of business processes across the enterprise requires real-time visibility into those processes. You can't manage and improve what you can't measure. Furthermore, different constituents require different levels of visibility into the process at each stage of the process. Line of business managers require a business view of the process, and IT managers require a systems view. All constituents need to see the progress of the business process in real time, so the process can be managed effectively and proactively.
However, providing this visibility is a challenge because an end-to-end business process may cross multiple organizational units, applications, and even business entities. For example, an order placed on the Web may need to touch multiple back-end systems, such as a customer-management system, inventory-management system, product-management system, billing system, and external systems, such as FedEx, for product shipping and tracking. The systems typically reside on disparate platforms, including mainframes, AS400, UNIX, and Web application servers.
Process-driven integration provides end-to-end business process visibility and management. It is one of the fastest growing areas of integration because it provides direct value to the business rather than just technical connectivity. BPM solutions typically include the following:
Process-modeling capabilities for business analysts to define the business process
Process automation, which enables process routing to be defined by events or content or other relevant business rules
Workflow for routing and managing manual tasks
Process monitoring and alerts when a process rule is violated
Some level of application integration, either through Web services, adapters, a full integration broker, or integration with another vendor's broker.
Advanced features include process simulation, optimizing processes, and running “what if” scenarios based on time and/or cost factors, and a business analytics dashboard that displays key performance indicators for the business manager based on process statistics. Business activity monitoring (BAM), which can send real-time alerts along with analytical and historical information, can help decision makers make faster and better-informed decisions. Gartner predicts that BAM will be a key spending initiative beginning in 2004, and it will become a requirement for future survival and competitive advantage (McCoy and Lheureux 2003).
BPM is also being touted as the solution for orchestrating and managing the flow of information across business services. They are highly compatible strategies and companies will want to investigate and fully evaluate both. These architectural concepts will also form the basis for the enterprise integration strategy.
The enterprise integration strategy does not end with a document produced by a committee. It is an ongoing process that must remain aligned with changing business strategies. Therefore, creating an enterprise integration strategy is not a one-time event—it is an ongoing process. Realizing this should prevent you from getting bogged down in analysis paralysis.
Creating a competency center will reduce the time it takes to create an integration strategy based on business strategies. A competency center is an organizational structure populated with in-depth expertise and processes focused on a specific topic or operational need that can be leveraged across an organization to achieve greater efficiency and improved results. An integration competency center is a centralized resource staffed with skilled personnel who perform on-going research and analysis into the possible technology options and promote integration best practices. This group is in the best position to compare and contrast alternative strategies, and can reduce the time this process takes for individual implementation projects. Although important, creating the integration strategy need not be a large task. Even for a large enterprise, several staff-weeks should suffice. The schedule depends not so much on the time required to create the strategy specification, as on the time required to present it to various stakeholders and secure their approval. Depending on the scope of the enterprise, this process can take from one to three months.
The Business Integration Strategy Specification is the document that maps business requirements, strategies, and initiatives to integration strategies and projects. The integration strategy specification can be created on either an enterprise level or a project level. As stated previously, companies will be able to leverage work and investments done on each project if the work is at least owned and managed by an enterprise group. To see the complete Enterprise Integration Strategy Specification, see Appendix B.
The introduction should be a short executive overview of the specification. It should begin with a tie back to the business strategies and initiatives and how this will support these needs. In addition, any major constraints, such as limitations imposed by legacy systems or the requirements for high security, should be addressed if they are major factors in the integration strategy. Some background on integration within the organization and any major benefits that would occur as a result of the strategy would be helpful. To create the introduction, answer the following questions:
How will the integration strategy support business needs?
Are there any major constraints, such as limitations imposed by legacy systems, or requirements, such as the need for high security, that are a major factor in the integration strategy?
What are the anticipated benefits of the strategy?
At the end of the introduction the reader should have an understanding of what, why, and how the integration strategy evolved.
The scope defines whether this strategy covers integration across the entire enterprise, a division, a line of business, or some other scope. The scope of the integration strategy is determined by the business initiatives defined in the business strategy. For maximum ROI and long-term agility, we recommend that the scope of the enterprise integration strategy be enterprise-wide. However, we also recognize that each individual business initiative has a unique scope relative to the business units, applications, data sources, and system user roles. For each type of initiative, different methods of integration and technologies are required. These include data synchronization, application integration, legacy integration, desktop integration (portals and mobile applications), and business-to-business (B2B), including traditional EDI, to XML point-to-point messaging, to complex supply chain integration. The later chapters of this book discuss integration strategies for different types of business solutions.
This section identifies the key stakeholders of the plan, including business managers and executives who contributed information, and team members who created the strategy. Key participants in the integration strategy should include all those responsible for defining infrastructure requirements and standards. Companies seeking to maximize leverage in infrastructure investments have an integration competency center and/or central architecture group. However, in the majority of companies, currently this task is most often distributed among development groups. Without a centralized strategy the likelihood of redundant components is high, raising the cost of both infrastructure maintenance and business change.
As previously stated, a successful business integration strategy does not end with a document produced by a committee. It is an ongoing process that must remain aligned with changing business strategies. Therefore, the process of creating an integration strategy is not a one-time event—it is an ongoing process. It is best to have a centralized group create the integration strategy with heavy involvement with business managers responsible for the business strategy. Different companies implement the function in different ways. In some companies a virtual team “revisits” the strategy periodically. Other companies put it in the domain of the enterprise architecture group. Due to the high number of integration failures in the past, it is becoming a recommended best practice to create an integration competency center.
Although this group can be a part of the enterprise architecture group, integration is a complex technical discipline in itself, and the breadth and depth of emerging technologies and standards warrants specialization. The competency center is responsible for defining standards for communication transport, application interfaces, message formats, messaging models (publish/subscribe, message queuing, request/reply), message routing (workflow, content-based routing, event-based routing), data translation, and transformation. By centralizing the responsibility for data translation and transformation, the company can leverage and reuse one of the most expensive and time consuming and complex tasks of integration—understanding and mapping semantic meaning of data between and among applications.
However an organization decides to implement the role of making these critical integration decisions and recommendations, the group charged with creating the strategy is responsible for ensuring that all IT decisions meet the strategic goals of the organization, with an eye to providing a return on investment. It must be noted here that when the group charged with creating the strategy has no power to ensure compliance of implementations across the organization, they tend to be less successful. When they have a seat on the board that controls the budget, and establishes or approves business metrics for each IT project funded, they are more successful, because they can enforce enterprise standards and strategies. The competency center or strategy group should be a catalyst for business innovation by making the business aware of the opportunities technology creates.
The template defines three types of participants that should be identified in this section:
This section identifies key possible strategies based on best practices, testing, and experience. These strategies are listed in the Integration Strategies Table (Figure 3-1). Strategies the company should consider are how to manage redundancy in both technology and skill sets and how to manage reuse. Although the cost savings are high for doing so, technology alone will not deliver any of these savings—it requires an enterprise approach. In fact, the purpose of defining an enterprise strategy and managing and updating the strategy over time, is to maximize IT investments and increase business agility. For example, an SOA strategy is highly recommended as a best practice and can deliver big pay offs over time, but success depends upon a strategy for reuse and an enterprise commitment to the approach. Although process-driven integration has the potential to deliver a very high ROI, the true value will come from optimizing and automating cross-organizational processes. These are the processes that are most difficult to manage. Therefore, again, an enterprise-wide approach will achieve the best results. You should also define how the integration infrastructure will be implemented. Will the company take a utilities approach to building an enterprise infrastructure that will enable interaction between all systems, or will it take a tactical approach for achieving the strategic vision? Lastly, the long-term benefits of creating the strategy depend upon periodically updating it to keep it aligned with the business strategy as it evolves. To ensure that this happens, the company should define the strategy life cycle and determine whether to perform regular periodic reviews (every 6 to 12 months), whether changes in the business strategy will trigger a review of the integration strategy, or whether funding of major projects will trigger the review.
The purpose of the business integration strategy is to provide a tie between the needs of the business and the implementations by IT. It ensures that there is a match between what is desired and what is provided. This section provides a mapping between business initiatives defined in the Business Strategies and Initiatives Specification and integration strategies in the form of a matrix, shown in Figure 3-2.
Discuss nonobvious points of support. If any row or column is blank (i.e., a business strategy has no integration strategy to support it or an integration strategy supports no business strategy), discuss the implications. Any budgeting for projects that has been done to date or expected allocations should be included at this point. This budget figure reflects the IT organization's portion of the budget allocated to this initiative.
By following matrix relationships between the business strategies defined in Chapter 2 and the IS strategies presented here, you can map business requirements to integration requirements. You can also prioritize infrastructure investments by ranking projects based on importance to the company.
This section describes the approach that the organization feels will be most effective in acquiring any technology. It should set the philosophy, constraints, and approach to sourcing. Issues to be dealt with are the existing relationships and current use of technology, vendor preferences, best-of-breed versus single vendor, and responsibilities for identifying, selecting, and negotiating contracts. It should define the following:
Preference for sourcing approach. This can include best-of-breed, single vendor, or platform approach, or choosing two or three preferred vendors. The benefit of a best-of-breed approach is that companies can easily take advantage of evolving technologies. The disadvantage is that it increases the training and skills required to implement and maintain the solution. The advantage of a single vendor strategy is that the company will have the greatest leverage in negotiating enterprise purchases. The disadvantage is that a single-source strategy puts you at the mercy of one vendor. Some companies mitigate this risk by choosing a limited number of strategic sources, between one and three, for each type of technology component. The sourcing approach may relate back to the strategy for minimizing skill sets, defined previously in the integration strategies section.
Preferred vendors. This includes preferred vendors for each type of technology or for the entire platform, depending upon the approach defined previously.
Procurement process. This part of the specification may point to another internal document.
The standards section (Figure 3-3) is arguably one of the most important sections of the integration strategy. Standards reduce costs and increase reusability and agility. They prevent dependence on a specific vendor or technology. Standards are able to accomplish this because they are available for any vendor or organization to implement. By using the standards, organizations can rip out one product and bring in another that supports the same standard. The reality is that this is possible, but there is almost always some rework required. However, this rework is significantly less than if standards were not applied. Standards help preserve IT investments. This is also one of the hardest sections to develop in the integration strategy specification.
Standards often get either too much attention or not enough. The intention of this section is to define an enterprise strategy for how different types of standards will be used in the architecture. This strategy forms the basis for the integration architecture.
The standards that can be defined in an integration strategy include the following:
Standard communication protocols and technology. These may also be defined for different types of integration projects. For example, for internal application integration the standard communication protocol will most likely be TCP/IP or other network protocols prevalent in the organization. Messaging lies at the heart of the application integration infrastructure. Companies may choose to standardize on vendor solutions such as IBM MQ Series, Software AG EntireX Communicator, or Tibco Rendezvous, or on a messaging standard such as JMS (which most vendors also support). For B2B integration, EDI may be standard for larger partners communicating via a virtual private network (VPN), and Simple Object Access Protocol (SOAP) may be standard for smaller vendors communicating over the Internet. Defining and documenting these decisions as part of the strategy will prevent companies from repeating the mistakes of history and having to integrate different messaging systems across the company.
Standard Application Interfaces. One of the early benefits of EAI technology was the prepackaged application adapter that provided faster connectivity to applications. However, each of these adapters was specific to the vendor. Moreover, some of the larger EAI vendors grew by acquisition, and their process integration server required different adapters than their application integration server or their B2B server. Companies looking to implement enterprise solutions were finding they needed to install and configure multiple adapters for each system, which quickly eroded the benefits of “packaged” adapters. The Java Connector Architecture (JCA) is a standard specification for creating adapters that can be accessed from any Java application. Alternatively, many companies are choosing to create Web service interfaces to existing applications as part of a strategy for creating a standards-based SOA. This is the approach the authors highly recommend.
Standard Message Formats. This is an area where history is repeating itself in a positive way. In the early days of networking, TCP/IP was considered too “heavy” a protocol for general use. However, the benefits of having a single protocol capable of communication across platforms soon outstripped the negative impact of larger packets. Besides, the networks just got faster to accommodate them. The same is true of XML. Although some say it is overly verbose for some applications, the benefits of having a standard message format that can be interpreted by any system that supports the standard outweighs any reasons not to use it. For this reason, XML is fast becoming the de facto message standard for both internal and external communications.
Standard Process Models. A business process model represents the knowledge of how the business operates. In the case of end-to-end business processes that cut across organizational boundaries involving multiple line-of-business managers responsible for different parts of the process, the model may in fact be the only documentation of how the process is managed across the organization. The time and money invested in creating, automating, managing, and optimizing the model is significant. Companies need to retain the value of that investment by maintaining the models and knowledge within the models. These long-term benefits will provide significant payback to companies in the future. This means the models should not be dependent upon a particular technology or vendor. The benefit of standards-based modeling is that it makes it easier to maintain and change the in formation in the model over time, and it makes the model more technology independent.
There have been a number of competing process-model specifications, but various process-standard groups and vendors are coming together behind BPEL, which stands for business process execution language. BPEL is an amalgamation of XLANG from Microsoft and WSFL from IBM, and supersedes both. Microsoft, IBM, and BEA joined to submit BPEL to OASIS, the international standards body. A competing specification has been proposed—Web Service Choreography Interface (WSCI), created by SAP, Sun and BEA; but BPEL seems to be emerging as the clear front-runner. The good news is that agreement on a unified process model also has important implications for companies currently building composite applications using Web services. Composite applications require process orchestration among the different application components or services. For these applications to be portable across technologies, a primary benefit of Web services, the process definition should also be portable.
A process standard will enable companies to retain and reuse the business knowledge represented in the model, including the process rules, flow of control, and management metrics. The standard will also enable organizations to consistently manage and optimize business processes, and implement business change rapidly.
Metadata Standards. One of the most difficult and time consuming integration tasks that cannot be automated by any technology is determining the semantic meaning of data within applications to enable data translation and transformation between systems. For example, System A may have a data entity called Customer. System B may have a data entity called Client. Although a person may be able to easily recognize that these are the same, a computer could not. However, it gets much worse. Understanding semantic meaning of data in some systems may actually require in-depth detective work. For example, financial institutions have many systems that track information about securities. However, each system may track different information about that security. Synchronizing information across these systems is not a mere matter of matching entity names. It requires parsing the information and delivering different data to each target system. Companies need to leverage metadata across systems. This can be accomplished by creating standard metadata definitions—an enterprise vocabulary—and managing them centrally. This is one of the central roles of an integration competency center.
The time, effort, and cost of creating an integration strategy should deliver a high return on investment to the company by maximizing reuse of existing systems, process models, and data definitions. Defining standards reduces the cost of creating system interfaces; minimizes redundancy, which lowers the total cost of ownership; and lowers the cost of maintaining systems by reducing the skill sets required. The integration strategy should also increase business agility by enabling rapid change within the company.
All of these benefits and goals can be tracked and measured, and the metrics used to measure the success of an integration competency center or strategy group. Metrics should be defined that measure the success and relative value of an integration strategy, tracked over time, and used as input when refining the strategy and determining future infrastructure investments. To be of use, each metric must be measurable and manageable. The effort to collect and track a metric cannot exceed the value of the information it provides. Owners are responsible for tracking and reporting on metrics. Specific metrics that can be employed include tracking reuse, tracking the time needed to implement new solutions or implement changes to existing systems, tracking savings resulting from reducing redundancy, and monitoring Total Cost of Ownership (TCO) of a system, as shown in Figure 3-4.
The risk section defines everything that can or might go wrong. It may also include a list of assumptions that might be wrong or need further information to be validated. This includes the organizational, cultural, technical, or management challenges and ability to achieve the desired business results, as shown in Figure 3-5. Each risk should be associated with a plan to mitigate the risk.
The goal of the integration strategy is to reduce long-term TCO and increase business agility and competitive advantage. This requires a strategy that does more than simply react to current business needs. Companies must identify the strategies by which the enterprise can use technology to maximize competitive advantage. The key questions addressed in the integration strategy include
What are the best and most innovative practices in the enterprise's industry?
What are the best and most innovative practices of successful agile enterprises?
What are the potential benefits and costs of a specific integration strategy?
What are the technical and marketplace risks associated with the integration strategy?
How do we measure success and improve the strategy?
A successful business integration strategy must be tightly aligned with key business strategies and requirements. Management buy-in is essential. Most importantly, to be of practical value, the business integration strategy must enable a strategic approach to tactical solutions. A metaphor for a solid business integration strategy is, “think globally, act locally.”
Ignoring any of the above key questions would pose risk to the success of both the strategy and the company. The approach defined here is designed to largely mitigate these risks, and accelerate tactical solutions while building enterprise agility.
After creating an integration strategy, the next step is defining the integration architecture, as shown in Figure 3-6. Part II (Chapter 4, Chapter 5, and Chapter 6) describes how to create integration architecture and define an architecture specification.
