It is becoming routine to see baiting headlines like Gartner’s latest on SOA Is A Failure. Suitably, this puff piece was delivered by the king of the malaprop.

To save you the time, here is the formula for a Gartner blog posting of this type: “_insert technology to be disparaged here_ is/will be a failure if it doesn’t solve a business problem and is technology for technology’s sake. It will fail even faster if you do not manage it properly and don’t have accountability.” Done. There you have it. No insight, no facts, just the same set of pro forma platitudes that have existed in the IT industry for years.

It is equally important to notice what doesn’t get written: ‘We (Gartner) told you to drop everything and run after this technology previously without making sure it solved a business problem, etc’.

Technorati Tags:
, ,

Who would have thought that the basic principles of loose-coupling, consistent interfaces and reuse would result in the developers doing less ‘grunt work’. Me for one.

“Doing an analysis of production support issues,” he said, “I was really amazed to find more than half the time they were working on issues relating to transactions between applications in this point-to-point environment.”

Point-to-point EAI connections caused unique problems because there was no consistency in the way integration was being done. That made it time consuming to maintain.

“Sixty percent of the time our application team was working to keep the spaghetti wet, to maintain the point-to-point contacts,” Kelly said.

Starting last fall, implementation of an SOA approach based on the webMethods Enterprise Service Bus (ESB) from Software AG has greatly reduced the maintenance tasks that kept developers from developing new applications, the CIO said.

“By moving to a robust messaging bus I could have robust interaction between applications and reuse services over and over and over for transactions between applications as well as moving data,” he said. “That greatly reduced the production support activities.”

Without an SOA environment such maintenance is a major cost for IT, Kelly said. Creating a point-to-point connection for a specific integration may at first appear to be a quick way to deal with an individual problem, but in the long term having the development staff spending the majority of their time on production support is not cost effective, he said.

Prior to the ESB implementation, the application team was spending 64 percent of its time on support issues and 36 percent of its time on value-added development.

“What’s happening now is those percentages are reversed,” Kelly said. “I’m finding now that 64 percent of the time my applications team is working on development and 36 percent of their time is spent on production support activities.”

Technorati Tags:
, , , , , , ,

Last week I attended a vendor conference at which representatives from the industry analysis firms spoke. One session that I sat in was just so egregiously bad that I have to comment on it. The speaker was from the firm that kind of sounds like ‘someone who tends to plants’.

Before he got too far into his scree, he polls the audience with the question of how many services they manage are part of their SOA activities. 10? 20? 50? 100? His blustery response was of this flavor: ‘No, dear audience you are WRONG, WRONG, WRONG because if you have Oracle or SQL Server or Windows XP you have tens of thousands of services — and if you didn’t know about these services, how could you possibly know about anything, you bunch of morons?! I am the ‘expert’, listen to me!’ At that point there was the needle scratching across the record sound effect going off in my head. Is this guy so clueless as to confuse real business services with APIs and interfaces? Yes, in fact, he was and that was just the start of the idiocy. He further goes on to say that you are not doing ‘real governance’ unless you are managing thousands of services — a statement unsupported by anything and one that flies directly in the face of the likelihood of a company having thousands of true business services. Unless you are trying to do governance retroactively, it can start with a single service and progress from there.

His formidable supply of malapropos did not add to his credibility. When speaking to a hype life-cycle chart, he continuously referred to the ‘thought of disillusionment’ rather than the ‘trough’ as well as repeatedly referring to one of the vendor products as ‘InFARvio’ rather than ‘Infravio’. My personal favorite was when he kept talking about doing ‘bottom down design’. No really — he used this expression like six times. This leads me to believe that he really doesn’t understand either top-down or bottom-up approaches, they are just words to him, words for him to torture at will apparently.

It is no wonder that there is confusion in the industry around SOA when vapid windbags like this are presented as experts and make outrageous claims that, with a little thought and examination, do nothing other than prove that they know not of what they speak.

Technorati Tags:
, , ,

