Context: I’m currently in discussion with a number of companies that are involved with SOA-vending & -consulting. As a result, I’ve been studying up a little on this market and hope to learn more by writing about it. Note: Since I know, judging by the response to other articles on enterprise-software, this isn’t exactly the most sexy of topics, I expect the number of comments to be minimal.

Jeremy has already written about this topic (primarily in terms of Software-as-a-Service (Saas) and Software + Service (S+S)) before (here, here, and especially here), so I won’t go very deeply into it, but SOA is roughly defined as:

“guidelines that allow software developers to design systems in stand-alone chunks of computer code, each specifying the critical outcomes, performance metrics, and interfaces between a discrete activity and other services.” (Src: HBR, June 2008)

If that’s a little abstract, I see it as a selling you a ticket to Lego-land, where you can play with legos all you like, those lego-blocks representing individual applications that can be used by businesses through a web (SaaS) or hybrid (Software+Service) interface, and Lego-land being the SOA-system that integrates all of them for you. This is opposed to the historical approach of buying a lego-box, which you eventually replace by another and another (side-prediction: we will eventually see Lego-world online).

SOA’s value-proposition

While traditionally it has been so that in order to compete in a technological world, you have to be technological, the idea of SOA is to remove that element, instead allowing individuals and businesses to focus on what they do best. I, personally, like that very much.

Other, more measurable advantages are that it is dramatically more cost-efficient. If you imagine that 5+ years ago, every company had to either invest into a powerful wide-area network (WAN) to be able to centralise IT-services, or replicate islands of IT-systems for each business-location, SOA removes that idea entirely, using a freely available infrastructure, the internet, and removing the need to build IT anywhere, instead paying-as-you-go for singular services that an external provider hosts and distributes. Added to this is the idea that performance now becomes accountable, in the sense that it is covered by contracts (e.g. QoS or SLA), something that was much harder to do with a permanently employed IT-staff.

With all these advantages and several more, it is no surprise that, in 2007, over 50% of mission-critical IT-projects were estimated to be SOA-based, a figure which is believed to increase to 80% in 2010 (these figures are from Gartner and may be US-only).

SOA’s hurdles

While this sounds pretty great, anytime you’re talking about system-wide change, you have to consider that this will meet resistance and involve a great many stakeholders, i.e. take a lot of time. And the question is here, who will you talk to as an SOA-vendor? Will it be the business-side of your client, as you are selling easy-to-understand lego-blocks, or will it be the technology-side, as you are selling technology? This is a serious question, so please answer it in the comments!

Added to this, a SOA-deployment is a strategic issue for your customer, meaning that your selling-proposition will also need to include the option of strategic support, aka consulting-services. This means that technology-only SOA-providers (vendors) will likely have to work with third-party consultants that pick-and-choose the best SOA-package for their client.

Related to this, the lego-like quality of SOA, which promises values like agility, flexibility, price, and reuse, and several more, all very important in this recession-prone time, also mean that someone can quite easily replace your service with someone else’s legos. Arguably this is much less the case if you provide an architectural framework and focus on building ecosystems (create lock-ins). But that is easier said than done, and as such this is a field dominated by few big players that buy up smaller ones.

Some more things, which I haven’t researched, are the degree that open source is a factor/issue here, and different revenue-models.

Grasping the paradigm-change

On the customer-side, there’s two ways of seeing this trend. On the one hand, extreme efficiencies, which also follows Nick Carr’s view that IT is no longer a competitive advantage. On the other hand, you’re giving away a lot of responsibility, which can be bad in two ways.

One, you’re giving away a lot of power to an industry, which will continue to consolidate. It’s something that may not be a problem now, but may become one.

Two, delegating a problem does not necessarily solve it. Taking the retail-industry, the biggest problem here is logistical inefficiencies, caused by delays, unnecessary replication of processes, or otherwise. Here, SOA, as long as it spans across the value-chain of manufacturers-transport-retailers-customer, is clearly a good thing. But it still requires a solid understanding of how IT does and can help your supply chain reap better results, something an independent SOA-vendor may not do as well. My opinion here is purely hypothetical, but it may be worth investigating how the masters of retail (Wal-Mart, Tesco, Carrefour, etc.) solve it. And if this is a problem, I imagine it is elsewhere too.

The SOA playing field

This post is getting a little long, so I’ll briefly go into this. Following Forrester-graphs show the players in the integrating corner of things (consultants) and, on the right, the vendors (also note the time-difference (the second one is Q4 2007) and region). You can find the originals here and here.

Clearly this industry is very layered, with some offering the complete package, including strategic assistance, and others providing either the SOA or a part of it (SaaS or similar). There is a lot of movement in this field with players buying each other out or moving into related industries, either on the hardware or software-side.

Final thoughts

Because I’m not a soft-/web-ware guy, I’m still very much undecided whether to head in the software-only direction myself, though I see much merit for an integrated business-consulting + software-deployment approach, and I also prefer selling Lego-blocks to rubber-trees. Feel free to convince me of your points of view.

All of this was initial thinking of course, and as such I’m happy to hear if you have anything to add or if I made some obvious mistakes. Again, considering the relative unsexiness of this area, I don’t expect too much

Vincent