Who is the SOA Buyer?

Guest Commentary
Who is the SOA Buyer?
by Ronald Schmelzer, Senior Analyst, ZapThink, LLC

A well-known saying goes that the road to business success is littered with failed companies that had great technology. After all, a good product or technology concept alone is not sufficient to guarantee success in the market. Good companies also need effective sales and marketing to bring a well-understood product to the market. However, companies in emerging markets such as those for Web Services and Service-oriented architecture (SOA) products often forge ahead with their product development and sales plans without answering the critical question: "Who is the buyer of my product, and what problem of theirs does my product solve?" The answer to this question can often be surprisingly challenging for companies who are looking to sell their Web Services and SOA wares, since the broad, enterprise nature of SOA initiatives can make it quite unclear who the buyer is.

SOA: Everybody's business
Because SOA is an architectural approach that abstracts broad, heterogeneous IT systems and applications, enterprise SOA initiatives touch many different individuals and groups within the organization. Furthermore, many of the products on the market today that help companies leverage Web Services within an SOA include security, management, integration, business process, and development tooling capabilities. Few products contain all of these items, but most contain two or three such capabilities. Such broad capabilities can be a mixed bag for both vendors and end-users.

The use of standards to describe a user interface, in this case HTML, combined with general-purpose clients that would consume those interfaces illustrated the power of loose coupling – namely the great amount of flexibility achieved by separating the presentation tier from the underlying business logic tier. In addition, the Web proved that distributed computing was possible at very low total cost of ownership. Web browsers enabled companies to distribute applications without needing to deploy software onto desktops or end devices.

On the one hand, multi-capability products such as Enterprise Service Buses (ESBs), composite application tools, content-aware network appliances, and SOA enablement platforms offer significant business value over single-function products, but on the other hand, it's less clear who in the organization is responsible for buying such products. In particular, vendors might call upon application developers, enterprise architects, or network operations managers in the course of their sales efforts. But which of these roles is truly responsible for buying SOA products?

The application developer buyer
In many ways, application developers and their managers are responsible for a significant part of the implementation and maintenance of systems that expose Web Services or otherwise participate in an SOA. Application developers are first and foremost concerned with the efficiency and effectiveness of the application they are developing and secondarily with higher-level issues such as reuse and business agility. ZapThink has found that application developers utilize Web Services mostly as a way to simplify integration on a point-to-point basis, and many don't understand (or even care about) the fundamental concepts of SOA. However, despite this low level, tactical usage of Web Services, application developers have some limited budget control, especially at the departmental level.

Companies who are selling tools that help to expose Web Services from individual systems, especially legacy and mainframe systems, or provide development tools to help facilitate Web Services and SOA will find significant traction with this group. However, these projects will all be mostly small, incremental deals, that over time might contribute to an SOA in the long-term, but mostly are using Web Services as a stopgap for their existing, tactical integration issues. As a result, the SOA buyer typically isn't the application developer.

The enterprise architect buyer
Search a bit higher in the IT organization and you'll find a class of user that ZapThink identifies as the enterprise architect. Enterprise architects can be individuals with that title in their job description, or can consist of a team of high-level developers and technical managers that have wide-ranging responsibilities in different parts of the organization. These users are not directly concerned with a particular tactical task, such as point-to-point use of Web Services for a legacy integration project, but rather concern themselves with trying to map the business needs to ongoing IT projects, while maximizing agility and minimizing incremental IT cost.

However, the enterprise architect is not a role that is well defined in many corporations today. In some cases, individuals that call themselves enterprise architects may actually simply be application developers or project managers, or in other cases, they may be missing critical aspects of their role, such as network operations, security, and business process definition. As such, companies that hope to target the enterprise architect community will either have to wait until this role becomes more prevalent and well-defined, or will have to continue targeting other buyers in the organization.

The network operations buyer
In many cases, companies are looking to sell Web Services and SOA solutions that primarily focus on aspects of application and network performance and optimization. XML and Web Services acceleration, security-focused appliances, Web Services routing, and even aspects of Web Services management applications are often tailored to solve the problems of the network operations and administration buyer. Network operations personnel care most about the health and well-being of the network. They don't see XML and Web Services as a part of a distributed, agile computing infrastructure, but rather as a foreign, alien body that must be dealt with in a controlled manner.

Instead of being proponents of Web Services and SOA, network operations personnel are primarily disposed against these new technologies due to the threats they introduce to "their" network. When network operations users buy Web Services and SOA products, they do so out of FUD – fear, uncertainty, and doubt – that Web Services introduce, rather than the positive business changes that it represents. As a result, many companies selling the such products can sell to this community, but these sales will tend to be tactically focused with little opportunity to sell to higher levels of the organization. In addition, network operations personnel are by definition risk-averse and tend to purchase from vendors they already trust. So, companies who focus on this community will face the threat of significant competition from the network gorillas, whenever they choose to enter the market.

The security and policy management buyer
In some companies, the role of security administration and policy definition is separate from both the network operations as well as the application development or architecture. These users are primarily concerned with defining policies that meet with established corporate governance requirements or emerging IT policies and procedures. They should apply these policies to all IT assets, whether they are software, hardware, neither, or both. As a result, their involvement with Web Services and SOA stems from the emerging need to secure Services, just as they have secured the other assets under their control. A policy they define for portal access must apply as well to the Services that underlie the portal. Similarly, network access policies that they might have applied to the firewalls at the boundaries of the organization must now spread to all the systems that could potentially be exposed on the network.

These security administration and policy management buyers thus care the most about Web Services security and SOA contract and policy definition tools. While they care less about the aspects of business agility and reuse than the enterprise architects, their purchasing decisions do have an impact on the entire enterprise, and as a result can have significant relevance to the infrastructure of a company. Therefore, whoever is responsible for buying security and policy administration for the company has influence on the SOA purchasing decision for the organization as a whole.

The ZapThink take
Who, then, is truly responsible for buying SOA products within the organization? Until new purchasing patterns evolve, companies will by necessity have to tailor their products for the specific buying audiences they plan to target. This limitation is unfortunate, since emerging Web Services and SOA products have aspects of integration, runtime infrastructure, development, modeling, management, security, and policy. How can they target just one buyer, if their capabilities are so broad? Vendors with such product breadth must focus their product lines to sell to specific audiences, until a single audience within the enterprise emerges that can understand the broad message, and has purchasing authority to implement the product.

For more information:

• Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
• Are you tired of technospeak? The Web services Advisor column uses plain talk and avoids the hype.
• For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
• XML Developer Tips and .NET Developer Tips.

• Visit our huge Best Web Links for Web services collection for the freshest editor-selected resources.
• Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
• Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
• Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
• Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.