Our recent engagements with clients as disparate as a mammoth semi-government organization, a well-known and well-respected direct marketer/ retailer, a profitable and prosperous mid-tier software firm (there are a few out there!), a publisher of scholarly journals, a well-known benefits administration firm, and a direct-to-consumer manufacturer have all had one element in common: the migration to service-oriented architectures. Each of these engagements has had a very different focus--information architecture strategy, selection of a multi-channel CRM supplier, “customer-in” business design for new ventures, portal strategies and implementation--yet we’ve used a common approach to help each group of clients reach their objectives. In each of these very different situations and contexts, we’ve found that it works really well to show clients how they can identify the core services they’ll need to carry out their strategies. What do we (and our clients) mean by services? Are we talking about Web Services? Not exactly.

We’re talking about application services--customer and account profiling, eligibility, credit-checking, status reporting, inventory availability, dynamic pricing, returns-handling, travel planning, expense tracking, workflow, alerting, business-rules creation and management. We’re talking about information services--federated searching, citation management, revision control, translation, taxonomy. We’re talking about infrastructure services--authentication, authorization, directory, session management, persistence. All of the business and IT teams working on the disparate projects mentioned above were already leaning towards a services-oriented architecture approach to conceptualizing and prioritizing their funded projects. What they learned in working with us was how to identify and to prioritize the services that make the biggest impact on their customers’, employees’, and partners’ most critical scenarios. Then, armed with a business and IT-bridging shared mental model and vocabulary, they go back out into the marketplace to try to purchase the services they can use to implement their strategies.

There’s the rub. Today’s software and systems suppliers haven’t yet caught up with how fast the service-oriented architecture evolution is sweeping through IT buyers’ organizations. It’s ironic. Most of today’s application software is being re-architected to take advantage of core underlying services and modularized into leverageable and re-usable service components--e.g., a single workflow service, a single alerting service, a single chat service--that can be re-used across applications. Yet no software company is actually selling services! And that’s what today’s customers are looking to buy. Today’s savvy IT buyers are still willing to buy packaged software solutions, but only if they are sold as bundles of services that can be mixed and matched, swapped out, replaced, and integrated into the services these companies already have. We’re no longer talking about Enterprise Application Integration (EAI) on an application-to-application basis. These architecturally-savvy business and IT budget-owners want service-to-service integration. They aren’t demanding that the applications they purchase be WEB Services, per se (in fact, most are leery of performance issues with SOAP implementations), but they are requiring that software suppliers offer application or infrastructure services with human- and application-readable XML and, even more specifically, WSDL interfaces.

We’re confident that as the new round of RFIs and RFPs hit the market--calling out functionality by specifying required services--the software and solution suppliers will catch on quickly. The smart software players will run out in front of the parade to capitalize on the re-architecting they’ve been doing to streamline the IT architectures of the products they sell. Software vendors need to start thinking Services, not Solutions!