Service Integration Architecture

The Service Integration Architecture defines business applications as reusable, easily changed components of business functionality, and how these components interrelate. This is the concept of a service-oriented architecture (SOA). While SOA has been considered a best practice for over two decades (see sidebar), until recently, very few companies were interested in them. Now SOA is suddenly a hot topic in IT, and at the center of many initiatives aimed at increasing business agility. At this point, if your company is not at least investigating SOA, it should be.

To continue reading for free, register below or login

Requires Membership to View

To read more you must become a member of SearchManufacturingERP.com

In a SOA, discrete business functions or processes are created as independent components with standard interfaces which can be accessed by other applications, services, or business processes, regardless of the platform or programming language. These services can be flexibly combined to support different or changing business processes and functions. It supports the creation of composite applications, which can be quickly assembled from existing and new services.

In the past, companies had to bet the business on CORBA, J2EE, or .NET to create a SOA. But most large companies use all of the above. The risks and costs of standardizing on one outweighed the potential benefits of SOA. This accounted for the low adoption rate. But Web services have significantly altered the value equation of SOAs. Web services are the first universally accepted standard because all the major vendors can, in theory, support it. They work with .NET, J2EE, and CORBA (as long as everyone sticks to the same version of the standard). Despite some areas of the standard that are still immature,Web services and XML have significantly removed the risk barriers for adopting SOA, making the benefits far outweigh the risks.

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 businesses to create business services out of existing systems, and rapidly implement and integrate new functionality. Using Web services, companies can begin creating an SOA by leveraging existing investments and incrementally adding new functionality. SOA is the architecture that will best enable long-term business agility because it supports reuse, and rapid deployment of new solutions.

The concept of SOA began in the early 1980s and was embraced by the networking and object-oriented programming communities. In 1983 the Open Systems Interconnect (OSI) Reference Model was adopted by the International Standards Organization (ISO) as a common reference for the development of data communication standards. It defines the functions of data communications in seven layers. Each layer defines a communication service, and each service has a clearly defined interface with the layer above and below it. This SOA has passed the test of time. While the technology and capabilities in each layer have changed dramatically, the architecture itself stands. As long as the interfaces between services remain the same, the services themselves can be changed easily.
The Open Software Foundation (OSF), the group responsible for the UNIX standard, developed the Distributed Computing Environment (DCE) based on a service-oriented architecture. DCE provides infrastructure services for distributed computing, including authentication and security services (Kerberos), directory services, remote procedure calls, and file and management services.

CORBA is a vendor-independent architecture and infrastructure defined by the Object Management Group (OMG) that enables computer applications to work together over networks using the standard protocol IIOP. CORBA enables interoperability across platforms. CORBA applications are component-based.

The most current component technologies are J2EE and .NET. J2EE is a component-based platform that manages the distributed infrastructure and supports Web services to enable interoperable business applications. It is currently the most widely deployed component model.

.NET is Microsoft's implementation of a Web services architecture, which enables the legions of Microsoft programmers to create Web services in the programming languages they are most familiar with. This preserves a very large investment in existing skill sets. J2EE programmers are usually more expensive than Microsoft programmers.

• Enable business agility. SOA is the best way to enable business agility. It maximizes leverage of existing resources while minimizing the time and cost of deploying new applications. Rather than developing applications from scratch, companies can utilize exiting functionality and create new solutions by assembling component applications from existing and new functionality. This enables rapid deployment of new solutions.

• Provide higher return on investment. Companies that define reusable business services and create or wrap business functionality as standard services will maximize their IT investments, through reuse and leveraging existing assets.

• Enable IT agility. Standard service definitions can provide a layer of abstraction for business services. A service can run anywhere and be accessed from anywhere. Therefore, a company can easily change location or technology of the underlying code.

• Reduce training costs. Business services can be encapsulated and abstracted in a way that makes them easy to utilize and assemble into component applications with minimal programming. Companies can utilize more skilled programmers for creating the underlying functionality and service definitions, which can then be reused by less technical programmers and visual application assembly tools.

• Reduce the cost of testing and bug fixing. Each service is like a black box that performs a specific function and has a published interface that accepts defined inputs and produces defined outputs. Each service can be tested individually, then reused over and over again. Interface testing is fairly straightforward, and can be automated using testing tools.

