We need to think about service orientation, go stealth. But what about gaining trust again? Would you accept some sort of service delivery if there are no guarantees on getting your investments back?
So, what would you suggest we should do? How do we focus on empowerment again? How do we keep service initiatives small? But last and certainly not least, how do we secure the investments made into service orientation?
Giovanni Scheepers
Hi Giovanni
ReplyDeleteWas good meeting you in Berlin - Am looking forward to a good discussion and espeically looking at your idea of asset liability management in the context of SOA. Am very excited!
Have a good weekend, Thomas.
Hi Thomas, likewise! Let's have a discussion.
ReplyDeleteSuppose you want to close a loan with your bank; then you know that:
1. you don't have to shout 'show me the money';
2. you do not have implicit dependencies with other parties;
3. the contract is established in advance;
4. clear executable general terms;
5. you will not be bothered by any internal / organisational problem at the bank.
You will have and will keep having confidence in the service delivery because it is based on a set of legitimate principles (like our service orientation patterns for delivering SOA).
Unfortunately our clients no longer have faith in SOA. IT-projects based on SOA have produced disappointing output over and over again. We arrived at a point that it's better not to mention the acronym SOA again.
So how do we regain and keep confidence? Simple, make the QoS explicit in money. Make sure that a service contract can only be established when:
1. the liabilities which flow from the service are made explicit with a cash flow projection using deterministic cash flow models;
2. the constituent defines its expectation regarding the amount of cash flow projection upfront;
3. an independent party validates the cash flow projection model of the service provider;
4.an independent party checks if there are sufficient assets available to provide a financial guarantee in case the cash flow bursts out lower than expected; if not, it matches assets for the duration of the expected cash flow; the same as by applying Asset Liability Management;
5. an independent party checks if the service provider has sufficient capital available to mitigate any unforeseen risk;
6. an independent party monitors, measures and reports the executed quality of service during use, based on metrics set up upfront;
7. the independent party is under strict governance.
Difficult? Absolutely not. As it happens, we do this and take this for granted in the real (financial) service delivery world. What are the challenges then:
1. SOA-patterns must be understood and carried out completely and vigorously;
2. costs will have to be made explicit in advance based upon transparent assumptions; think about maintenance costs in particular and costs which originate from the lack of empowerment within our IT-projects;
3. if the lack of empowerment is persistent and the chance of success is low, then (CIO) leadership will have to be made even greater;
4. yields have to be made explicit in advance; think about the amount of expected business value and yields by the expected amount of reuse and complexity reduction;
5. requirements will have to be made free of any ambiguity and will have to be strictly formal (presumably as a result of SAVARA).
So who will be an independent party? Large companies will organise this internally. Small companies will probably need a new service in the market place: service insurance.
Let's show them the money.
I'm not an economist and therefore I had to read up on asset liability management first to understand its concepts. Wiki was quite good in this respect http://en.m.wikipedia.org/wiki/Asset_liability_management. My understanding is that ALM is a methodology that banks and insurance companies (ASR is one, right) use to ensure a positive cashflow and offset all operational and other risks by backing them up with equally heavy assets. In the article there's a reference to Basel II -- so I assume that Basel II defines regulatory guidelines in this area.
ReplyDeleteWhat I'm still not sure is how this relates to SOA. My understanding here is that you'd offset the operational risk (opportunity costs, faiulures, etc.) with assets (that presumably the service provider holds back). An independent party arbitrates when SLA and other expectations towards the service are not fulfilled. The service implementer as a liable party must then stamp up money to compensate for the loss that the service provder has encountered (and for which the service consumers may claim compensation).
When we talked at the SOA Symposium I understood that there might also be another party that insures this risk for the service implementer. There'd be four parties/roles involved in such a setup: 1) service implementer, 2) service provider, 3) neutral arbiter, 4) liability insurer. the insurer could collect statistical data for the service implementers and therefore adjust risk factors. There might even be some kind of an implementer rating ("AAa", etc... similar to what exists for financial instruments).
You wrote, how does this relate to SOA? Well, without a sound architecture and without service orientation, there is no way you could mitigate the direct financial risks of the investment.
ReplyDeleteSo what sequential steps need to take place?
1 The Service Provider (SP) asks an Neutral Arbiter (NA) to validate his Service Contract.
2 The NA will be trusted and motivated to do so.
3 The NA inspects the architecture and the way this service will be developed, implemented and deployed. In case the result of the inspection will cause tears and depressing moods, the NA gives advice how (if possible) to pimp things up.
4 The Service Consumer (SC) states his expected cash flow. By doing so, the SC puts his trust also in the NA.
5 The NA checks if the expectations of the SC are tangible.
6 If tangible, the NA claims governance and will be committed. In addition the NA will make financial reservations.
7 The NA directs a formal way of requirement management (SAVARA).
8 The NA monitors the service implementation and deployment. The NA also monitors the QoS of the service during run-time.
9 The SC delivers a projection model - together with the operational assumption.
10 The NA validates the projection model and the related assumptions.
11 The NA sticks a certificate on the service-contract and by doing so has mitigated the direct financial risks of the SC.
12 The NA governs the design, implementation and deployment of the service.
13 The NA governs the QoS of the service during run-time (as long as agreed on up front) and periodically reports any discrepancies towards the projection.
And there you go, a happy d(m)eal without surprises.