This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Re: As the pendulum swings
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.
Mark Bonafe wrote an interesting post on the whole OO vs procedural debate and how SOA may be just the return to procedural programming.
The problem I have with this, and several other posts on the topic is this, SOA has almost nothing to do with programming. Its about the (functional and non-functional) decomposition of a system. What are its main building blocks. And you know what ? Programming language/style has little do with it.
Frans Bouma asks if "OO is the goal or the tool" ? My answer: I have one goal, and it has nothing to do with OO, SOA, or Domain models. My goal is for my clients to be happy with the system, and to make a profit.
Anything that drives me to this goal is welcome. It used to be that OO was my favorite tool/roadmap, today I use SOA for architecture, and OO for the actual development. Gone is OO Analysis and Design at the system level, supplanted by SOA.
I find that the pendulum doesn't have much to do with it, and here's why. SOA isn't about code, OO is.
I think that it is common knowledge in the industry, that the larger a project, the lower chance that it would succeed. Even ( especially ? ) if using an OO methodology ( aghh! the "M" word ! ). Anybody wondering why ? Could it possibly be that the methods that we were using for small-medium scale development efforts in the past don't work so well on big projects today ?
I think that the main reason that OO couldn't hold up, was that OO was about modelling the world - for every object in the real world, we'll have an object in code. Big systems aren't so much about objects in the real world, but more about interactions, processes, and flows.
This may sound like the pendulum swinging back to procedural programming, only, its not programming. Its about the system's architecture. And its not done by programmers using a computer language, but rather by business drivers and 30,000 foot architects. ( I actually wish there were some "low-level" programmers that brought them down to earth every now and then ). These are the people who tell us what we need to build.
Here's a hypothetical anecdote between a business driver(B) and an architect (A):
(B)We need to a way to save the data we get, and use it later. (A)We should have a persistence thing (service) in the system.
(B)We need to do all sorts of checks to see that the data we get is valid. (A) We should have a validation thing too.
(B) We need to integrate this stuff with our partner companies' systems. (A) Well, we need some way for our systems to talk together - webservices might work, but our development shop knows more about MSMQ. But, we'll need to have a way to move to different communications later. We should also have something to authorize things ( authorization service ).
(A talking to staff later ) I guess we need some way to get all of these high level requirements to fit together. Did somebody say OO ( or OOD&A ) ? That has nothing to do with any of this stuff ! What we need is something to tell us about how to structure a system to do all this.
SOA is about what the major building blocks of a system are, and how they work together. In other words, the executive summary. This IS the system. OO is how to build each part - or, at least OO seems to be the best tool we have today for actual development.
Frans - SOA is about WHAT is the system, not so much as to WHY. The why is actually quite simple - "because that's what the client wants". OO is, as you said, about HOW to get it done.
Previous Topic
