Hiya, On Wed, May 27, 2009 at 02:29, Rob Eamon <[email protected]> wrote: > 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 think this is my point, exactly; a focus on some things that needs flexibility can get you a long way. A lot of companies I've worked with are locked down hard in terms of infra-structure, and they really have no idea how to fix it. I think more and more realize you can't buy shrink-wrap to fix it (ie. some ESB), they have to put some serious thought into it. The beauty of SOA as a way of thinking rather than a way of doing is that even when your perticular project fails you've learnt something important about those principles, use the best of that in the next project and move on. It's a bit like when I started doing Topic Maps; once I got it, I couldn't go back to designing data-models quite the same, no more lookup-tables, shared indeces, atomic entities, etc. Once you go down the path of a new paradigm that just makes so much sense, it's hard to go back. And that's my point, really; once you go thinking in terms of SOA, you're set on the path of salvation, even if you will sin a lot along the way there. >> 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? ;-) Why not? :) It's a crazy concept, really, that businesses should start thinking about business. But I guess it has taken us this long to realize that IT isn't disjoint or separate from the rest of the business. >> 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. Hmm, maybe. I'm not going to state it so black and white, though. To me, "resulting systems that fulfill particular business need" is just business-speak for "staying in business" with the odd "excel in our business" thrown in if you're good at it. We're discussing end-game stuff here, but in my world there is no end-game, never will be, never was. It's all a perpetual furnace of ideas and practices, no matter what business you're running, with people and products and all that other baggage, and it's going to be there whether you do something called SOA or not. By this token the architectural style is *the* thing to focus on, because if *that* is what's going to keep you in business, then that's the important part of it. And in a sense, it's the end-game of comapnies, even if it isn't the end-game for people. The important part to me is not the practice of SOA, but the philosophy and thinking behind it. I can only imagine a lot of people out there are doing SOA without knowing they're doing SOA, and that's a good thing. >> 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!" :-) Well, it's a bit of a straw-man, really, because the counter is "we went $20 million surplus last quarter because our systems were SO!", and I can say that without any proof, too. :) > 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. Well, staying in business is the ultimate end-game, and as such I'd say SOA might play it. > 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. Ok, well, we agree, of course, and yes the risk is that people are doing stupid things in the name of SOA thinking they're doing SOA when they're decoupling one aspect just to marry it to another (moving the problem rather than solving it). But that's a risk with anything, including philosophy, religion and politics, so we're in good company there. I think we have to blame big companies selling SOA for this perticular mess, saying "WS-* in a system like ESB is SOA" with a straight face. *sigh* I'd still think that people involved with anything SOA at least read the reference standard, a few articles and perhaps join this mailing-list to learn and move away from the shrink-wrap nonsense, though. There is hope, there is an episode 4, right? > 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. Hehe, good one. Unless you're Jesus, in which you'll be Right At Home (TM). :) Regards, Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