A puzzling new meme regarding Vendor Driven Architecture (VDA) has popped up in around SOA. The thought behind this seems to run something like this: companies should buy ‘best of breed’ (BoB) solutions for their SOA and not buy a particular vendors suite. Vendor suites are further demonized by calling them “comfort technologies”.

Wow. Didn’t we hear all of this ‘best of breed’ versus software suite drum banging about ten years or so ago in IT? Then the play wasn’t SOA but EAI. So, yes, by all means go buy whatever you think is ‘best of breed’, then spend years trying to integrate it all into something that might meet your shifting/evolving business requirements over the integration life cycle. I can’t think of too many companies (if any) that would advocate the BoB approach again.

Another dimension to this decision that seems to get lost is that there is value to the Enterprise by constraining technology choices — this is part of what Enterprise Architecture does (or should do). If every project is free to pick their own ‘best of breed’ the corporation will quickly wind up with an unmanageable mess of disjointed products (and integrations, etc). Many of us in large corporations have seen this one play out as well. Enterprise standards are a necessary ‘evil’.

Further, it is entirely possible, valid and valuable to compare business requirements to the vendors/products that the Enterprise has already decided on as standards. It would be rare that there wasn’t a 70% or better ‘fit’ with any contemporary enterprise application portfolio. My point is, the decision to choose a vendor product doesn’t have to be ‘just because'; it can be because an existing vendor can solve the problem without having to introduce another technology/vendor. Stated differently, vendor selection doesn’t by necessity have to start outside of the existing enterprise standards.

Let’s say that the analysis is performed and finds that a BoB vendor has a few more bells and whistles than one of the approved vendors. In my mind, the next step is not to jump to the BoB vendor, but to perform a further analysis around when (realistically) the enterprise would be ready to take advantage of the differentiating feature(s). If the answer is 2-3 years, then there is a good chance that the “comfort vendor” technology will have caught up to the niche vendor. This is one of the tricky things around requirements analysis that often gets overlooked — much of the functionality will not be consumed out of the box, but only after there has been a significant amount of analysis, design and implementation. The industry and products keep evolving, just as the requirements do. Here it is valuable to have a vendor who has an articulated technology roadmap that will guide the follow-on analysis.

So, to me, it seems VDA is a symptom, It is a bad thing only if you blindly follow whatever your vendor is telling you. But at that point, you certainly aren’t doing architecture nor are you doing due diligence on your requirements gathering and analysis. That would appear to be the bigger problem and is much more likely to have far more damaging consequences that ‘catching’ VDA.

Technorati Tags:
, , ,

In the spirit of the segment that Bill Maher does on his HBO show, here are a few of my New Rules for SOA:

1) Stop telling me that ‘there is nothing new about SOA’. Everyone knows. No, really, they do. The fact that services can finally be implemented in a shared, non-prorprietary manner is what is new. And while it shares some conceptual similarities it is not ‘just like CORBA’. There is nothing about this observation that adds anything to a discussion of SOA.

2) Stop calling it SO-UH. My experience so far has been that anyone who says ‘SO-UH’ instead of S.O.A has a better than 90% chance of not knowing what they are talking about. And then they go on to prove it over and over by saying clever things like ‘SO-UH Architecture’, ‘SO-UH Services’ and ‘SO-UH Orientation’.

3) Stop using the tired old expression ‘boiling the ocean’ when referring to SOA projects. I may be overly optimistic in thinking that businesses have learned quite a bit about implementing large projects over the last 30 years and recognize that a phased approach is almost always the best way to go. This is an interesting one because while most true practitioners advocate a quick, iterative approach, several of the big consulting outfits have talked about ‘not thinking big enough’ for SOA and advocating huge, overly complicated rollouts. And, as previously discussed, the agile ‘failing to plan’ dream doesn’t work.

