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….
Excellent post. I am going through a few of these issues as well..
[…] This diagram tries to express the role of the local developer to act as an agent enabling and supporting change in an HEI. The developer deals with the remote, outsourced ICT system at a technical level, becoming one route through which the HEI ensures it gets the best possible value out of this arrangement. Remote services are, nowadays, guaranteed to offer some sort of application programming interface (API) which allows the more technically capable customer to tailor the service to their needs, rather than simply being obliged to use an undifferentiated, default user-interface for example. Local developers are increasingly networked with their peers in other HEIs (not least because of the efforts of the DevCSI project), so they become quite powerful in being able to exploit commonly used remote services through the free sharing of knowledge, technique and even code. And because local developers are, in some case, embracing a more agile approach to development, they become the conduit through which the end-user expresses their needs to make the remote, shared service better fit their local, idiosyncratic needs. Developers can become surprisingly aware of ‘business’ processes and information flows through an HEI, as they have to deal with them at several levels (I wrote about experiences of this sort in a previous post, SOA and reusable knowledge). […]
[…] then found this on Paul Walker’s blog, “SOA and reusable knowledge” (Feb 26/08), which, as the title hints, downplays the idea of re-usable code, in favour of […]
EA/SOA are about business process, not technology…
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…