Retiring the Four-Platform Framework for Web Services
As an analyst firm, ZapThink sees many presentations from vendors and end users, and as a result we have seen a recurring vision for Web Services that has outlived its questionable usefulness at representing how the market is implementing and producing products for real-world Web Services and SOA solutions — namely Gartner’s Four-Platform Framework of Web Services. While the framework has helped many companies get started with their understanding of Web Services, we believe it’s time to move on. Fundamentally, the way in which the Four-Platform Framework is represented by vendors and end-users is inaccurate, incomplete, and in the final analysis, no longer helpful for either end-users or vendors as they struggle to grasp Web Services or Service-Oriented Architectures (SOAs). In its place, ZapThink offers the SOA Implementation Framework, which we feel more accurately reflects the challenges companies face as they seek to implement SOAs, and the products vendors must produce to help their customers achieve the benefits that SOAs promise.
Explaining the Four-Platform Framework
The Four-Platform Framework contains a Web Services producer platform, a Web Services provider platform, a Web Services consumer platform, and a Web Services management platform. The producer platform consists of development tools and development approaches to exposing Web Services interfaces on top of existing or green-field applications. The producer platform sits as the primary means by which developers create Service interfaces and compose those Services into higher-level business processes.
The provider platform is separate from the producer platform and is mainly responsible for hosting and provisioning Web Services in the enterprise. The provider platform can contain application servers, middleware platforms, integration solutions, or even databases. In this vision, the provider platform supports the Web Services architecture or SOA, which is essentially a best-practice architecture for implementing large enterprise systems.
According to the Four-Platform Framework, the consumer platform focuses on using and taking advantage of Service interfaces provided by the producer and provider platforms. Finally, the management platform is a product solution or managed network that focuses on administrating and supervising the operation of running Services to guarantee that they are meeting business needs.
So, according to this vision, an enterprise must implement each of these four platforms to deploy Web Services and SOAs in the enterprise. While this certainly served an important role for people as they first tried to understand a new and emerging market, it is not an accurate, complete, or helpful representation of how end-users actually buy and implement Web Services or SOAs in today’s market.
The Vision is Inaccurate
The primary problem with the Four-Platform Framework is that it is simply not an accurate representation of the way that companies actually purchase and implement Web Services. Simply put, the management, consumer, producer, and provider platforms are all inextricably linked together. Any Web Services solution focused on solving integration problems — indeed, the only kind of Web Services solutions most companies consider at this point in time — will have to consist of management, consumer, producer, and provider elements. Yet, companies never purchase these platforms separately. Rather, consuming, provisioning, and producing are all capabilities of the same platform (although a separate product does often provide management). A look at what IBM, Microsoft, CA, BEA, and others offer would confirm that there are not three or four separate Web Services or SOA offerings from these vendors, but rather a single, unified solution that seeks to address the overall SOA challenge. If the platform vendors themselves aren’t offering the Four-Platform Framework, then who is the Framework intended for?
Secondly, end-user companies don’t evaluate Web Services solutions as being composed of three or four parts, but rather as a single, cohesive solution set that addresses their immediate needs. RFPs from end users don’t call for four separate platforms, but rather for a single Web Services-based solution that solves their integration problems. Since the Four-Platform Framework doesn’t reflect the way that vendors produce Web Services products, or the way end-users purchase or implement them, it’s clear that this vision is not an accurate portrayal of the current market.
The Vision is Incomplete
The Four-Platform Framework also doesn’t include a number of important elements of the Web Services and SOA markets. In particular, the framework does not include address the architectural components of an SOA. It is not clear where SOA tools, asset management suites, composite application solutions, and management tools that enable coarse granularity and loose coupling fit into the Four-Platform Framework. The framework also completely misses the role that UDDI plays and relegates it to keeping track of large numbers of Services and aggregating Services across organizations, rather than its central role as a Service broker for enabling location independence.
In addition, the Four-Platform Framework is missing the critical role that security plays in implementing SOA solutions. Security platforms are not among the four platforms, nor are process or information integration platforms, for that matter. Finally, there is no allowance in the Four-Platform Framework of the role of emerging Enterprise Service Bus (ESB) products. Are these critical solutions part of the producer platform, the provider platform or neither?
The Vision is Unhelpful
Most importantly, a framework like the Four-Platform Framework must be helpful to both vendors and end-users. Unfortunately, the framework is not helpful to startups or emerging technology companies as it positions each of the four platforms as part of existing development tool, application server, or enterprise management markets. In this vision, there is simply no room for additional entrants. On the other hand, the vision is not even helpful for vendor market leaders, either. Most of the major platform vendors are attempting to sell well-integrated suites that reflect the realities of today’s Web Services market, and the Four-Platform Framework does little to support the major vendors as they attempt to sell unified solution suites that combine elements of the four platforms.
Finally, the vision is not helpful to end-users since it poorly reflects how the market for Web Services products is truly evolving. Most importantly, the Four-Platform Framework is an example of what ZapThink calls a “horseless carriage” mentality. That is, the framework applies traditional ways of thinking about existing markets to new, emerging markets. In this case, the movement to SOAs demands new ways of developing, managing, deploying, and architecting IT assets. The word “platform,” however, implies a runtime environment as part of an n-tier architecture, rather than loosely coupled applications composed into a Services layer of abstraction. As a result, simply using the word “platform” in the Four-Platform Framework is fundamentally unhelpful.
The ZapThink Take: The SOA Implementation Framework
ZapThink eschews platforms altogether when discussing SOAs. Instead, our SOA Implementation Framework contains five parts: Service-Oriented Architecture tools, Service-Oriented Integration, Service-Oriented Process, Service-Oriented Management, and Web Services Security and Identity Management, as shown in the figure below. SOA tools include modeling, asset management, and Service-oriented development tools that both IT and line-of-business need to build and maintain the Services in the SOA, and maintain the abstraction layer that those Services represent. Service-Oriented Integration provides runtime integration among disparate, heterogeneous systems integrating both at the application interface as well as at the information levels. Service-Oriented Process composes Services into business processes that are themselves Services, and provides the loose coupling to isolate the Services that are produced from the processes that consume them. Service-Oriented Management enforces and enables loose coupling by guaranteeing the availability of Services and providing visibility into their runtime operation, supporting the layer of abstraction that exposes system functionality in a loosely coupled manner. Finally, Web Services Security and Identity Management are fundamental prerequisites to building an SOA by providing the key capability of enterprise identity management that is required to maintain security context and policy enforcement across long-running Service interactions.
ZapThink calls this vision a framework, because it offers pieces of the SOA puzzle that vendors and end-users must assemble. We use the word “implementation” because this framework applies both at design time and runtime — in fact, SOAs blur the distinction between the two, and thus, this vision is fundamentally a framework of the complete implementation lifecycle.
A Final Word
The technology is actually the easy part of moving to an SOA. The hard part, as with any situation that involves change, is the human part. End-users and vendors alike must actually change the way they think about the organization of their IT resources in order to make their SOAs successful. The Four-Platform Framework was useful in its time as people began to think about the power of Web Services and SOAs, but that time is over. Today, people are beginning to think in Service-oriented ways, and as such, they need a new framework for understanding the essential elements of a successful SOA.