All The President's SOA

I don't want to labour this point but it does make a nice introduction for what I want to write about this time out. I saw Paul Coby, CIO of British Airways present at a conference last year and one of his favourite phrases resonated with me, "There are no IT projects. Only business projects". He has a point. If you're doing technology for the sake of technology and not to help your customers or to improve your business then you're not doing it right. Now that's very easy for a high-flying CIO to say, how does he back it up. How, I wondered, does the thorny issue of executive sponsorship work itself out at BA?

Here's another quote for you, "There is nothing more powerful than an idea whose time has come." Victor Hugo this time. And, as I've blogged about before there is a single, simple, brilliant idea at the heart of SOA to prove that SOA's time has come, namely, building something once and re-using it is a good thing to do.

This famous quote of Victor Hugo is paraphrased in the movie 'The Contender'. As President Jackson Evans (Jeff Bridges) campaigns for his Vice Presidential nominee to be approved by the Senate he says "...there is no weapon as powerful as that of an idea whose time has come". As the nominee - Senator Laine Billings Hanson (Joan Allen) - finds out the idea is one thing,  having some executive sponsorship to back it up is another. And lets face it, there is no better executive sponsorship than that of the President of the USA.

You probably won't have that level of sponsorship for your SOA efforts, so you'll have to settle for executive rather than presidential. What do you need from that executive for your SOA to succeed? What areas do they need to think about to help and support SOA in your organisation?

I've identified six areas;

1. Business Strategy and Process: Organisations need IT implementations that support the business and its changing needs. This is all about thinking about the business project, not the IT project. This is about providing an environment that links the management and measurement of IT with the management and measurement of the business strategy. This is where your sponsor is a key sounding board and information resource. What are the KPI's of your organisation and how does your planning in IT help to achieve them?

2. Architecture: Nearly all organisations that I have worked in fund and build IT by projects in lines of business. This leaves enterprise-wide processes and integration to be considered as afterthoughts and creates a barrier to change. The A in SOA helps organisations build an IT environment based on standards, distribution, loose coupling, re-use and business process representation that is designed to respond to change and will operate and integrate at the enterprise level, the executive level.

3. Building Blocks: A lack of consistency and repeatability in IT implementation hinders most organisations in achieving their goals with respect to IT budgets and agility. The building blocks metaphor offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximising the ability to repeat successes by reusing implementations and the core infrastructure.

4. Projects and Applications: As in point 2 above, IT is traditionally developed by projects within lines of business – often creating excessive spending on duplicate functionality and compromising the integrity of enterprise processes. Executive sponsorship here helps you to catalogue, categorise, and modernise functions offered by systems and applications – standardising the manner in which those functions are offered, while reducing redundancy and promoting consistency. Duplication goes down, re-use goes up.

5. Organisation and Governance: The organic growth of our organisations has yielded an IT infrastructure that is difficult to manage and costly to change. Concentrate on creating an organisational structure and mandate - executive sponsorship needed here if you're going to mandate anything by the way - to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimise IT utility.

6. Costs & Benefits:The $64,000 question. What is this going to cost to build? How much is it going to cost to run? More importantly, what are the predicted benefits from using it? And remember, an IT benefit without a Business benefit is not a benefit at all. Key development metrics, productivity measures, reuse measures, general best practices and internal/external benchmarking. And how does all of that link back to the Business Strategy outlined in Point 1?

My Brazilian colleague Marcelo Simoes has also penned a take on this recently with his "Five-Step Action Plan for Executives". He makes several good points in his piece and I particularly like his Fifth step - The victory dance.

More Jeff Bridges to close with. You're probably not going to get The Dude to sponsor your SOA efforts. But get yourself a sponsor. One that can think big, start small and move fast.

Are you doing SOP’s instead of SOA?

Hi and hope you all had a great Christmas and all the best for the upcoming year!

This is the second blog in our SOA Governance series around a report that came out detailing the ten common mistakes in doing SOA that cause it to fail. I am going to address the second reason which is underestimating the impact of organisational change.  I am very much in agreement with this sentiment and we at Oracle, while we sell SOA technology, believe that SOA is really more a state of mind than anything else.  I also do not think this key issue that gets as much airtime as it should. In fact the mis-application of SOA at the isolated project level rather than the enterprise level largely determines whether you are doing what might be called Service Oriented Projects (SOP’s) or whether you are changing the culture and organisational behaviour with a truly transforming Service Oriented Architecture.

Well let’s get started. In any business initiative that involves technology there are three things that need to work together – people, tools and methodology. This is true with SOA but with an extra emphasis on the people component.  Actually organisational change is really at the heart of SOA.  If we go back to the beginning, SOA is all about making the business more adaptable to change. Why is this an issue? Because the processes and systems we have to support us are so rigid, so slow, so difficult to modify that they have become obstacles to future success.  These process and system difficencies have been  caused by many years of “oiling the squeeking wheel”. What I mean by that is mostly no-one has been really willing to tackle the problems at the core of the enterprise – they just focus on their particular project and seek to deliver it cheaply and quickly.  That is not bad in itself its just that each project done this way adds just a little bit more inter-system dependency, a little more tight coupling, a few more duplicated modules… You get the idea I think.

Why do we take this approach? Well its simple – the metrics by which we are measured encourage us to do so. Fast, cheap, self contained projects are viewed as successful. If we get kudos for this we do it again. Its also simpler than trying to fit in with what other parts of the organisation are doing.

SOA is about changing all this isn’t it? We want to streamline the organisation processes. We want a common set of data definitions. We want a re-usable library of services. We want common tools and consistent methodologies.  The problem should be now self evident - we are talking about cultural change as much as Web Services and XML and UDDI. Guess what is easier to do – change the culture or learn the SOA technologies?  

The bottom line is this – if you don’t try and change the culture of the organisation you are not really doing SOA.  How can I say that?  Well if you use SOA technologies and basically build a point-to-point architecture (so you don’t have to worry about any other project in the organisation) then you are not doing SOA you are doing SOP's.  You are just using SOA tools to build the same things you did before.  Is there any real value in doing that? Apart from learning how to build and use Web Services, ESB’s, BPEL etc - not really.

Is this what is happening? Have people invested in SOA tools but not taken a true SOA approach? Have they then expected to see cross organisation value that didn’t appear and then said “SOA doesn’t deliver what the vendor promised me?”

Recently on Kate Carruthers blog she spoke about why reuse fails. Guess what – its because of the psychology – its about the people – its about resistance to change - its about wanting to keep my project isolated and independent of the other.  Reuse is just one aspect of SOA (albeit an often overhyped one). To really make SOA work we need to think in a process oriented way because that’s how our suppliers, customers and partners interact with us. We need to structure our organisation around  these processes and measure the effectiveness of the lines of business in supporting them. If we do this the all IT projects are subordinate to the process and must work to make it efficient, flexible, fast and available.  Then and only then will any technology – including SOA – really deliver measurable business value.