« Web 2.0 is bad for business | Main | SOA and the invisible side-effects of refactoring »

Many large organizations are now proudly rolling out their brand new SOA infrastructures.  Is yours?

Perhaps your company, like many others, is well on the way to transforming its integration backbone from an old-fashioned "point-to-point" scenario (in which each application must each integrate with each other application separately) to a forward-looking SOA approach (in which each application need only integrate with a single service layer).

In one case I came into contact with recently, the organization concerned referred to its service layer as the "Matrix" - a phrase which carries disturbing overtones of technology spinning out of control.  And indeed this, it seems to me, is exactly what is happening.

Let's consider a couple of very simple issues.

Impact analysis

How is your organization coping with change to services?

In fact, it is non-trivial even to define what is meant by "change" to a service.  How many of the following changes would generate an impact analysis in your organization:

• Addition of a parameter?


• A new possible value for a parameter?


• Change in algorithm?


• Switch of underpinning database/application?


• Use of underpinning databases/applications by another application?


• A new security check?


• New logging procedures?

The textbook answer is this:

A proposal for any such change would generate an organization-wide impact analysis, driven by logical analysis of pi-calculus bisimilarity between the old and new scenario.

However, only a very few organizations in the financial services, military and critical systems fields are following this route.  What is your company doing?  Many seem to be trusting to luck that no-one acccidentally breaks anything serious.

Cost-effectiveness

It is a truism that no software is static.  So services require continual attention if they are to stay useful.  And this costs time and money.

So how is your organization assessing:

• The business value-add provided by each service?


• The degree of maintenance effort appropriate for each service?


• Whether or not enhancements are necessary for each service?


• What actions to take when service-level agreements (SLAs) for a service are violated?


• Which IT staff to assign to which services?


• When to dispose of services?


• When to combine existing services, possibly with some loss of functionality?

Here there are not yet even any textbook answers.

TAKE AWAY

It has been generally accepted for some time that investment in IT is not, on its own, going to give your organization any strategic advantage:

In 2003, Chris Verhoef of Vrije University, in his keynote speech at the IEEE International Workshop on Source Code Analysis and Manipulation, claimed that there was little evidence of a positive correlation between IT investment and return on shareholders' investment.  He was drawing on his own studies, plus those by Paul Strassman (the ex-CIO of the US Department of Defense), who claimed that no relationship existed between IT investment and company profitability (P. Strassman and T. Pisello, IT Value Chain Management: Maximizing the ROI from IT Investments, Information Economics Press, 2003).
EQUITY and the Problem of Return on IT Investment

Strassman showed that you have to box clever if you want to get anything at all out of IT.  I don't see organizations boxing very clever with regard to SOA.

In the next postings to this blog, I will be considering how to use SOA to advantage - in particular, I will deal with the problems described above as well as others.

And I will suggest ways to deal with such issues without spending a fortune on yet more technology!  Rather, the answers, as so often, are right under our noses.

Posted by keithhb in Management • Service-Orientated Architecture |Digg This|Add to del.icio.us