When MWD started in 2005, the first topic we sunk our teeth into was SOA (it was 2005’s Cloud Computing, pretty much).We researched the technology and the practice pretty thoroughly, I think (along the way tackling “SOA 2.0” among other things), but in mid-2007 we drifted away from the topic a little. At the time it seemed that we’d said pretty much all we could about the subject – we’d done a lot of technology and architecture research (looking at the need for governance, the need to consider consumer as well as producer service lifecycles, and so on), and there were still relatively few opportunities to dig into actual case studies to start to determine real-world best practice experiences.
Over the past few months, though, I’ve started to pick away at SOA once again – it feels to me like we’re at the stage where there are some interesting real-world stories to dig into, and at the same time there’s still a lot of people looking for answers to some straightforward questions about the nature of SOA and how to deliver value from a SOA investment.
With this in mind, I was excited to see the launch of a “SOA Manifesto“, styled after the Agile Manifesto – which has had a significant impact on expanding awareness and understanding of Agile development techniques. I was intrigued to see that Anne Thomas Manes of Burton Group, of “SOA is Dead” fame, was one of the signatories – so I decided to ask her about her involvement in the drawing up of the manifesto. I know that Anne and her team do a lot of case study and best practice research on SOA, so I was interested to hear why she wanted to get involved. Below are my notes from our conversation.
NWD: What kinds of issues have you seen that made you want to get involved in the SOA manifesto?
ATM: Fundamentally, the amount of people I’ve seen who still think SOA is about technology rather than design/architecture. Though we are further along now because we have better books (like Thomas Erl’s books), I just felt that there’s still a need to show people that SOA is about designing systems differently. When I wrote the “SOA obit” blog entry, it was really a reflection of the fact that only around 15% of the projects we saw were delivering significant value; and maybe another 25% were just about breaking even. The majority of projects we’ve seen just haven’t delivered a decent return. My goal in being part of the SOA Manifesto group was really about trying to get people thinking about SOA in a different way, so they could use SOA to enable much more business-aligned portfolios of applications.
NWD: What’s the precise purpose of the manifesto, do you think? What does the group want its value to be, and to whom?
ATM: We very much admired the Agile Manifesto, and followed that path. When it was published a lot of people didn’t know what Agile meant; it really helped crystallise the role and value of Agile development. The value of the SOA Manifesto is hopefully similar – it’s in the way it establishes a set of core principles and value statements to help people think about what we think are the right things and getting SOA back on the right track.
NWD: What kind of feedback have you had on the SOA Manifesto so far?
ATM: Well, there have been a number of accusations that the content is too general-purpose – that there’s nothing that’s inherently Service-Oriented about it, and that you could apply it to many other things. You know, I think that’s true – but I don’t think that it invalidates the principles at all in the context of SOA. This kind of reflects the whole point of doing the Manifesto: the challenge we’ve had with SOA implementations is that too often, people have ignored the stuff we know works in the rush to try out a shiny new set of technologies.
NWD: Is the SOA Manifesto “group” planning to build on this initial statement? If so how?
ATM: We currently have over 300 signatories to the Manifesto [Now around 475], and all the group members are blogging/tweeting about it. We’re trying hard to make sure that we get as many signatories as possible, in other words. But, just as was the case with the Agile manifesto, there’s no group intention to directly commercialise this [in delivery of a body of knowledge, training, etc].
I’ve looked at a lot of the commentary and criticism of the SOA Manifesto out there, and a lot of it seems to be about saying “so what?”. But as Anne rightly points out above, the fact that the principles in the Manifesto are quite applicable to many types of business-technology change initiative doesn’t make them worthless. The fact is, SOA implementation *is* a business-technology change initiative.
I think the other thing to bear in mind, when looking at the SOA Manifesto and SOA analysis and commentary generally, is that no-one in their right mind is saying that SOA is always the right answer when it comes to application implementation (though in my view there’s an abstract business analysis/architecture part of SOA, reflected in OASIS’ SOA Reference Model specification work, which has general applicability across all domains). There are many technology implementation domains where SOA principles aren’t the right ones. As the Manifesto points out, SOA should be all about a set of architecture decisions that promote flexibility and agility (through things like loose coupling). In some situations, there are other factors (like extreme performance) which might trump a general desire for flexibility – or at least create interesting tensions for architects.
So – to sum up: personally I’m a fan of the SOA Manifesto. It’s not perfect, but nothing designed by committee ever is. It *is*, I think, “good enough” for what it needs to do – which is to add more weight to the argument that if you want to deliver value from SOA work, you have to continually remember to focus on a set of IT architecture principles and avoid getting too distracted by shiny products.
