Archive for May, 2007

SOA Soup

Tuesday, May 8th, 2007

As a follow on regarding my blog on Financial Services SOA Adoption Challenges continued analysis from many is adding more color to the gotchas.  CIO magazine ran an article in the May 1, 2007 issue entitled “Stuck in the SOA Soup”.  The article points out there are 115 standards related to SOA (quoting Forester Research).  The plethora of standards means there is no unified approach to SOA (not to mention process).  There’s a simple but spot on quote in the article from Hong Zhang, director and chief architect of IT Architectures and Standards at General Motors: “The challenge is that there is no common, consistent architectural framework to guide the evolution to SOA”.

I see this problem rearing its head in Financial Systems IT shops.  Most are defining their approach from scratch, and this leads to lots of learning (making mistakes, correcting them, etc. some are successfully maturing their approaches gradually, but it’s taking a lot of time, while others fail altogether).

The article suggests focusing on quality of service (I fully agree, see my #1 point in my blog entry The Registry is Important but There’s Much More).  Also, the article highlights General Motor’s experience.  It’s a good read, I’d recommend it.  Interesting though, the article says GM launched their SOA in 2000, and back then there was far less definition around framework, in fact the term SOA didn’t even exist, (we launched our SOA effort in 2002, and it didn’t exist then either, we merely began with decomposing apps into loosely-coupled common services, reuse, collaboration and a governance process… all of which became molded into the SOA buzz).  The article’s main point (which I also fully agree with) has to do with achieving agility.  Quoting Mr. Zhang again regarding the goal of an SOA is “to establish a flexible information systems and services environment that can quickly realign” as business needs change.  Absolutely correct.

Posted in Software, Trends | No Comments »

Financial Services SOA Adoption Challenges

Wednesday, May 2nd, 2007

This week in the April 30 InformationWeek publication there was short couple of paragraphs under the heading “SOA: A Warning Shot”.  The short article reports that financial services firms that have implemented SOA’s are “… finding that they can be more expensive, less reliable, and harder to maintain than standalone applications” (quoting Sajay Sethunath, chief architect for BearingPoint’s financial services consulting business.  From the article:

“His conclusions should be a warning to other industries.  IT departments tend to pick the low-hanging fruit and build services that they know will be reused by several applications, he says.  But too often they haven’t established a metric to show how the effort leads to savings.  What’s worse, Sethunath says, many of the services aren’t even what business users want.”

I work with financial services firms every day, and know many CIO’s and CTO’s in the industry personally.  I can say with confidence, there is truth to Sajay’s comments.  Some are indeed struggling with early implementations of SOA’s. I know of IT organizations in financial services that have made meaningful progress, although many are in early stages without the skills and knowledge to build a complete SOA infrastructure. 

Research done by the Aberdeen Group says that cost-savings remains the biggest lure of SOA.  But regardless of where the IT organization is in the SOA implementation, the big payoff though is a ways out.  The analyst at the Aberdeen Group gathered data from over a thousand companies, and the report basically concluded that if 2005 was the year of SOA romance, the honeymoon was over by the end of 2006, in other words reality is setting in.

SOA’s are valid and worthwhile for any financial services IT organization, but the reality is that they require a systemic change in architecture and process. SOA’s are very complex.  After seeing successes and failures win lots of organizations, many of the key glitches are becoming clear, they are:

  • Don’t underestimate the power and usefulness of the right tools, like a flexible and extensible registry to manage services, policy servers and collaboration wikis.
  • Quality, quality, quality.  Because distributed components loose the benefit of an all-seeing and all-knowing compiler, there isn’t a quick “syntax error” message you’ll get when a disparate service is consumed for the first time in a unique composite application.  The registration process of any service needs to include comprehensive testing and certification.
  • Follow popular standards and create your own where they don’t exist.
  • Pick the right people, the right skill sets.  People that can see and understand the end from the beginning, but can also manage daily tactics of what needs to be done to get there, (Steven R. Covey’s famous book “7 Lessons of Highly Successful People” defines who the right people are to build an SOA as far as I’m concerned).
  • Understand and define what business issues exist that can benefit from the SOA.  Keep that definition in mind throughout the process, in particular when things start to get off track.
  • Set realistic expectations.  The big payoff may take a while to realize, so the value needs to be understood in a temporal context.

No pain, no gain.  Nothing worthwhile is every easy, so don’t lose heart.  It’s the right architecture and process that can today’s business challenges.  Think of it as a journey, not a destination.

Posted in Software, Trends | 5 Comments »