Most discussions on Cloud Computing I’ve been reading are focused on the infrastructure and technology part. It offers easy to deploy infrastructures or even applications in a very scalable way. All this in a pay-per-* way. And here is where a CFO should get interested. Moving to a Cloud implies moving from CAPEX to OPEX. Usually a CFO has an idea on how to keep these balanced. The Enterprise Architecture of some organizations even have very strict guidelines on whether certain expenses should the one or the other. So that’s the first one to thing about…
As was stated in a previous blogpost on measuring the business value of SOA, project metrics for business value created by SOA projects, IT projects, or even projects in general are rare. If I were a CFO this would worry me.
Besides that SOA efforts in a way also demand a different way of cost accounting than the traditional silo based. If my organizational unit owned (and had to account for the costs) of a rather popular often reused service, I would like to charge them. Say for example in a pay-per-service-call way. How do the financial systems under the responsibility of the CFO facilitate this?
Of course there will be lots of other stuff on your agenda if you are the CFO. But hey due to the crisis interest rates are low, labor is cheap, as are materials, so why not invest now in the foundation/infrastructure for the future 😉
If you’re a CFO and – by incident – are reading this blogpost please let me know what you think, and add a comment…
As Anne Thomas Manes stated in her presentation on Measuring the Business Value of SOA a 2009 Gartner study showed that
- 36% of SOA projects lack a business justification
- 1% of all SOA efforts actually measured benefits
From these statistics it doesn’t seem to be a natural thing to do, measuring the business value of SOA. By measuring the business values we mean value in monetary terms – “hard cash”. Think in terms like:
- Increased revenue
- Lower costs
- Better use of assets
- Solve customer business needs
In order to have a good assessment of these we need a solid baseline measurement. This is where it gets hard. How many organizations actually have baselines like these. So the intricacies of measuring the business value of SOA aren’t necessarily related to SOA! It might very well be an issue for IT or even businesses in general.
What is specific for SOA or any other architecture or maybe project management approach, is to single out SOA as the direct responsible mechanism for the business value created (causality). In other words what part is SOA specific and what is “just” the availability of a new application? SOA has an indirect impact on business outcomes.
As an example of the previous point: In one of the SOA efforts that I have been involved in – that was at least in my opinion successful – the realization of the business case was very clear: 5 to 10 employees of a department had no longer work to do after 11.00 am. However because we automated a process that wasn’t automated before, it would be very hard for me to point out what part of the savings was actually directly caused by implementing in an SOA context.
This is one of the reasons why I’ve been advising organizations to implement SOA as part of their “normal” projects, or at least projects with a valid business case. Dealing with your project in a SOA way will not only deliver the monetary outcome described in the business case. Applying SOA principles like “Separation of concerns” and “Loose Coupling” will yield in solutions that are modular, interoperable, and shareable.