• Support multiple client types and platforms. The SOA offers a layer of abstraction from the underlying platforms. This makes it possible for multiple types of end-user devices, including browsers and mobile devices such as pagers, cell phones, PDAs, and other specialized devices to utilize the same business functionality and have information communicated to different devices. This platform independence provides great savings for large companies that have a myriad of technologies in use.

• Speed development time through parallel development. Different programmers can independently work on different services because each service is self-contained and does not depend upon the state of another service. As long as the service interfaces are well-defined at the beginning of the project, and programmers know what to expect from other services, they can easily define and create services independently. It used to be said that past a certain point adding more programmers to a project increases development time. This is no longer true with SOAs.

• Increase scalability and availability. Because SOA offers location transparency, there is the potential to increase scalability by adding multiple instances of a service. Load-balancing technology would dynamically find and route the request to the appropriate service instance. Likewise, if there are multiple instances of a service on the network, and one becomes available, software can transparently route the request to another instance, thereby providing better availability. This is more the case for new services built on application services, and not legacy functionality that has been wrapped in Web service interfaces.

What makes SOA so compelling is that it can be done on both a large and small scale with the same benefits. Texas A&M University was able to demonstrate these principles in the development of their online class-registration system described in Case Study 7.1 (Software AG n.d.). This application was a small step in the application of SOA with a big impact.

Ultimately, SOAs will become the way most organizations build their IT infrastructures, because it is the best and only proven way to provide long-term agility. However, it will take some time and investment to get there. To date, most of the industry focus has been on solving the considerable technical connectivity problems. However, the larger hurdles to truly enabling business agility through SOA are in defining, building, and managing reusable business services.

Texas A&M University has been a real leader in the application of technology to supporting the mission of the university. As one of the world's largest educational institutions, improving services to the students—especially during registration—remains a high priority.

A service-oriented architecture using Web services is well suited to provide improved registration and ancillary services to students that expect more electronic services and less time standing in lines. So a decision was made to implement an online service. The IT department developed their class-registration system using Web services and two staff and was able to deliver a system in three months. Most of the service was provided by the existing Cobol and Natural programs running on the mainframe. They were tied together into Web services using EntireX Communicator. It was estimated that using this approach and technology there was a saving of over 50% in development time compared to prior similar efforts in the department.

During registration, thousands of students were served simultaneously and efficiently. The impact to the university was a higher degree of satisfaction by students and a significant reduction in phone calls for the university staff.

To date, the majority of the focus on SOA and Web services has been on the technical details of defining interfaces. While the standard interface definition is the critical enabler of the system, the bottom-up approach has its limitations. If the focus is only on the interface specification, and not on how to define what functionality to expose as a service, companies will not reap the full benefits of an SOA. Increased business agility and decreased costs are dependent upon well-defined, well-managed, reusable services that are fast and easy to connect to.

Unfortunately, there is no mathematical theory or methodology that can tell a developer whether the component or service is at the correct level of granularity to maximize reuse. The most commonly used method of creating business services is the trial-and-error approach. This usually means defining services in the context of a particular business process, then revising for reuse in the next solution.

A top-down business approach to defining services will enable companies to better meet the current and future needs of the business. It starts with the business requirements. Each service should provide the functionality to meet one or more business requirements, and the set of functions should be closely related. This is called functional cohesion. However, the services should be loosely coupled. The processing within one service should not be dependent upon the state of processing in another. A service abstracts the functionality from the underlying technology.

In truth, to get the job done, both bottom-up and top-down methods are necessary. The top-down approach yields a level of abstraction that is necessary to create business agility. However, at some point the model needs to meet the technology, and the services need to be implemented as components or collections of components. Companies will continue to build components from the bottom-up to encapsulate business services. The key is to make these components functionally cohesive to avoid overlapping functionality and loosely coupled to enable rapid change and to minimize the impact of change.

