Category: SOA

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:
architecture, dubious, soa

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:
architecture, design, esb, enterprisearchitecture, soa, software, technology, webservices

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:
soa, analyst, bottomdown, suckage

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:
architecture, soa, vda, enterprisearchitecture

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:
soa, enterprisearchitecture, newrules