Sonic Software
SOLUTIONS
PRODUCTS
SERVICES
CUSTOMERS
PARTNERS
RESOURCES
SUPPORT
NEWS & EVENTS
ABOUT US

SOA Comes of Age

June 8, 2004

SOA Comes of Age

We are in the midst of a technology sea change no less significant than the move to GUI, client/server, or object-oriented computing: the transition to service-oriented architecture (SOA) as a fundamental underpinning of IT. Organizations are grappling with—and implementing—SOA strategies as they build their next-generation software architectures. Industry consortia and standards bodies are busy developing a set of SOA specifications that promise richer interoperability. Software vendors of all sizes are focusing on SOA strategies for their product lines. And large vendors are jockeying for position in an attempt to "own" SOA before the other guys do (although surely no single vendor should—or could—do such a thing; more about that in a minute).

Why is SOA making that rare jump from industry hype to true usefulness? The answer is simpler than the acronym. SOA represents the opportunity to achieve broad-scale interoperability, while providing the flexibility required to continually adapt technology to business requirements. No small feat, particularly when one considers the extent and complexity of today's IT environments.

While not an overnight phenomenon, today's SOA represents a powerful summation of technology approaches that have been refined over the last two decades. The core principal of a uniform means of connecting systems is simple in theory, but has been difficult to achieve in practice. It has taken the software industry several technology cycles to arrive at and agree upon an architectural model and a set of standards that are up to the task. While some would argue that there is still some distance to go—and indeed we are not yet finished with the Web services standards that will provide rich multi-vendor interoperability—the model is working. In fact, we are already seeing the benefits of SOA adoption today.

During the first few years of the SOA wave, many vendors and enterprises alike focused on the "application end" of SOA: the goal of making application functionality available as a set of services. While this is the aspect of SOA that is easiest for many developers to identify with, there are other equally vital facets to consider in an enterprise SOA strategy. How should I think about the relationships between services? How will I connect them across my business? How will I orchestrate interactions across them? How will I manage and monitor them? How will I secure them?

In other words, what is my global architecture for services? This question has spawned the creation of SOA architecture groups in many organizations. It has also led to the requirement for something beyond an application platform. It points to the need for SOA infrastructure, increasingly identified as an enterprise service bus (ESB).

SOA infrastructure has a different set of characteristics than an application platform, and the underlying architecture for one is not appropriate for the other. To support the goals of service orientation, SOA infrastructure has to support:

  • Flexibility: it must allow the organization to change processes and relationships between applications through configuration instead of coding;

  • Heterogeneity: it must span new service-enabled applications as well as existing applications, while providing a consistent service model;

  • Distributed deployment: services will be spread across an organization, and between organizations; and

  • Management: the infrastructure must be able to manage and monitor itself, as well as the services deployed within it.

Interestingly, application platform suite vendors (such as IBM and BEA) have begun to discuss the need for SOA infrastructure in addition to application platforms. BEA's recent marketing of their Quicksilver project clearly draws this distinction. For many, though, the distinction is not new. Middleware has been performing the role of application-mediating infrastructure for decades, albeit through varying degrees of service-orientation and without cross-vendor interoperability. Recognizing the shift to SOAs and interoperability, Sonic pioneered a new form of middleware called an enterprise service bus (ESB), releasing our first version in March 2002. Based upon a vision of pervasive SOA-based connectivity shared with an interesting cross-section of large enterprises, Sonic developed a distributed service deployment, management and orchestration architecture, and married it to our standards-based enterprise messaging technology. Organizations across many industries, such as financial services, telecommunications, manufacturing and retail have already deployed the flexible, robust ESB infrastructure that is just now being discussed by other vendors. For these customers, the vision is already a reality.

In the end, though, SOA is larger than a single product or a set of products. SOA, by definition, represents an architectural approach. Responsibility for the design and implementation of an enterprise's IT architecture belongs to the enterprise. Software products are but tools and infrastructure for each organization to apply intelligently to that aim. No one vendor can therefore "own" SOA. You shouldn't have to rely upon a single vendor for all aspects of the SOA you build. Such a requirement would defeat the primary reason for making the shift in the first place: interoperability. Certainly some vendors will be more successful than others when it comes to providing useful SOA technologies—those that promote the core SOA tenets of broad-scale connectivity, interoperability and flexibility. I will be looking into these and other issues surrounding SOA and the enterprise service bus in upcoming installments of this column.

Gordon Van Huizen
Chief Technology Office
Sonic Software