In this chapter we offer a top-down event-driven method for defining discrete business services that can be used on a project or enterprise basis. Defining business requirements in terms of business events offers a number of advantages. First, event-driven service-oriented architectures provide the most agile systems. In the ebizQ webinar, "Creating the New Enterprise Agility: Service-Oriented and Event-Driven" (http://www.ebizq.net/expoq/events/event39.html), Roy Schulte, VP Gartner, stated, "agility generally involves event-driven business practices, facilitated by service-oriented architectures." He used the analogy of trains and trucks to describe the agility of SOA. "Changing a truck's direction is easier than making a train go where the tracks don't. If you want the train to move over one foot, you have to do an immense amount of work tearing up and re-laying tracks," Schulte said. "On the other hand, all you need to do to turn the more agile truck is move the steering wheel." SOA is the architecture that provides the wheels for the agile enterprise.

Second, business events are a good way to design services because they are easy for business users to understand, identify, and verify in a design. They represent the essential activities of the business. One of the best ways to ensure maximum reuse of a service is to have an interface design review, so all stakeholders can evaluate whether the service will meet their needs. This is the process used by OASIS to develop standards. When companies adopt this practice, the services are more likely to meet a wider range of needs. Business stakeholders are better able to define and verify business events and required system responses, than technical interfaces. The event responses define the requirements for the interface design.

Finally, defining the business events the system will capture and respond to clearly defines the boundaries of the system. This is essential for ensuring successful and rapid implementations. The event responses are further decomposed into sets of functionally cohesive system responses. These responses may be supplied by exiting systems or new development. The service may be an integrated interface to a set of responses supplied by different systems that need to be coordinated. A service can itself provide different levels of abstraction. The service can also be a single function provided by a component or application. Focusing on business events and required responses provides a business-oriented approach to defining the SOA. This method is described in the Service Integration Specification.

Some have called the process of creating reusable business services similar to cooking waffles. You need to throw the first one out, and it gets better over time. While it is certainly an iterative process, this specification will provide guidelines for creating reusable services. A full copy of the specifications is in Appendix E.

This SOA Specification provides architecture and design guidance for applying a service-oriented architecture approach to integration. This document defines the events, services, and components. It is the design and architecture specification for the development of the services and components.

The scope of this specification is defined by the scope of the project. It documents the architecture and design for an SOA approach to an integrated solution. The scope of this specification should describe the scope of the application or system that is being designed.

This section should define the stakeholders who can verify the business events, services, and interfaces; the development team who will execute the implementation of the design; and the team responsible for the architecture and design. Any other participants or stakeholders should also be identified, including their roles.

The Business Events section defines the business activities that the system must support. A business event is something that

• Occurs in the business environment
• Occurs at a given point in time
• Must be responded to by the system

The Event Table describes the relevant activities that happen in the business and the required system responses. There are two types of events: business events and temporal events. Business events are activities that occur in the business, and are detected by defining each business activity within the scope of the system. Temporal events occur at a predetermined point in time. Temporal events exist because the business policy demands that certain system activities occur at certain times, or because the system produces its outputs on a timed basis. Case Study 7.2 describes how managing business events more efficiently at Delta Airlines can have significant impact on its business (Tillett and Schwartz 2001).

The business requirements are defined in the Statement of Purpose (Chapter 2, page 30). From that list, create a list of business events within the scope of the system, and define the responses to each event (see Figure 7-1, page 126). In the Event Description column, include how the event is initiated, or detected. When defining Responses, give descriptive names that unambiguously define what the system response is, such as "Verify existing customer," "Enter New Customer,""Check Credit."

Case Study 7.2 Delta Airlines—Managing Business Events Through the Delta Nervous System

The Delta Nervous System (DNS) represents an investment of $1 billion "to deliver timely data to customers, employees, and partners." However, it is not the delivery of the information, but the use of that data in handling business events that is the major benefit of the DNS. For example, an initial application of the system is aimed at baggage handlers and ensuring that they have an accurate picture of gate changes and flight delays so they can better plan the movement of luggage on and off planes. The change in status of a flight is a business event that has repercussions across the airline system. Whenever an event occurs, the change in status can be acted upon by providing the key participants of that event with information and services to react to these changes.

The DNS is turning Delta into a real-time enterprise with the ability to better serve its customers. However, it also has enormous revenue-generation and cost-saving implications. For example, having real-time information allows Delta to increase the number of flights per day by moving planes in and out faster. Overtime of idle ground crews can be reduced through better planning. Costs associated with the mishandling of bags can be eliminated.

While the focus is on making information available, the value will be in identifying meaningful events and then taking appropriate action as a result of the events. It is not necessary for a business to create a new source of information. Rather, it is important to create an architecture that is able to act upon business events and flow those through the system efficiently as a service. Delta has put such a system in place with its DNS.

The system responses defined in the Events Table are used to determine the essential services the system must provide. Some of these services or functions already exist in other systems, and other functionality will be new and must be developed then integrated. The service descriptions define the scope of functionality required to perform a specific business service.

Figure 7-1 Event Table
Event Number	Business Event	Event Description	Response
E1	Customer places Web order	This event is kicked off by an external event when a customer makes an order request. It ensures a valid order is placed into the system.	R1.1 Verify existing customer R1.2 Enter new customer R1.3 Check credit R1.4 Check inventory stock
E2	Order is processed	This event is kicked off when an order enters the system. It ensures that the order is ready to ship.	R2.1 Enter accounts payable R2.2 Fulfill order
E3	Order is shipped	This event is kicked off when an order has been processed. It ensures that the order is shipped and all parties are made aware of the results.	R3.1 Tracking number assigned R3.2 E-mail notification to customer
E4	Order is returned	This event is kicked off by an external event when a customer returns an order. It ensures that the returned order is processed correctly.	R4.1 Return authorization issued R4.2 Credit customer account R4.3 Credit inventory

To maximize business agility and IT investment, business services should be defined at the level of granularity that will optimize reuse. Tight cohesion— grouping closely related functions together into business services—and loose coupling between services are the design metrics that will yield more reusable design.

Three parts of the specification fully define each service: the Service Category Table, the Service Definition Table, and the Service Interface Table.

This level of description is sufficient for developing a new Web service or wrapping existing functionality as a business service.

The Service Category Table lists all required responses to business events, and defines whether the function already exists in one or more systems, or if it is new functionality. The table also defines likely services to provide the functionality. The service at this point is a first best guess at a services definition and will be refined further in the next step. When defining services, think of modules within an existing application that may perform the service or likely component modules for development (Figure 7-2, page 128).

The Service Definition Table fully describes each service at a level sufficient for creating Web services or other integration interfaces. Each service should be described in terms of its functions and systems used to create the service. In creating this table, group all functions and responses together that will form a cohesive module. For example, the service should manage a particular set of data, such as customer information, or product information, or should perform a specific service that might be used in other applications, such as credit checking or pricing. There should be loose coupling between services. Each service should interact with any other service through the defined interface. Changes in one service should not impact functioning of other services.

The description defines how the service will be implemented, such as Web service, application adapter, or application module interface (Figure 7-3, page 129). This is the place in the specification that brings the top-down design down to the technology-specification level.

Figure 7-2 Service Category Table
Response	Description	Service Category	Existing/New Systems
R1.1 Verify existing customer	Verify the existence of the customer in the system	Customer maintenance	Customer database
R1.2 Enter new customer/change customer data	Update customer records with new information	Customer maintenance	Customer management—SAP
R1.3 Check creditM	Check the credit rating of customer for proposed order amount	Risk management	Financials
R1.4 Check inventory stock	Check availability of stock to fulfill order	Inventory management	Warehouse system
R2.1 Enter order	Enter all order information via web interface; send to appropriate systems	Order management	Financial A/R; order fulfillment
R2.2 Fulfill order	Pick, package and ship all order items, report on backorders	Order fulfillment	Warehouse system
R3.1 Tracking number assigned	Assign an on-line tracking number to shipment	Shipping management	New—FedEx Web service
R3.2 E-mail notification to customer	Send E-mail to customer when order has been shipped	Shipping management	New—Web component
R4.1 Return authorization issued	Issue return authorization number	Customer management	Customer management
R4.2 Credit customer account	Issue credit to customer account when order is returned	Accounts receivable	Financials
R4.3 Credit inventory	Add returned merchandise to inventory	Inventory management	Warehouse system

Figure 7-3 Service Definition Table
Service	Functions	Description	Existing/ New Systems
Customer record maintenance	Check existence/ add/delete/modify	Web service abstracts, database connections and lookups, manages customer records	New—Web service, interfaces with customer management
Credit check	Check credit	Interface to credit check module of ERP system	Financials
Inventory management	Debit/credit inventory stock	Interface to warehouse management system	Warehouse system
Accounts receivable	Credit/debit customer account	Interface to A/R module of ERP system	Financials
Order management	Workflow management of a manual service	Interface to warehouse management system	Warehouse system
Shipping management	Integrate with FedEx system; send notification to customer	Integrate FedEx tracking Web service into customer web interface; create e-mail notification component	New—FedEx Web service
Customer management	Process returns; call center support	Web portal for call center, providing unified interface to customer and order info	New—Web component

While the Web services standard defines how to specify an interface, it does not define the data and functionality that the interface needs to contain. The Service Interface Specification provides the information necessary for creating Web services or other application or component interfaces. Using the Service Definition Table, list all inputs, outputs, and methods that the interface needs to support, and determine how the interface will be implemented (Figure 7-4).

Inputs: Customer ID; name, telephone number; address; shipping information; e-mail; credit; discount

Outputs: Customer ID; name, telephone number; address; shipping information; e-mail; credit; discount

Implementation: Portal based interface with data access service that controls connectivity to back-end data sources. Will either build Web service or install vendor data connectivity solution

The goal of defining standard interfaces is to maximize business agility. The standardized interface enables applications and services built on different platforms with different languages and technology to interoperate. It enables services to change internal functionality and rules or underlying technology without impacting other applications or components, as long as the interface remains the same. Therefore, getting the interface right is essential to maximizing reuse and agility. It is highly recommended that companies follow best practices of the standards committees when defining interfaces by having design reviews that include all stakeholders. It is also recommended that you create a glossary of terminology that is meaningful and consistent across all stakeholders. The purpose of the Interface Specification is to enable such design reviews, and to fully describe the interface so it can be implemented correctly and optimally.

A use case diagram can be used to depict the relationships between users, events, and services. It is the final piece of the puzzle for the specification. It integrates all of the information from the previous sections.

Use cases define actors and how they interact with the system services.Actors represent a role, and can be humans, other computers, pieces of hardware, or even other software systems. They must supply stimuli to initiate the event that in turn requires a system response (or service).Use cases describe the behavior of the system when one of these actors sends one particular stimulus. It depicts the business events and system responses in terms of the event stimulus that triggers the use case, the inputs from and outputs to other actors, and the behaviors that convert the inputs to the outputs.

The basic components of use case diagrams are the actor, the use case, and the association (see Figure 7-5).An actor is depicted using a stick figure, and the role of the user is written beneath the icon.Actors can be humans, other computers, pieces of hardware, or even other software systems. A use case is depicted with an ellipse, and the name of the use case is written inside.Associations are lines between actors and use cases, and they indicate that an actor participates in the use case.

To support the analysis of nonfunctional requirements (e.g., reliability, maintainability, and performance), use cases should be created to support scenarios in which these nonfunctional requirements will be tested. Examples include: 1) creating a use case that tests performance across a distributed component interface, and 2) creating a use case that tests the adaptiveness of a component by extending it (i.e., adding classes) and examining it to determine if the architectural design principles still hold. These system-level use cases may be implemented in a stand-alone fashion whereby a part or slice of the architecture is being tested independently from the business domain functionality it will need to support.

