This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: SOA vs? XP - well, maybe A vs XP might be more appropriate
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
There's a building buzz about SOA. I don't think that anyone can argue with that. Also, I believe that for large systems, SOA will become the new paradigm. Don't take my word for it, the PAG group at Microsoft have recently began rolling out ShadowFax, the still emerging definition of what Microsoft sees as SOA's future.
Now, as a developer, I am pro TDD, using it constantly and consistently. I have been thinking a lot about XP as a way of developing systems in teams. The success stories have been increasing over time, and XP appears to be a valid development methodology in its own right. Not only XP of course, the entire Agile camp ( XP, Scrum, DSDM, etc ) has been raising some serious concern in "heavy" development shops.
What interests me is the mesh/meld of Architecture ( yes, with a capital A ) and agile methods. It would appear that the two, although not entirely opposed, don't quite fit. Agile methods allow the system's architecture to unfold as the system is built, keeping it as supple as possible. The architecture camp, of which SOA is a member, define the system's architecture up front. Of course, small intra-service development efforts could occur before or in parallel to the architecture definition process, however, their effect on it would be minimal at best.
From a historic perspective, I think that where SOA comes in, Agile methods have yet to be introduced, or, if they have been already introduced, the data as to the success of agile over non-agile are inconclusive at best. Very Large Systems ( once again, capitalized ), like those developed for financial institutions, the military, and government have seen very little agile action at the project-wide scale. These systems have multi-year development+deployment schedules. I have recently done a stint at one such project. Waterfall, although not called by name due to recent bad press, is still used, but under the guise of tailoring some other development process.
On these large-scale development projects is where SOA will have the short-term largest impact. This is for the simple reason that project architectures are all different, but there's nearly always only one development methodology for the company. The entrance barriers to SOA are much, much lower than any agile method.
I would be very interested in hearing any accounts of the SOA-Agile mix. Any thoughts would definitely be appreciated.
Also, "small-scale" SOA sounds like an interesting idea. How relevant is SOA to not-so-large systems ? As a standalone developer, I'd like to know what improvements SOA can bring me over OOA and other alternatives. I'm always looking for ways to be more productive and increase quality at the same time. TDD has recently done exactly that. Some of XP's practices have also contributed. SOA looks promising. Its the integration of these behaviours that interests me today.
Previous Topic
