--- In [email protected], Alexander Johannesen <alexander.johanne...@...> wrote: > > On Tue, May 26, 2009 at 03:50, Rob Eamon <rea...@...> wrote: > > I would offer this addition: don't pursue an "SOA initiative." > > That, IMO, is the completely wrong thing upon which to focus. > > Completely wrong, eh? :) Well, lots of organisations find out that > their current infra-structure is becoming rather inflexible and jump > on SOA (or what they perceive as SOA) as a means to fix it.
Perhaps the thing to focus upon in this case is making the infrastructure more flexible. Or even better, focus on specific business aspects that need particular flexibilities. SO principles might help with that, but the primary focus should be on the original goal, not on the style of the approach. > I'd say, good for them! Even with a bad lessons learnt they'd still > get some positive outcomes from it; architecture in general, web- > services (or equivalent) as a wrapper, service-minded thinking, etc. How about business-focused thinking? ;-) > > Using SO principles might help structure a system to meet > > particular goals but SOA is not the end-game. > > For companies which are at their wits end, I'd say it just might be, > and that it might not even be a wrong thing to pursue either. > Playing it as an end-game is an opportunity for the organisation to > take it further once their brains click around the concepts. It's the resulting systems that fulfill particular business needs that are the important result, not the style of the architecture. Focusing on the architectural style as the end-game risks missing the business need--which is what prompted SO principles in the first place. Eyes need to be on the business aspects. SO is but a tool in the belt. > > It is one particular way to organize the components of an > > (probably enterprise) architecture. > > Well, not so much a way to organize as it is a way to *think* about > organizing it. :) A way of thinking is part of it, sure, but to what end? So that we can say the system is SO? "We lost $20 million last quarter but our systems were SO!" :-) IMO, it would be better that the system meets the business objectives and exhibits the characteristics set out by the arhitecture goals and principles (which were to be driven by business needs). If the architecture and resulting system(s) are SO, spiffy. If not, no biggie--since the end-game is business results. I get what you're saying, that focusing on SOA as an intermediate toll-gate to something better can be useful. And that by "doing SOA" correctly, one will (most likely) be business focused. But I'm not so sure. Look at how many zero in on just doing web services and how many equate doing SOA with installing and using an ESB. SO as the intermediate goal carries a risk of forgetting that the real goal lies beyond that. The drum being beat by many in this forum is "focus on the business" and on addressing business objectives and needs. Being SO is seen as a good way to architect systems, but we keep having to remind ourselves and others to focus on the business and the larger issues. To not get mired in "SOA" which I think is one of reasons for Anne's "SOA is dead" theme. (Please correct me if wrong Anne.) This might be a poor analogy but perhaps it illustrates my point behind focusing on what is driving the creation/modification of an architecture vs. its style. If I ask for a Victorian-style house, it is important that it be Victorian, but it is infinitely more important that it be a house. A Victorian style barn might please the Victorian society, Victorian proponents and admirers, but I'll be homeless. -Rob
