The Oracle Australia and New Zealand Middleware and Technology Blog.

Wednesday, February 18, 2009

SOA – Pay Now or Pay Dearly

Hi, and welcome to our fourth topic on the 10-part SOA series. My section focuses on how a lack of investment in certain areas, can hamper and potentially derail business transformation strategies that are relying on a SOA approach.

When I hear the phrase “doing SOA on the cheap” it means one thing to me, viz the fundamental building blocks to facilitate SOA transformation have not been followed or understood. There are though a number of investment-poor symptoms that I think could warn you of impending SOA troubles. I would break them into people, processes and technology.

If you look at the people issue, I think the most important aspect here is investing in time. As time costs money I often see SOA relegated to the corridors of the IT department because it is then easier to control. I believe that as a SOA approach should underpin business transformation, sufficient time has to be spent with business to understand the overall strategy, to gain alignment, to facilitate role transformation, determine project priorities and decide upon a funding strategy. In terms of funding, I have heard that the “spare bodies” in the IT department get thrown at a SOA initiative because it is “high risk”; no-one understands the concept and no-one would fund it, so SOA will start off small with a couple of trained developers or DBAs and never grow beyond an experiment. SOA needs the most highly skilled technical and business resources, including key external consultants, that money can buy. You get what you pay for in this game, and what you don’t want are unskilled consultants and staff putting your business under unnecessary risk.

If you look at process, I would put governance into this category. I hear that governance can come later in SOA maturity because it is an expensive overhead. On the flip side I have seen SOA projects grow from a concept to production extremely quickly, and without the right policies and procedures in place potentially bad development practices could quickly become the norm, and the execution of services at runtime could be unmanaged. I believe in putting down rules quickly in a process to prevent costly rework later. Debates continue at what point governance should begin to develop. I would say you should think about governance before you build your first service.

The last category that you need to look at is technology, which would include development and the SOA enabling technologies. If you look at development, developing a bunch of services is pretty easy. The more difficult thing to do is develop services for reusability. It is estimated that creating a reusable service to a base service is anywhere between 30 and 200% more expensive. The flipside is that using a reusable service in further projects reduces development cost between 20 and 80% of the cost of developing a base service. While this makes logical sense, no IT project manager will factor in increased development costs to incorporate the notion of reusability, when it might not bring them benefit to their immediate project. I think another way of tackling this issue would be to apply governance that would ensure that services are built for reusability and services form part of a managed service lifecycle and development culture.

Choosing middleware technology can be tricky. When funding is lacking, often skunk works projects are built with anything that is freely available, with little or no consideration to the suitability of the technology to the business and no understanding of the manageability of the final architecture when the middleware infrastructure begins to mature across an enterprise. Ripping middleware out of architectures is a difficult process and making a hasty middleware decision early on in SOA adoption can prove costly in the long term.

So maybe a parting thought is if applying a SOA approach on a shoestring is not a wise decision, how can you get the funding to make it happen? For any transformation initiative, business executives need to understand what is required for them to achieve their business strategy. If SOA is the right approach and will deliver the required business value to help them achieve their business strategies, and they agree to the principles, then you will have the business case and the mandate to begin to invest properly in time, process and technology.

No comments: