Jim Webber, a thought leader from ThoughtWorks, also known as the "World Wide Webber," has been out preaching his message on "guerrilla SOA." He recently appeared on this podcast on the InfoQ site. Jim not only states a good case for his ingredients for guerrilla SOA -- MEST (great explanation here) and SSDL (SOAP Service Description Language) -- but also reminds us of the whole purpose of SOA in the first place. Here are some snippets from his recent interview. I know Jim from my WebServices.Org days, and Jim hates middleware with a passion, as you will pick up from this interview.
Q: What is 'guerrilla SOA'?
Jim Webber: "A lot of SOA projects that I’ve seen have been somewhat akin to mobilizing an army… you have hundreds of consultants.. ..a whole bunch of armaments in the form of huge sophisticated middleware platforms… and …the whole thing is very heavyweight and somewhat cumbersome..
"When you’re going for that kind of big upfront SOA.. …you lose a lot of opportunity to prioritize and deliver your business options based on your business priorities and business values."
Guerrilla SOA turns that around. You’re looking for a much more lightweight engagements. We want to address discrete business problems, organize priorities according to the business stakeholder, and get those processes implemented rapidly in an incremental way with lots of feedback."
"So we can actually start to prioritize across the business which processes are the most value, and which ones are most heavily used and so forth. And implement without having to wait for a big program of work to be established. Put the ESB in place, or other kinds of technical dependencies."
Q: Does this work in both large or small scenarios?
Jim Webber: "The nice thing is it works in either. Because you have specific priorities the business gives you… any given time, and focus on those. As long as the business can keep coming to you, you can scale ad infinitum, up until the point you've implemented all the processes in a given domain or in a given business."
Q: Is this approach compatible with large-scale vendors' middleware?
Jim Webber: "The approach helps us to decouple dependencies between what the businesspeople want and the tools we have available, ESBs and so on. I would absolutely use those tools to where it make sense to me.. to implement the process that I’ve been instructed to automate. If it doesn’t make sense, I wouldn’t use them. I would use other tools -- simple job apps, store and forward-based architectures, message brokers -- where it makes sense within my current context."
"But the important thing is I don’t let my current development context bleed -- I don’t let those abstractions leak into other development projects. We like to keep each process that we’re implementing relatively isolated, so that the service ecosystem grows. On the other hand, if we allow everything bleed together into a big SOA platform, you tend to get tight coupling and so on. And that restricts your options for evolution further down the line. The business people can see we have this much broader view of the processes as a whole."
Q: What's the risk with tight coupling?
Jim Webber: "The classic scenario is that if I’ve got two systems that are tightly bound, and I change one, I risk breaking the other. We saw this back in the day with CORBA processes, tightly coupled through an IDL, now we have Web services, where we tightly couple through another IDL called WSDL. With tightly coupled systems, there's a ripple effect. When I come to you and say I’m going to make changes, first reaction is no, because you’re going to break me. Then we get into this paralysis, where neither of us can make progress, because we’re so scared of damaging each other. We need strong governance and so on and someone to strongarm to make both parties move."
Q: What's the alternative?
"Instead of sharing types, I think we should start to share business schemas and business messages -- owned not by the technical people, but by the businesspeople. That gives me as the developer of a service an interface that I would make sure that I adhere to… and honor the contract in my service implementation."
Leave a comment