James Governor's Monkchips

On SOA at BT: Confused by Andy Mulholland

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

“We finally have the case study we have all been waiting for; British Telecom has announced after some eight years it has nearly finished making its entire infrastructure ‘entirely SOA based’.

Eight years of work on this certainly supports the statement that SOA is not new, but as anyone who has ever worked in a company that has tried to create standardisation by standardising on a single product will quickly recognise it’s not the ‘what’, meaning the product, but the ‘how’ meaning the implementation that matters. Our understanding of how to implement SOA has got better in the last year, but even now we are far from a universal agreement. Looking at the press release more carefully reveals that BT has been experimenting with Web Services since 2001. This to my mind pretty well guarantees that anything done six years ago is now obsolete and not going to work with anyone else.” [italics mine]

SOA doesn’t necessarily define implementation details, does it? I can see no reason why BT couldn’t have done extremely useful work in the past modeling processes, refactoring legacy systems, driving towards modularity and so on, as it moved towards SOA with its 21st Century Network. Andy is a really bright guy, with plenty of architecture experience, so his statement above surprised me. Am I missing something?


  1. SOA doesn’t define the implementation details (tool junkies notwithstanding) but I would venture that the contract definition, and the methods of the implementation (classic RPC-style of the early frontier vs. Message-based or REST based of the new world) don’t exactly like each other. There is a significant impedence mismatch in many of the implementations.

    I’d venture further that the granularity and modularity cuts that one would have made in a CORBA or RPC services mindset is significantly different than the more coarse and business-oriented separation and services found to work better in more modern attempts at SOA.

    All that ventured, I’d say you’re missing that the mindset that came up at the RedMonk JavaOne debate on services (REST vs. WS*) and the changes in what people have found to work since the debut of the web service moniker *have* changed significantly, and with it the applicability of the original services.

    But maybe I’m missing something as well….

  2. Cheers Chris. I get that argument, I just felt confused by the implementation point.

    Dallas – As far as i know a great deal of BT’s planning has been business contract oriented. As a company being deregulated it had to be. On the WS vs REST point , I think we’re still very much in a two speed world. WS-* people are still doing WS-* stuff, without the UDDI vision of five years ago. But REST is still a technology under consideration in the enterprise rather than a mainstream way to build service oriented architectures.

  3. Hi James

    its a fair point you make, and i should have been clearer. I believe, rightly or wrongly, that there are two sides to SOA, a technology implementation and a business process design, or may be redesign might be better way of putting it. A key challenge in the last five years and certainly right now and looking forwad is the question of how does my business process work with the outside world. Internal Orchesration versus external Choreography, and as ever the devil lies in the detail!

    I commented on BT because i believe it is an great example of the technology benefit, and they give impressive details which are often lacking in other stories but i believe the basis for the design of business process and capture within services is now becoming a significant point and i doubt if the thinking some years ago when they started on the SOA project would have been able to predict where that is going.

    so no problem with the architecture side, more concern with the busienss process side

    regards andy

  4. Actually, I have worked with people from BT on several SOA related projects including ebXML and WS-*. BT gets it and has been very pragmatic in their approach to implementing standards.

    SOA is an architectural paradigm, nothing more, nothing less. It often confuses people who cannot differentiate between abstract and concrete (a test of intelligence). SOA, as described in the OASIS Reference Model for SOA, is a view of infrastructure focusing on services as a means to connect capabilities and needs over disparate domains of ownership. It can be built using multiple technologies. I would argue that you can build a REST style Service Oriented infrastructure in compliance with the OASIS RM. It is also possible to built something that does not conform to either the REST style or SOA RM and implements “anti-patterns” of SOA.

  5. On to important things – did you catch the tour today live? I am green with jealousy! My pic is Vinokourov. Guy is a superb rider and too unpredictable for others to form strategies to keep in check. either him or my old mountain biking buddy Cadel Evans.

  6. James and Duane – Business contracts change most of all, especially in telecomm, having been in that industry for a piece of life. And to Duane’s point, it is exactly a paradigm, and the implementation, as was your original point, is what shifts, and the business entities and operations exposed as services eight years ago may have become irrelevant or obsolete due to changes in the business, organziation, operating procedures, or technical implementation practice in the interim. It’s from that point of view that I would still stand by Andy’s statement as correct and relevant.

    I don’t believe the technical approach is what has obsoleted things in the original context. It’s the fact that in six years, telecommunication business changes quite a bit, and has changed over the past six years. Mix a changing business environment with a rapidly evolving technical practice and shifting architectural approaches guiding that practice, and implementations, being the convergence of architecture, business and technical tools and standards, and it’s not very surprising that the results are obsolete and incompatible.

    I asserted when web serivces first emerged that the challenge was never technical in SOA or distributed computing historically, but in the agreement, the business agreement, that the two systems agreed on. The ease of implementation and rapidity of evolution in services in this latest generation of distributed systems has further highlighted the fact that the contract is the hard part, and what we’re really getting is agility, not enduring, classical, reusable systems. More done faster. IMHO of course. 😉

  7. Great stuff Dallas. Its a very good point about changing business specifications. that said- BT does have a long term plan and has done some good work in driving towards it, constrained by regulatory issues and so on.

    Andy- thanks for the reply. I think I see a briefing with BT in my future…. 😉

Leave a Reply

Your email address will not be published. Required fields are marked *