How big do you need to be to use a Service Oriented Architecture? That’s a question I’d never really thought about until recently. I’ve worked in organisations ranging from a six-person start-up to a couple of global mega-corporations, and in every case we got a lot of value from thinking in a service-oriented way.
We moved quickly because we could partition problems into separate, loosely coupled concerns. We saved costs and improved quality by reusing well-tested components. The return on investment from SOA seemed pretty compelling.
Yet recently I’ve been working with a company that is struggling to see that return. It’s not that SOA isn’t giving them the benefits of flexibility, reuse, and suchlike. It’s just that the cost of the SOA makes these benefits pretty marginal.
Where are these costs coming from?
For this company, they start with an ESB. They’ve chosen an open source option, but even that brings a five figure annual fee for support licences. This is the largest single cost, after salaries, in their IT department.
And salaries are the next cost. Developing and maintaining services requires expertise. That six-person start-up I worked in existed in order to develop a software product – we all had expertise in software engineering. My current client exists for a totally different reason. Software expertise is an overhead. An experienced architect and a couple of engineers is a lot of very expensive overhead for a small company. Yet three people is about the minimum for a viable team – any smaller and there’s no-one to bounce ideas off, no cover for holidays or illness.
Throw in the cost of servers to run the ESB, subsidiary tools, etc, and the SOA amounts to a major investment. Their old architecture of ad hoc batch jobs and cobbled-together applications looks pretty cheap by comparison.
It’s not that this company doesn’t need flexibility. They need to be extremely nimble. A key reason for their success is the way they run rings around global mega-corporations. They developed the SOA because that old architecture was getting in the way. But the ongoing cost to maintain it has surprised them.
They can reduce some of these costs. You can develop a SOA without an ESB. You can find open source tools that don’t need a support licence. But you can’t develop a SOA without skills.
This has been a useful lesson for me. Many of the concepts of service orientation still apply, but we’re needing to adapt them to make economic sense in this context. One benefit of working with a small company is that they watch their costs closely – I wonder how many companies are simply paying the cost without thinking about it?