I've already bought your book, now I know why :-) Thank you. - Michael
________________________________ From: Steve Jones <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, October 30, 2008 9:16:26 AM Subject: Re: [service-orientated-architecture] Re: Rhody tells you how to sell SOA There is a bit in the book (hey its Christmas, buy a copy for your relatives ;) ) on "heatmapping" the services to do this and a bit around doing KPI mapping. The reason why I don't do ROI cases where its cost reduction is that the return is a "gap" i.e. if we do this then you will spend LESS so the return is a bottom line element. You can spin it into a margin improvement thing in an ROI case but I've just tended to find that being clear on cost reduction v ROI (top line) has helped. The purpose of heat-mapping is to make it clear the different forms of measures (and contracts if outsourcing) that are appropriate and to highlight the truly differentiating (invest here for big returns) from the utility (damn our back-office IT is expensive for no apparent reason) this helps you focus investment onto the areas where it will have most impact and to convince the business on the justifications for IT decisions (e.g. vanilla package in the back-office because its a utility). Effectively this is about managing your IT portfolio from a Business Service perspective. Its "big" SOA in its scale and scope but its cheap to do. Steve 2008/10/29 Michael Poulin <[EMAIL PROTECTED] com>: > Sure, one model may not necessary work in all cases. > > We were talking about monetary metrics for SOA services. So, for the first > step, we have to find how services 'play' in your four business cases, in > particular, > 1) share price or another kind of massive market impact (hard to see the > 'play' > 2) ROI - TVO (I can identify 4-5 'play' scenarios) > 3) Cost - TCO (is this about just cost reduction? what else may be in there > and not in ROI? One-two of my ROI scenarios is about cost reduction... ) > 4) Utility - Cost against business metric (unclear if this is just a part of > ROI cases, e.g. development/ maintenance investment and disassembling > cost...) > > Can you elaborate a bit more on this? > > - Michael > > ____________ _________ _________ __ > From: Steve Jones <jones.steveg@ gmail.com> > To: service-orientated- architecture@ yahoogroups. com > Sent: Wednesday, October 29, 2008 6:17:28 PM > Subject: Re: [service-orientated -architecture] Re: Rhody tells you how to > sell SOA > > ROI works where you are talking about ROI, i.e. top line increase. If > the focus is cost reduction then a cost reduction calculation works > better. > > I've done quite a bit around doing TCO modelling (or even TVO - Total > Value of Operation) and monitoring and its hard because most of the > time companies don't have the clarity. The key is that one model > doesn't work for IT you need (IME) at least four basic ones > > Differentiation - MASSIVE market impact. Measure it based on the > share price or other pieces > ROI - Topline impact (TVO) > Cost - TCO > Utility - Cost against business metric > > Steve > > 2008/10/28 Michael Poulin <[EMAIL PROTECTED] com>: >> I prefer to calculate ROI instead of cost, and two values - short-term and >> long-term ROI. A lot of current problems in the companies is in that they >> calculated just the cost of implementation. .. Do you know how to >> calculate >> potential benefits in monetary metrics? >> >> - Michael >> >> ____________ _________ _________ __ >> From: htshozawa <[EMAIL PROTECTED] com> >> To: service-orientated- architecture@ yahoogroups. com >> Sent: Monday, October 27, 2008 9:59:17 PM >> Subject: [service-orientated -architecture] Re: Rhody tells you how to >> sell >> SOA >> >> Understood. The definition of flexibility isn't ambigous. >> >> Also want to point out the there is a cost associated with obtaining >> flexibility. I think it's better to calculate the benefit that may be >> obtained from flexibility to see if it is more than the cost >> associated with it. >> >> H.Ozawa >> >> --- In service-orientated- architecture@ yahoogroups. com, Michael >> Poulin <[EMAIL PROTECTED] .> wrote: >>> >>> Exactly, it "does not equal profit", and may be not good for every >> process. If I look at the Business with Service Eye (where process is >> just an implementation) , flexibility is what is needed in frequently >> changing external environment. If the latter does not change or >> changes slowly, flexibility is not that crucial. >>> >>> So, the first is a requirement for flexibility that comes from the >> business needs/market/ external environment; which business >> service/process has to be made flexible is the second. >>> >>> I tried to point that flexibility is not that ambiguous. >>> >>> - Michael >>> >> >> >> > >
