Return on investment in systems

This is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.

Note “systems” rather than “technologies”, but most systems depend on some technologies.

Q: Can we ignore technologies?

No. A business depends on, and has to manage, the technologies that enable and constrain what it does.

A logistics company depends on the depots and vehicles it owns or hires.

Human activities (package sorting, vehicle loading, routing and driving) are supported, enabled or replaced by technologies.

Enterprise and solution architects work to enable, support and improve core business processes that provide services to employees and customers.

They focus on “digitisable” (Ref. 4) or “information-intensive” (Ref. 5) processes that create and use business data.

The business processes depend on business information systems.

The business information systems depend on technologies.

Not so long ago, they depended on pen, paper, card indexes and typewriters.

And since the “information age” started in the 1970s, information systems have depended on an IT platform.

So, many business system costs now appear under the heading of IT costs.

Q) Are IT costs high?

Note first that EA (being out of business system planning) is more about IS than IT.

And IS and IT are separate divisions or practices in many organisations.

I gather IT costs as a percentage of revenue for FTSE 500 companies are typically around:

• 1.5% of turnover for generic IT services: "keeping the lights on" , basic infrastructure, email, desktop support and provisioning,
• 2% on top of that for key IS projects, ERP, CRM, whatever.

If you count IT costs as overheads, then 3.5% of turnover looks high (and the figure in banks is double that).

But where systems perform operational processes (as in banking) surely they ought to be counted as operational costs, among which they may look remarkably small.

Read On IT cost cutting.

Q: Is the value of an EA team to maximise the Return on Investment (RoI) in IT?

Enterprise and solution architects work to enable, support and improve core business processes that provide services to employees and customers.

They focus on “digitisable” (Ref. 4) or “information-intensive” (Ref. 5) processes that create and use business data.

They look to optimise the investment in business information systems, focusing on benefits as well as costs.

However, maximising the RoI in IT systems is more a slogan than a measurable goal.

Q: So how do we measure the RoI of EA?

Avancier Methods include a slide show on EA funding and ROI metrics.

All possible measures are questionable if not downright disputable, bearing in mind that the PMO, ITSM, HR and other functions make their own contributions.

· Fewer systems? Could be a bad thing if the fewer systems are each larger and more complex and/or provide less satisfactory services.

· Higher systems integration? This increases the complexity of inter-system dependencies.

· Faster creation of new products? Product proliferation is part of the complexity problem.

· Higher employee productivity? How to measure it, and the contribution of EA to it?

· Sum of all the RoI achieved on all system change projects? Ditto.

· Lower system change project failure rate? Ditto.

· Lower IT costs? Ditto.

· This is a naïve target, not necessarily a good thing.

Q: How does EA measure and monitor the value of system or system change?

Enterprise architects do strive to start and finish by addressing business value.

They start from goals and objectives to be achieved by business processes, or changes to them.

They look to define the value of systems to support those processes, and to document discrete “value propositions”.

TOGAF includes three vehicles for documenting values of different kinds to different stakeholders.

	Costed in	Has a value to	TOGAF documents in
System operation	OpEx	Service consumers	Service contracts
		Other stakeholders	Value propositions (for ops)
System change	CapEx	System sponsors	Business case or ROI
		Other stakeholders	Value propositions (for change)

The concept of “value” sounds simple, but is difficult to measure objectively.

Some systems clearly have the value of making/saving money or meeting a legislative imperative; but many don’t.

Q) Who values system operations?

Surely, systems user or customers.

Systems ought to be judged on the quality of the services they offer to users, but these qualities are hard to quantity.

If we can measure target product or services qualities, then we can measure actual service delivery against that standard.

But who knows how much faster, simpler or better the services could be?

And shouldn’t we rather be measuring the desired effects of those services in the wider environment?

And what does the system sponsor get out of a system’s operation? Minimisation of operating costs or risks may loom large.

Comparing systems that offer apparently similar services to their users is difficult without intensive hands-on experience.

But without reports of comparisons in realistic business scenarios, the sponsor may know no better than to choose the cheaper system.

Q) Who values system changes?

Surely, change requesters.

Many parties (system sponsors, service requesters, consumers, and providers, and other stakeholders) may get something different from a system change.

Each may have their own value proposition.

For some stakeholders, the value of a new system is found in a fat redundancy payment.

And what does the system sponsor get out of a system change? Again, reduction of operating costs or risks may loom large.

Q) Who knows when sufficient value is being obtained from a system?

First thought, when benefit > cost.

For this calculation, both must be expressed as a monetary amount.

In practice, system sponsors have difficulty measuring benefits or values.

(See related Avancier papers under references.) E.g.

what is the quantified value of your email system to your business?

Q) Given a value measurement, what does a manager do with it?

Suppose measurement shows system value < system cost.

What to do with that information?

Discard the system? Change to a new system or service provider? How to know that will be better?

The manager could ask the EA team to investigate how the system could be made better, cheaper, or replaced.

Or perhaps easier, change the way value and cost are measured?

Q: What is the best value system, as a solution to a business problem or requirement?

There is rarely a right answer; there are trade-offs between different solutions; some meet some goals better than others.

The solution options, features and weightings in your “Pugh matrix” are crude measures, and easily manipulated.

The best solution today depends on which goals and stakeholders are weighed as most important today.

The best solution tomorrow may be different.

Q: So what are you saying?

Politics matter: EA-level decisions are steered by power and politics.

Architects see trade-offs between multiple options.

Senior managers are politicians who prefer binary decisions: do it or don’t do it.

The bigger the purchasing decision, the more senior managers assume responsibility for it.

Consider a proposal for a high-speed railway line.

A decision to proceed will primarily be a political one.

Decision makers will ask for numbers to back it up.

The cost numbers they are given will be approximate and the benefit numbers will be dreamed up.

The proposal for new or changed business systems may come with equally questionable cost and benefit numbers.

The political value of change – addressing pains, threats and opportunities felt by sponsor-level decision makers – can prove more important.

EA needs senior executives to personally value the contributions of the EA team.

Architects have to be political animals.

References

Ref. 1: TOGAF 9.1, The Open Group.

Ref. 2: Oxford Dictionary of Proverbs. Cf. 1942 G. Ciano Diary 9 Sept. (1946) II.

Ref. 3: Heylighen F. (1992): "Evolution, Selfishness and Cooperation", Journal of Ideas, Vol 2, # 4, pp 70-76.

Ref. 4: “EA as Strategy” Ross, Weill and Robertson.

Ref. 5: ArchiMate v2 standard, The Open Group.

The papers on the “Enterprise Architecture” page at http://avancier.website contain much advice relating to EA.

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0 25/08/2016 14:18

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.website” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this work, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org