<<Is your SOAP turning to SOUP?
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.>>
You can read this blog at:
http://www.ebizq.net/blogs/it_directions/archives/2006/12/is_your_soap_tu.php
Gervas