To create the use case, first identify the primary actors in the system. Then prioritize the services to be implemented.We recommend creating a use case for each proposed service. As an example, see Figure 7-6 (page 132).

The Use Case Specification contains text that further describes the use case (Figure 7-7). The text specification also usually describes everything that can go wrong during the course of the specified behavior, and what remedial action the system will take. This specification can be customized or expanded to handle particular issues within an implementation or organization.

This section should provide any final comments on the system, the design, or the usage of the system. It should include any known issues, constraints, or extenuating factors that contributed to decisions, or could affect the system in the future.

Abstract: This use case allows the customer to create a purchase order using/updating existing customer information or by creating information for a new customer. If the customer has initiated a purchase order directly (without accessing an online catalog), he or she can select the items from a product list for this use case.

General scenario:
1. Customer clicks the "order" button—Initiating Event
2. Screen appears displaying or requesting customer information
(UC010—Display Customer Information, UC011—Customer not Found)
3. Customer completes purchase order information including payment type, "Bill to" and "Ship to" addresses
4. Customer selects item from item list (UC017—Order Standard Item from Product List)
5. Customer selects item from online catalog (UC007—Order Standard Item from Online Catalog)
6. Customer clicks on "clear" button
7. Customer clicks on "submit" button
8. Customer clicks on "end" button—Post Condition (goal achieved)

