One of the promises of SOA and SOBA is that applications will be less complex, and therefore can be developed more quickly. This complexity is reduced by having strict rules about how SOBA apps will leverage and reuse services. In essesence, SOA takes an architectural approach to the problem of apps that take a long time to create, deploy, and modify.
Interestingly enough, Agile Project Management methods (like Scrum, XP, and others) solve a very similar business problem in an entirely different way. Instead of breaking up the complexity of the application in order to speed up delivery, they address the process by which that large and complex application is created using methods that focus on embracing scope change (while controlling it), improving dev team communications (while reducing the time spent on it), and prioritizing the feature set.
Clearly, these two approaches are not tied to each other for success. An XP project can (quickly) deliver a stovepipe app that is difficult to maintain. A SOBA can be (quickly) developed using a heavy process like RUP. However, both SOA and Agile SDLC methods use the same problem definition to justify their existence, and both purport that each, in its own right, is sufficient to solve the problem.
Clearly, if one problem spawns two different solutions, you have to ultimately ask the question: are both solutions necessary?
In my opinion, SOA does nothing to address the fundamental problems caused by using a bad SDLC process. Agile software development processes go a long way towards making life livable for the people who write code for a living. On the other hand, Agile development processes do nothing to address the fundamental problems caused by system definitions that are too complex, refuse to consider reuse, and will ultimately cost a fortune to maintain.
So, in a way, both are needed. On the other hand, I think we need to frame the problem a bit differently so that there are clearly two different problems being solved. That way, when SOA solves one, and agile methods solve the other, both can be measured independently of one another.
My suggestion on how to reframe the problem statements to account for both—
Agile methods solve the problem of software development processes that produce frustration, rework, long hours, and missed expectations. These are very tactical needs tied directly to the act of developing software.
SOA solves the problem of systems that embody multiple business capabilities in a non-reusable manner, thus forcing developers to re-invent the wheel every time a new application is created. These are architectural needs tied to the business’ need to deliver consistent solutions in a rapid manner.
SOA makes all programming obsolete.
😉
I think you need some sleep. You are comparing apples to archery.
SOA is about architecture, XP is about development process. You can use XP to create a SOA based solution. Or RUP. Or our all favourite hack and go development technique.
And last time I heard about them, all agile techniques go a long way to reduce complexity and promote reuse. If you have a project owner which refuse to do any reasonable things, no method or architecture will save you.
Hi Thomas,
If you go back and read the post, you can see that I am not pretending that XP and SOA are not different kinds of things. I am saying that they are largely justified, to executives, using the same words. My suggestion is to fine-tune the justification for both so that implementing one is NOT seen as a reason to avoid the other.
— Nick
Enterprise Architect
Certified ScrumMaster
I did read your post. My reply explains how I read it. And I didn’t see it the way you explain it now. What I saw was two unrelated things compared.
Perhaps I am the one who needs some sleep. I know I need it:)