After a few years of reading about (and, once upon a time, practising) Service Oriented Architecture (SOA) development, I was interested to read Galen Gruman's article in Infoworld on its take-up in the mainstream, commercial world.
I got interested in SOA very early on. Not surprising really: as an enterprise developer (in Higher Education) with a background in web technologies, involved in mainly Java-based projects, I already had the mindset with which SOA would fit naturally. Specifically, it was the promise of distributed, re-usable components which appealed (and which was touted as the main benefit by commercial vendors). But after a couple of years of experience with this approach, and with the very slowly maturing stack of standards known as 'WS-*', I began to doubt. I noticed how much effort went into 'building for the future', without this 'benefit' being clearly realised very often.
Yet SOA seemed to bring benefits nonetheless. We found that our various development partnerships with commercial vendors became easier to manage, for instance, with a shared SOA approach. But the real pay-off was in the discipline it demanded. We especially had to take pains to better understand the processes and workflows. And it was this latter aspect, I think, that offered the most benefit to the developers, and to the organisation. When developers start to think this way, they are forced to consider the 'business' they are developing for, and they will tend to build more sensibly. Towards the end of my tenure as an HE enterprise developer, I was spending more and more time modelling the business.
I would claim that, by the time I left, the technical team within which I worked had a better overview of the business processes of the university than any other part of the organisation. We were able to successfully re-apply that knowledge to subsequent development, to great effect.
Quoting Ian Findley, an analyst for AMR Research:
Another danger seen from the SOA survey is that the main benefit that the vendors sell around SOA — code reuse — is not the real benefit that early SOA adopters have gotten. Often the code from project A is irrelevant to project B, he noted.[...] Findley noted that the projects don’t happen faster because of code reuse. Instead, it is the changed mindset that SOA brings to development and management of technology as a whole that provides the real benefit, Findley said.
I find this reassuring - especially in the light of the growing community effort focussed on the The e-Framework for Education and Research. I think (I hope, anyway) that the e-Framework is side-stepping the commercial focus on re-usability, instead emphasising the knowledge to be gained from adopting an SOA approach, with the intention that this can help organisations plan and prioritise their development efforts. While 're-use' is a stated potential benefit of the e-Framework, it refers more to the re-use of understanding, documentation & design.
The real benefit is to be found in re-usable knowledge, not re-usable code. Of course, as is often the case with a real benefit, it is harder to measure....