Successful operation responses/output:
1. User provided visual confirmation of order and confirmation number
2. Order entry system updated with order

Extensions/ alternative paths/ unsuccessful operation responses/outputs:
4a. This step may be omitted
7a. This step may be omitted
6a. This step may be omitted

Issues: Need to verify how "product list" will be displayed, stored, and updated Need to determine how to link submitting the PO when the customer is using the online catalog

A successful service-oriented architecture enables companies to rapidly implement new business solutions or change existing ones and can deliver a substantial ROI. However, SOA is not necessarily easy to accomplish. The following best practices will help you reap the full benefits of SOA.

• Provide high-level organizational structure and support. Success with SOA requires ongoing enterprise commitment and investment. SOA cannot be accomplished with a single project. There needs to be a group of experts, such as the competency center, that focuses on the definition, growth, and reuse of the SOA. There need to be organizational processes and policies governing enterprise integration. As integration crosses organizational boundaries, it can also cause territorial disputes. Companies need processes and policies for managing these disputes (described in more detail in section 4.4, Organizational Structure and Architecture Governance).

• Implement standards-based architecture. Standards help ensure both interoperability and portability. They prevent technology lock-in, and help preserve value in IT investments. Web service standards are enabling the widespread adoption of SOA, despite the fact that it has been a known best architectural practice for three decades. XML enabling your systems is one way to provide a standards-based transport, management, and storage format for all structured data and unstructured content within the organization.

