SOA for Independent Software Vendors (ISVs)

As Enterprise Architecture, Service-Oriented Architecture (SOA) is particularly useful in large enterprises, and increasingly, to small and midsize businesses, as well. However, those are only one part of the IT ecosystem. What about those companies that are in the business of building and selling software products, so called independent software vendors (ISVs)? Generally speaking, ISVs create and sell software products that run on one or more IT platforms. ISVs might offer consulting services, but they typically aren’t consulting companies per se. Neither are they simply Value-Added Resellers (VARs) or Original Equipment Manufacturers (OEMs), who embed or customize someone else’s products. Rather, ISVs sell their own intellectual property as installable, configurable software.

The largest software vendors are responsible for the enterprise applications that we run, the operating systems we use, and the infrastructure platforms on top of which we conduct business — think IBM, Microsoft, SAP, Oracle, HP, and CA. However, we don’t usually refer to those vendors who provide software ecosystems unto themselves as ISVs. Instead, this ZapFlash focuses on the thousands of smaller software vendors who participate in the large vendors’ ecosystems by making and selling software products that run on the large vendors’ platforms. For these smaller folks, does Service Orientation even matter? Why should they consider the intricacies of the movement to an agile architecture if their primary objective is to the fill the niches left open by the larger software companies?

First, Necessary Step: Don’t be an Integration Headache
First, an important reminder: as we covered in earlier ZapFlash, there’s no such thing as a SOA “wizard” — that is, software that can provide SOA out of the box. Remember, SOA is architecture, which means it consists of a set of best practices, and the discipline to follow them. In other words, SOA is something you do, not something you buy. As a result, there are two fundamental ways that ISVs can leverage SOA in their products: to help their customers implement SOA for themselves, and to leverage the principles of Service Orientation to help make their own products more useful and valuable to their customers, regardless of whether those customers are actively planning or implementing SOA.

In fact, a primary reason why even the smallest of software vendors should consider adopting Service-oriented principles in their software is the same reason why many large companies decided to adopt SOA as many as a few years ago — to reduce their integration expense. Distributed computing systems built on proprietary, tightly-coupled, and inflexible technologies are much more expensive, complex, and cumbersome to integrate with, resulting in significant customization and configuration expense. The problem with most of today’s ISV products is that too much time and money goes into simply getting them to work in a heterogeneous, distributed environment.

As a result, ISVs with products that participate in the increasingly heterogeneous IT environments of their customers should at the very least take the first step down the SOA implementation roadmap and replace proprietary, tightly-coupled interfaces with standards-based, loosely-coupled ones. This move will not only reduce the overall cost of implementing their software, but also make their products more attractive as the IT environment becomes increasingly more complex. Software products with standards-based interfaces will not only offer lower cost of integration for their customers and faster time-to-market for the vendors, but will also significantly reduce the need for consulting to get them to integrate, lowering their total cost of ownership.

Enabling Continuous Innovation
However, simply placing standards-based interfaces on top of existing, tightly-coupled architectures is not sufficient for ISVs to realize the true promise of SOA for their customers. ISVs should also take the notion of loosely coupled, composable Services to heart. Too many software companies have jumbled their products together into a tightly-coupled, intricate morass of software that is hard for the vendors themselves to integrate, let alone their customers. Taking SOA to heart will lead to making their own products better integrated with each other, let alone with their customer’s IT environments.

What differentiates the smallest of ISVs from the largest is not their requirement to meet customer demands — all software companies must do that — but rather the available resources to meet those demands. Large software companies often have the luxury of deep pockets to fund ongoing research and development. Small vendors all too often operate at the edge, carefully balancing the need to continue to invest in their existing (one could even say “legacy”) technology, while looking to innovate to meet new demands so that they can grow their businesses. Even more so, many IT products have reached a point of maximum complexity where adding new functionality amounts to a zero-sum game that only serves to further complicate the software, rather than adding to the overall value to customers.

In today’s competitive (some would say “cutthroat”) software marketplace, vendors must continually and rapidly innovate their products without introducing this unnecessary complexity and brittleness in order to survive. Service Orientation is therefore many ISVs best hope for survival. By abstracting their product functionality as a set of Services that continually evolve as the underlying implementations likewise evolve, ISVs can approach their application functionality as a Service-oriented whole that meets customers’ changing business requirements.

Rather than trying to translate directly from sales requirements to product implementation, ISVs should take a page out of the smartest enterprises’ SOA playbook — establish an Enterprise Architecture team that manages the Service model that mediates between business requirements and software functionality. The more that vendors seek to translate directly between individual business requirements and product functionality, the more they will find themselves chasing the tail of IT complexity. SOA provides ISVs with an overall product development methodology that allows them to meet new customer requirements with new functionality, stay ahead of competition by matching existing features and introducing new capabilities, and do so without breaking everything else they already have or worsening the challenge of product integration. Smart ISVs will see SOA as their ticket to long-term product success.

Make Yourself an Embeddable Platform for Growth
However, software companies have significant opportunities to benefit from SOA more than simply making the componentization and integration of their offerings easier for themselves and their clients. ISVs should also recognize that SOA is fundamentally shifting the entire landscape of distributed computing. Rather than seeking to purchase, implement, and then integrate disparate software offerings as their business needs change, enterprises will consider all their various IT capabilities as composable assets they can leverage as their business needs evolve. As a result, many ISVs of the future will no longer be in the software product business anymore. Rather, they will be in the Service business, providing an assortment of IT capabilities, associated metadata, and business processes that enable the composition of those Services on an ongoing basis. As the notions of Software as a Service and SOA converge, ISVs that successfully leverage SOA will provide their customers an ongoing stream of continually updated Services and metadata, rather than selling traditional software products on today’s familiar release schedules.

In this vision of the Service-oriented ISV, vendors become independent Service providers that provide all the necessary IT intellectual property for a particular set of business tasks. Service-oriented ISVs are in the business of providing Services that their customers can embed within their business processes as needed. This shift from self-contained, packaged software to embeddable, composable Services will necessarily change the business of software as vendors offer their products on a license, subscription, or even per-transaction basis. As a result, ISVs who don’t ride the SOA wave will quickly find themselves obsolete in the face of IT Service vendors that provide the flexible Services businesses desire.

The ZapThink Take
The most important benefit of SOA is business agility, and implicit in this ZapFlash is the position that ISVs must become more agile by shifting the control of IT to their customers. For far too long, software vendors have exerted excessive control over their customers by imposing restrictions, costs, and complexities on how their customers consume IT functionality. In many ways, the business climate actually rewarded this balance of power by establishing the expectation that software licenses are but a small part of the total cost for any particular IT project.

The shift to SOA is fundamentally changing this economic reality. Customers are coming to expect a much flatter cost of change and the ability to evolve their business without having to rip and replace their IT investments. ISVs, therefore, have no choice but to evolve into agile businesses themselves in order to enable their customers to become agile as well. Becoming Service-oriented, therefore, is not a matter of simply putting standards-based interfaces on top of existing, tightly-coupled, complex, inflexible and non-composite business functionality. Rather, in order to realize the promise of SOA, ISVs must change the way in which they build, package, sell, deliver, manage, and support their offerings. In other words, SOA will radically change the ISV just as much as the end-user, and those that can get on top of this curve will thrive, while those that don’t will be doomed.