Peace in our time: surviving the war between IT and the Business: Chris Koch
This session was cancelled, however, I reviewed the presentation material and have summarized the key points. Chris defines the front of this war as misunderstanding, which comes as a result of four things: it’s about me, unwritten strategies, technology perfection, smart people vs smart people.
Chris suggests that overcoming such misunderstandings can be done by structuring the relationship between IT and business. Some mechanisms include: service level agreements; and at an individual level.
In the experience of the presenter, things that have not worked are: the “uber-architect”; a confederated structure; bad IT governance with an Enterprise Architecture add-on.
On the contrary, what has worked is: a federal structure; carrot (budget control); stick (project review/prioritization); influence over authority.
Chris has observed four phases of maturity: silos; standardized IT; standardized business processes; business modularity.
In the end, the issue is about change and managing that change. For this the presenter offers ten rules:
- stay on message;
- keep it simple;
- expect fear;
- let them own the change;
- lead by not leading;
- show, don’t tell;
- provide experience;
- focus on the big picture;
- seek compliance before commitment;
- make it a personally relevant story
EA Program maturity: A Key to Delivering Business Value: Phil Allega
The basic message here is that a maturity program helps one benchmark themselves against best practices and then allows one to determine their next steps in maturing the Enterprise Architecture Program. There are several different maturity measurement schemes — Gartner has one — the objective is not necessarily to be fully mature across each dimension as to achieve an endpoint comes with a cost. One must determine what is appropriate for the environment.
Phil suggested an annual reassessment.
To emphasize the importance of developing a maturity model, Gartner provided the observation that they have no examples of EA Program failure due to getting the technology wrong. The issue is lack of maturity.
Strategic impact: the EA Measurement Program: Bruce Robertson
Deploying a full and complete measurement program in one step is likely not feasible. Bruce suggested a deployment sequence of measurement: IT investment (email, crm…); business goal (reduce cost, increase revenue, enhance quality, managing knowledge, gaining agility); value management (reputation, return on capital invested, bottom-line profit, top-line revenue). All this leading to a point where impact on business value could be seen and measured.
As well as suggesting a sequence of scope, he suggested that it is best to gradually add depth to the measures.
Bruce talked about relating EA Deliverables to value. First, generally EA has two key deliverables: a description of current state/future systems; second, the rules, guidelines to get to future state. The issue then is to relate these to the concerns of the stakeholders, and for that you need to understand what their concerns and issue are and how/whether the EA deliverables support them.
From a measurement perspective, this translates into measure the things people are complaining about.
In a question on how one should balance Enterprise vs. LOB trade-offs, Bruce suggested that the issue is often related to the sense of loss of control and if that is the case then that is the issue that should be addressed.
In another questioning whether it is possible to valuate Enterprise Architecture on its own, Bruce agreed it was difficult. It is easier to measure in the context of business strategy, asset management and projects.
Sales 101: Selling the Value of Enterprise Architecture: Richard Buchanan
Richard started the discussion by saying selling value requires knowing what it is you are selling. That is you need a definition of the EA program.
To convey the value of the program the problem to be solved has to be understood; the concerns others have that you think you can help solve; all these have to be linked to what the EA program provides. It is difficult to sell value if there is no agreement on what EA is and is to do.
Richard suggested as Enterprise Architecture is a process EA should be thought of as a verb: to EA. Not a noun: an EA.
On the question of cost, Richard stated the point of view that the cost of EA should be calculated based on the number of people doing the work, not the cost of the systems that will eventually be implemented. Therefore, in most cases, the cost of EA is small compared to the total IT budget. The point is that systems will be deployed and thus the cost will be incurred. The argument for EA is that deployment can (1) be done more efficiently (2) be more effective in supporting business strategy.
Leave a Reply