• Implement a standards-based approach. Follow the example of the standards committees that have long experience with creating processes that are successful in creating interoperable standards. Perform design reviews for service interfaces, and include all stakeholders. Stakeholders can be identified through the use cases.

• Think big, start small. When planning for an SOA implementation, consider the enterprise-wide impact in order to maximize reuse and agility. But start with a project that has a limited scope and a high probability of success. Nothing succeeds like success. You will learn a lot from each implementation, so wait until you have a couple of smaller implementations under your belt before tackling the most difficult challenges.

• Invest in training. You will have a higher probability of success if your employees know what they're doing. Few designers and programmers have experience with SOAs built on standards such as Web services and XML. It'sall too new. All stakeholders, including business and IT managers, architects, designers, programmers, and operational support personnel need to understand the overall concepts of SOA and what their role in the process is. Architects and designers need to understand the design parameters and best practices for creating agile and reusable systems. Programmers need to understand the new technology, and how to implement services and infrastructure components. Operational support personnel need to understand the implications of managing a distributed SOA.

• Use tools to save time and money. Don't try to handcraft everything. A wide variety of tools are available that can reduce time and skill sets required to implement the solution. Invest in tools when the advantages clearly outweigh the cost.

The Vanguard Group is an interesting case study where each of these best practices came into play (Case Study 7.3) (Dragoon 2003).

It had been described as a "brilliantly simple solution" when the Vanguard Group made a decision in the late 1990s to align their customers Web portal with their customer service system. In retrospect, it is surprising that more organizations have not come to the same conclusion, because the benefits seem so apparent:

• Parity between the customer interface channels in functionality
• Reduction of complexity in maintaining multiple systems
• An architecture that can be leveraged and reused for other purposes

The actual results have been impressive. Training of internal employees was significantly reduced, virtually eliminating four to six weeks of training. Retiring a large number of databases and applications reduced the complexity of the underlying architecture. Almost 10% fewer staff was required to maintain the systems. User response times were reduced by 60% to 70%, increasing the efficiency of the staff. Furthermore, the architecture supported the development of applications that improved several key business processes, resulting in straight-through processing of transactions. Savings from these changes were expected to result in annual savings of $30 million. The investment to achieve this was significant, but the expected ROI is an internal rate of return of over 20%.

While investments in architecture are often thought of as costs that have no apparent benefit, Vanguard demonstrates that the implementation of an architecture that supports reusability can have significant impact on a business. A well-designed service-oriented architecture is the key to achieving these benefits. Web services are not required, as we see with what Vanguard accomplished, but should help lower the costs that were borne in this project by reducing the amount of custom infrastructure work that is now provided through the Web services technology.

Services are the building blocks for composite applications and process-driven integration. Defining reusable enterprise services, as well as managing and measuring reuse, requires ongoing enterprise commitment and investment. Success with SOA is as much a matter of management as it is technology. Companies interested in long-term business agility will invest in all aspects of the enterprise integration architecture, including information and process integration architectures (Chapter 8 and Chapter 9, respectively). Companies focused on pressing tactical needs, will define only what is absolutely necessary and move on to implementation (Part III). See Figure 7-8.