Reducing the cost of IT management is one of the primary pressures for most organizations. One of the most common ways to reduce such costs is to enable the reuse of applications that developers have already created and configured for the enterprise. In the past decade, especially in the past 3-5 years, companies have spent millions of dollars on enterprise software applications of all sorts: CRM, ERP, and other operational applications. The next few years will be less about new application development, and more about existing application integration and reuse.

The Service-oriented approach helps solve the challenge of reuse by imposing a design methodology that promotes the use of self-describing, published, loosely coupled, and dynamically bound components rather than static, tightly-coupled components. Reuse becomes a matter of publishing available Web Services and developing the Services themselves to make sure they are not inadvertently tightly coupled. However, many companies believe that Services are nothing more than a standards-based API--basically just SOAP calls sent over HTTP.

Fundamentally, this is belief is a far too limiting way of thinking about Services in the long term. Rather than thinking about Services as a "universal API," enterprises can realize the greatest ROI by thinking about application and system functionality as loosely coupled, abstracted components. In order to realize this vision, however, companies must get a better understanding of how to "componentize" their enterprises in a Services context.

Enterprises must model the various constituent parts of the enterprise and how they interact in order to gain a fundamental understanding of them. In many ways, business modeling means taking design methodologies appropriate for object-oriented computing and recursively applying them to various business functions. In the Services context, therefore, coarse-grained business processes consist of loosely coupled business capabilities that contain the more fine grained software objects.

Business modeling Service-oriented architectures achieves a number of objectives:

• Helping to identify the level of granularity of systems for reuse.
• Providing requirements for business logic components and subsystems, and their interaction with other subsystems as well as external businesses.
• Identifying areas where developers can combine and separate components for greater flexibility and reuse.
• Developing systems than can evolve over time.

In order to meet these objectives, businesses must avoid modeling components using complex, nonstandard interfaces. Modeling in a Service-oriented architecture will then enable reuse and the other goals mentioned above. Just like Services themselves, business models shouldn't make any assumptions about the underlying architecture or framework that developers will produce the solutions with. Rather, the enterprise should model the components and their interactions in order to enumerate the requirements, but without imposing any restrictions on how to meet those requirements. This level of abstraction is very much the same as with the Service-oriented architecture: allow services to fulfill needs while abstracting the actual way in which businesses implement them. Without this approach, businesses must build components in a custom fashion, making each component unique and non-reusable.

ZapThink believes that what will become increasingly important is not the middleware platform itself, but the thought processes that go into to deciding how to create Web Services and Service-oriented integration solutions. Business modeling and identifying the granularity of Web Services will become as important as the business logic contained within the Web Services themselves, since Services components that are too coarse-grained will be just as difficult to reuse as tightly coupled object components. Since it's easier to model processes that are under one's control, the first major Services implementations are internally focused integration efforts.