Fight Fight...
Reading Dan Creswell's weblog and his recent post on "SOA definitely doomed" and a couple of replys (including me) I think SOA is heading towards the "trough of dissolution" which is great news. Why? It means that the shiny happy technology wave is going to crash soon and we can get on with what SOA is really about this means
1) SOA is not about technology, not ESBs, Web Services, EJBs, Spring, .NET, Java etc etc etc
2) SOA is not about RPC, Messaging, Events or anything else
3) SOA is about changing the way you think about applications and enterprises
First off Dan goes after the "we don't know what SOA is" - We now have SOA RM, not everyone is onboard yet but its a start.
This is the shift that SOA represents and is the thing that will continue on. Undoubtedly there will be people who don't do SOA in the future, hell there are people who keep doing waterfall today (and failing as a result), and there will be people who say they do SOA in the same way as people say they do agile today when all they are doing is traditional iterative.
SOA is an important shift that has been used successfully in massive systems for many years, and which is leaking through to the big, middle and small mainly via vendor product marketing, in a similar way that OO really made the break through in the 90s, with various companies pushing "their" take on OO, paticularly OOD.
The rest of Dan's issues are focused around the development of SOA systems, which is part of the challenge for anyone trying to understand SOA. The vendors products are NOT about architecture they are about delivery, but SOD of IT was never going to catch on. Dan's points on the confusion in this technology area are very similar to those in the 90s where people argued C++ v Smalltalk v Eiffel etc etc and lost the fact that the importat shift was the change in thinking, not in technology.
His point about complication is well made, SOA is aiming at a more complicated challenge, its aiming to create a common language between diverse stakeholders. But then at the moment we have nothing with which to communicate between these groups effectively and that cannot be allow to continue. But I remember only 5 years ago being told that business people would never understand Use Cases, and now its become a natural way to discuss requirements.
SOA is about a simple principle, making your IT look like your company and enabling it to change in the same way as your company. This isn't about STOPPING small agile projects, its about enabling them, but enabling them in a way that doesn't make them the maintenance nightmare of tomorrow.
OO has failed in the large, its time to try an approach that works.
For the record Dan could definitely kick my arse.
And for an example of the OO wars of the 1990s, here is a cracker from the inventor of C++ and a troll from 1997 and back in 1994 people were not sure what OO was about
3 comments:
I'd rather hope I never have to go kick your ass! :)
If we are indeed in the trough and about to come out the other side with less hype and a good dose of reality, I'd be happy with that. I might also want to dump the SOA name though and call it something else at the danger of inducing yet another (sigh) hype curve - maybe not then.
I don't have a particular axe to grind in respect of SOA other than the fact that as a responsible architect I want fact not fiction so's I can figure out how to use it right and deliver benefit to the appropriate people.
"OO has failed in the large, its time to try an approach that works."
Hmmm, gonna be nit-picky - I don't think OO has failed - it's mostly about the way people have used the technology and I'm willing to bet there'll be a lot of OO kicking around inside this next generation of systems.
OO and software design in general is about getting the right set of API's at the various layers of your system. It might be that the top layer looks more service like (whatever that turns out to be) where in the past it looked more like an Object (whatever that is). IMHO, we'd just be formalizing (and hopefully improving) something that good architects were doing back with CORBA and got forgotten whilst we messed around with the horror known as J2EE and phoney SOA.
Dan Creswell
http://www.jroller.com/page/dancres
Couple of responses here.
OK, let me go really retro here. First take the writeups on SOA and do a replace all with Client/Server. Now everybody hold their breath for just a second here and take time to think this through. What client/server was supposed to be, not what it became is esentially the same as what SOA is supposed to be. The problem is that C/S became a marketing term and devolved in to just another name for ODBC with a slightly different stack. C/S and SOA have the same issues.
1) Getting business definition from services.
2) Governance of shared services.
3) Redefinition by sales critters.
4) Lack of Modeling.
My response on OO. OO is a real interesting topic. IMHO where we went wrong with OO is to call it a software development methodology. For OO to work it has to be a requirements methodology that can also be used to help develop software. In the end in the analysis model Objects, Use Cases, Generalization, Specialization, are agnostic as to whether you are developing software or using liveware to implement.
In the end it is all an issue of overselling and undercommiting.
Art
I disagree Art that SOA is just Client Server 2.0 :) Client server split a problem into two bits but it didn't really say what those bits should be beyond "GUI stuff" and "Backend stuff". Client Server was a technology evolution enabled because clients actually had some power in them. SOA is about changing thought around the whole system and not just the technology. Client Server projects could have been built in an SOA way, but CS is just an implementation style.
Post a Comment