Model First, Service-Enable Next

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 Web 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 Web Services in the long term. Rather than thinking about Web 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 Web 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 Web Services context, therefore, coarse-grained business processes consist of loosely coupled business components 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 Web 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 Web 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 Web Services implementations will be internally focused integration efforts.

Read More in ZapThink’s Service-Oriented Integration Report…

Research: Service-Oriented Integration (SOI) Market to Grow to $6.2 Billion by 2006
The ability to connect systems within the enterprise and external partners while reducing the cost and complexity of maintaining those systems seems to be a goal that is just out of reach for most enterprise IT organizations. While Web Services won’t be the magic bullet that miraculously solves these problems, it does enable a new class of solution: Service-Oriented Integration (SOI). This report identifies the key aspects of SOI, solutions for implementing SOI, business ROI metrics, and critical challenges.

Key Findings of this report:

  • The SOI market is expected to grow from $435 million in 2001 to about $6.2 billion in 2006.
  • The top three EAI vendors have over 43% of the overall EAI market. With the entrance of Microsoft and other vendors in 2002, this landscape is expected to change.
  • Service-Oriented Integration (SOI) simplifies system integration by providing a single, simple architectural framework based on Web Services in which to build, deploy, and manage application functionality.
  • Web Services isn’t an integration technology, but a distributed computing technology that lends itself well to being used in integration scenarios.
  • In a Web Services context, there really is no difference between EAI, B2Bi, and Data Integration.
  • SOI faces challenges in immature specifications, insufficient reliability, security, and transaction control.
  • The potential ROI realized by adopting Service-Oriented Architectures (SOA) far outweighs the slight benefits an organization gets from using Web Services as simply a “better API” for accessing application functionality.