The usefulness of having an IT Architecture (I rather prefer value instead of usefulness) for an organization is often subject to debate. To end the debate, it usually helps if the board (or executive team) fully supports the IT architecture, not only the existence of IT architect(s) in the organization.
Some people claim that a typical board can't understand the IT architecture by itself (who can?) and therefor is not likely to support or enforce an IT Architecture. In this case it is very likely that the organization's IT architects are at the top of their own Babylon Tower. Not necessarily a smart thing to do, as it will not lead to a wide acceptance of IT Architecture, certainly not with business executives.
Some of you had the privilege to meet with board members in order to present a proposition on which they should or could take a decision. For those who have not: the following questions are in the head of the board members:
- What is in it for me?
- Why should we (read our organization) do this?
- How much will this contribute to the bottom line this year and the next years?
Yes, it is that simple. They are held accountable and need to clarify their decisions to the shareholders. Even if the board is one person and the only shareholder!
No, "Partnering within our ecosystem will greatly benefit the IT mission to simplify the use of the Enterprise Messaging Bus using broadcast protocols on the secured transparent network" or similar wording will not make their day.
In quite a few organizations the responsability on IT matters within the board is taken by the CFO. Unfortunately many CIO's - despite their title - are not members of the executive team and do report to the CFO. If your CFO is the person to give the final nod, make sure that (s)he get the view on IT architecture in a language (or numbers to be specific) that is clearly understood.
Financial people love ROI: Return On Investment. With the formula for Arithmetic ROI it is simple to see if the investment is profitable or not. But calculating the investment values of a complex IT infrastructure or an elaborate software platform is not everybody's piece of cake. So IT has to satisfy the board with something else.
We are talking about the cost necessary to implement the change towards the IT solutions according to the IT architecture, the current cost of the IT landscape (usually already known) and the anticipated cost of the future IT landscape. And let's not forget the cost of creating the IT architecture and to maintain it. Good Architects have a fee, not an hourly rate.
Keeping in mind that I am talking about all costs*: both capital and operational expenditures (CAPEX and OPEX). I always suggest to use only the hard facts: the future combined CAPEX and OPEX should be lower then the current one. Divide the cost of change by the savings achieved and you will have the duration it takes before the savings are effective. If this period is longer then the life span of the solutions then you should think twice before going ahead. It certainly will not impress the CFO. Tip if your initial numbers don't look good enough: check if you included the cost of all relevant IT staff.
So how much detail should the IT architect bring to the picture? Not too much, because it will sidetrack the audience and you will get IT into slippery territory. If the IT architect is trusted using credible sources, the consolidated numbers should give enough insight to the board. And as for the cost for change: be bold when quoting numbers. Rather too much instead of having to say "oops" at a later stage.
As you can see, IT Architecture for Board Members is all about a financial view on the IT landscape. IT architects should demonstrate the financial viability creating, implementing and maintaining an IT Architecture.
*) Doing a TCO analysis - Total Cost of Ownership - is worth the effort if IT also would like to get a good financial understanding of the stuff they implement and maintain.
© Peter Bodifée 2008. All rights reserved
No comments:
Post a Comment