--- In [email protected], Alexander Johannesen <alexander.johanne...@...> wrote: > > 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.
Excellent points! My concern is this. SO supposedly provides flexibility. So people take that and say "let's do SOA so we can be flexible" without identifying what needs to be flexible and what form the flexibility needs to be. Once those are determined, any number of styles can help that be achieved. > 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. That's where we diverge. SO, IMO, is not the path of salvation, though I imagine you're just being a bit heavy on hyperbole. It's a path. How effective one is with SO will be largely determined by how effective one is with architecture and planning in general. Alas, I have no good evidence of that. It's just anecdotal. > > 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. Amen to that. > 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. Excellent point about the end-game notion. An architectural style will keep one in business? I guess I get that sense from a few folks in this forum and elsewhere but it is a sentiment with which I utterly disagree. The "must do IT things this way or you'll be out of businss" mantra has been repeated many times over the decades. If anyone has examples where this turned out to be true, or where lack of adoption significantly contributed to business failure, I'd love to hear about it. > The important part to me is not the practice of SOA, but the > philosophy and thinking behind it. Being service-oriented can indeed be a Good Thing. > 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. How would we be able to tell that's what they're doing? > > 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. :) Definitely a strawman. The point I was attempting to make (using either my negative view or your positive view)--it doesn't really matter if one is SO or not. What matters is *some sort* of planning, organizing, enforcing, managing, etc. The state of the IT landscape in most places can be largely attributed to apathy and narrow, short-term thinking. BA and EA planning, in *any* style, will provide benefit, IMO. > 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. Very true. > 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. There are many contributors to the confusion surrounding SO and SOA. > *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. I would have thought so too but I consistently run into folks away from this forum who firmly believe that SOA is WS-*, ESBs and such. And when I try to persuade them otherwise, they think I'm the one who is off the rails. Even when I can sway them a bit that the SOA=WS-* view might be wrong, they still grudgingly hold on to their old view. SOA as a meaningful term was toast long ago. Excellent exchange! I really appreciate the sharing. -Rob
