On Thu, May 28, 2009 at 02:14, Rob Eamon <[email protected]> wrote: > 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.
*Any* number of styles? :) Well, I guess that depends on how loosely you define what we know of as "SOA". For me it becomes somewhat specific, a way of thinking and a set of principles that I think are pretty damn good in terms of achieving this fabled flexibility, and I dub that SOA (as very close to the SOA reference model; http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm). There are other styles which wouldn't be as effective, like the "cobble things together haphazardly" architecture, "throw at the wall and see if it sticks" architecture, and of course, Big-bang architecture. :) >> 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. :) Me, 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. But, but ... I wrote "the path to salvation", ie. we both agree it's a path. I think were we diverge is not on whether SOA is a end-goal or path or anything like that, but simply to how those business requirements are defined. I'm probably a *lot* fuzzier around the edges (hence my disdain for ROI reports and the like), I'm into long-time sustainability more than meeting immediate business goals. And, I have to admit, I suck at sales and being a business dude, I can't stand thinking in short-terms and I'm dreadful at balancing internal budgets because I feel (well, I should say, I know! :) they aren't beneficial to the longivity of the business as a whole. But that's just me, but I'm comfortable being a contrarian in this aspect. > Alas, I have no good evidence of that. It's just anecdotal. Amen to us both. :) > An architectural style will keep one in business? Well, kind of. If you take IT seriously, then having IT shape itself as flexible as the rest of your business I think is a good idea, and I suspect that that's what we call "architecture" because there's a plan of sorts involved. My own opinion of why SOA makes sense is that I can make a plan (architecture) through something I find quite organic (services), SO in system (but without too much rigor). > 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. But I'm not saying "this way, or die", I'm saying that SOA lends itself to the flexibility any organisation might need. We agree flexibility is good, no? And that SO is good, yes? Nor am I saying must; I'm fine for you to go out of business. :) > 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. I've been involved in a number of projects that was taken over (from others who did things, shall we say, more conventionally designed) and where SO (and agility) was enforced in order to save them, so, yes, anecdotal evidence and just based on my experience, but I'm not convinced my projects were that unique. I've just seen lots of evidence that speaks for it, and I've been in this business for almost 20 years. Let's try to be clear about something I'm pondered a lot lately. All this stuff we're talking about here, it's really all about how to make stuff work in ways that most people (within an organisation, or community, or domain, or human race, or whatever) can agree or understand, to easier be able to replicate good results. This is why methodologies were embraced to begin with, but the trick is of course always to refine and come up with ways that works the best, and that's no easy task. Now, no methodology in the world can replace good talent, so many will try to squeeze that talent's brain, and create a framework out of it so that his / hers knowledge and experiences can be converted into something other can use (when their brains are drained or not working properly). If you got the talent and have an organisation they thrive in, you don't really need much methodologies in order to be successful, and in many ways, you don't really need things like agility, SO or whatever as people will come up with these or similar things all by themselves. So. So what we're talking about is a distillation process of sharing that talent out across an organisation which got people of all levels and talents, and try to make some common ground in order to be successful. People who follow one convention will not always think some other convention is a good idea, no matter to the credentials of the convention. Some times change itself is a good catalyst, other times you really need some convention because parts of your organisation's got mustard for brains, or, if you're lucky, too much talent (read: ego) to cooperate. This is easy; this is a people management job. To reiterate what I said a few posts ago ; >> The important part to me is not the practice of SOA, but the >> philosophy and thinking behind it. SO is just a way for me to convey a directed philosophy of designing software. I would never use the whole SOA reference model, and certainly not formally, but it is the closest we'll get to some ideal I see working again and again. If people at least could agree to the SO principles, we'll go quite far from that alone. Forget about implementation details here; that's just a couple of technical meetings and a talent with big enough ego (or balls or pondus) to pull off, and is actually closer to people management than people think. In this sense, the SOA reference model is pure gold, as it points in a direction in which disagreement usually is a quibble rather than fundamental platform changes. >> 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? Well, I hear quite often things like "oh, so you mean CORBA, only done right?" or "just like DDD, only higher up?" or "ah, so define services instead of functions?" and "services are just like real services, yeah, that makes sense" or (more towards implementation) "I've been doing that for years" or "like instead of using Maven for the configuration, just put the configuration in a network?" Or, "so, use the ESB core rather than the specialized tools?" and so on. People usually get SO quite fast, in my experience, whether they're technical or otherwise. Next question is of course if we *need* to know this is SO or not. I'd say, as long as it works ... :) ... but using the SO moniker helps communication and spreading common idioms of operation. ... > 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. Agreed, although I personally think the SO moniker helps communicate a joint understanding or direction, and helps people work together better. I guess someone will jump in here and point to the disjoint between design and implementation, orchestration and choreagraphy (I'm not really big on these things myself), and perhaps they're right, but to me the "thinking in terms of services" as a philosophy is far more important. >> *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. Unfortunately true. I still blame the big companies and consultants for this, though. Except the good people on this fine mailing-list. :) Regards, Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
