This chapter is from the book
This chapter is from the book
This chapter is from the book
Growing Pressures
Business processes have long spanned the multiple silos found within enterprises (Figure 1-1). Then why are you starting to experience more significant problems now? The answer is that changes afoot within enterprises are stressing their existing architectures.
)
Figure 1-1 Sources of Pressure
The majority of IT projects have traditionally focused on a single business process activity (or group of activities) residing entirely within a single application silo. The project's focus is generally to improve this activity's functionality, cut its cost, or improve its response time. The entire project generally lives within the silo: business objective, justification, budget, and staff.
Evolving business pressures have begun to force you to take a different view. One of these pressures is to improve the responsiveness of the enterprise as a whole. Customers and business partners want the business to respond more quickly. They want to have ordered goods delivered tomorrow (or today), not next week. They want the status of their order when they ask, not a callback in an hour after someone has investigated. The problem, of course, is that such projects require changes in multiple silos. They do not fit well within existing project structures.
Another major pressure is cost management. The wide adaptation to enterprise resource planning (ERP), for example, has sought to optimize resource utilization by coordinating and managing all enterprise-wide business processes related to planning, procurement, and production. These efforts impact all of the architectural elements, and successful ERP projects address them all, in concert. Projects that treat ERP solely as an IT initiative inexorably, and spectacularly, fail.
There are also increasing pressures to increase the return on investment (ROI) from IT projects and to make systems and business processes more flexible. This has pushed SOA to the forefront as enterprises seek to architect business processes from reusable services. The vision is that the reuse of services will cut IT costs by avoiding the cost of reimplementing existing functionality in future projects. Services also promise the potential for implementing new (or revised) business processes more quickly by simply composing existing services. This not only reduces IT costs but cuts the overall time span of the project as well. It improves an enterprise's ability to respond to outside pressures.
The sticking point here is that business services are pieces of business processes. They involve people and information as well as systems. In defining business services, you are structuring and organizing (i.e., architecting) business processes and business organizations as well as systems. If services are to be reused, they must fit cleanly into multiple business processes and align well with assigned business responsibilities. They require the total architecture perspective and active business involvement.
Business services also pose challenges to existing silo-based project structures. A business service encapsulates functionality provided by one business unit so that it can be used by at least one other business unit. That other business unit is responsible for some other portion of the overall business process. In order for this to work, the interests and needs of these other business units must be factored into the design of the business service, or it will not provide the functionality required.
This multiple-business-unit perspective does not fit well into traditional silo-oriented IT projects. To begin with, the service provider does not accrue any of the benefits of reuse. In fact, the silo implementing the business service will actually incur a higher initial cost for providing its functionality as a service. Nor does the first user accrue any benefit unless the reuse actually occurs within this first project. It is generally the second and subsequent projects that will realize the benefits of services. Existing project structures are not designed to handle projects that span multiple silos and whose benefits will be realized only in the future.