4) Stop saying that SOA isn’t a ‘product’. I am not sure who doesn’t get this. The architecture part of the acronym should give that away. There are any number of vendors who what to sell you their SOA-enabling products, but none of them has an SOA for sale. Similarly, there are also companies that will sell you an Accounting or ERP system. The purchase of the product does not instantly give you balanced books or a bill of materials. The business must take the building blocks they purchased and make them work in support of the business (which is rarely exclusively a technology exercise). SOA is no different.

5) SOA is not EA. SOA is one tool/approach in helping to achieve some of the technical goals of Enterprise Architecture — it is not a substitute for EA. I would be willing to say that without a well functioning EA discipline, any SOA effort will wind up not providing true enterprise services and value. Instead it will yield pockets of unmanaged services that may or may not interoperate based on which project developed them.

Technorati Tags:
, ,

With the typical firm grasp of the obvious, the following quote appears at the top of a posting entitled “When all else fails, try SOA best practices“:

“We’re seeing a lot of people out there struggling with SOA, trying to do SOA,” said Ronald Schmelzer, senior analyst with ZapThink. “They are worrying about building services and running services. They are having to ask themselves questions. ‘Why am I doing this? What services do I really need to be building?’ They need methodology.”

Well and it’s no wonder given the various forums that SOA has on the Internet. The problem is, everyone has their own methodology with about 80% of it being identical to every other, 10% of it being somewhat different and 10% being absolutely useless. That is not much room for differentiation. In my reading of these different approaches, the difference appears to whether the methodology was created by an SOA practitioner or merely a self proclaimed pundit.

For a prime example of the chest thumping echo chamber of ego and useless opinion, take a look at the yahoo SOA ‘discussion’ group[warning, Yahoo login required to view content]. Here you have a handful of preening blovators who go on at great length about esoteric, impractical aspects of webservices and (sometimes) SOA. Endless rants about REST vs SOA, business services vs enterprise services, their out pet definitions of technology terms, on and on. When an unsuspecting non-blovator posts, there is a veritable feeding frenzy to see who can dissect the question and turn it into a rambling thread of gibberish and self promotion. Thus, the majority of the non-blovator questions go unanswered leaving the poster to think, ‘well if all of these smart people can’t come to a reasonable conclusion, then it must be really hard’. Run away from the pundit mosh pit!

This is not to say that there aren’t the occasional quality posts that provide some real value; there are. The problem is that there is so much noise that it is hard to find these nuggets. Just as there are some true practitioners you can go to to get quality information on a highly consistent basis. In my opinion, one of those (rare) individuals is David Linthicum. He consistently delivers the ‘here is what works and here is what doesn’t’ insights that I really appreciate. I just hope that this continues to be the case now that he is part of the ZapThink group.

Right, then there is Zapthink. You really want their website to be the good resource for SOA that it desperately wants to be but visitors are immediately put off by the newbie web design motif that makes it look like a pr0n site, circa 1998. Arrive at the site and you are greeted with: A horizontal scrolling banner, and vertical scrolling banner, an obnoxious flashing banner top center, a font that is about 3 sizes too small to be legible and no real information on the front page, only self promotional come ons. It is a disaster. When you get to the ‘content’ (most times behind a login) it is typically an excerpt that you then need to go to yet another web site to read the actual article. Tedious and unnecessary, especially since many of the linked article merely mention Ron Schmelzer name and some quip that he contributed.

So where does that leave those in search of quality information on SOA? Here are a few of my favorites:

The previously mentioned Real World SOA blog by David Linthicum

SearchWebServices Occasionally has some good postings in and amongst the vendor diatribesn

Steve Jones’ Service Architecture – SOA is worth a look, as wel
l
SOA and EDA Though I wish Jack would ditch the annoying snapshot preview popup

SOA Consortium Insights is updated infrequently, but the posting are typically info dense

The SOA Magazine tends to have good, in depth postings

Todd Biske’s Outside the Box has thoughtful posts on not just SOA but BPM and Enterprise Architecture in general

webservices.org can be a bit hit or miss, but you can usually pan a few nuggets away from the vendor annoucements and whitepaper-cum-advertising literature that you find there

Technorati Tags:
, , ,