In my last post (What’s the gap?) I observed that, for the most part, there is fairly good alignment between Business and IT. This is supported by research by McKinsey & Co showing that collaboration and business strategy alignment features strongly in the development of IT strategy for a large proportion of companies surveyed.

Also, the strategic importance of IT for Business is recognised by the high level of representation at the Board (44% of CIOs consulted by McKinsey in 2007 reported directly to the CEO).

The same report also highlighted that IT was heavily focused on managing and operating as a business service and this probably seems a natural role for IT.

Although there’s no doubt operating for service excellence is a key responsibility, sticking to this status quo contradicts a key factor of IT’s meteoric success over the last forty years. Had not the pioneers of modern IT innovated solutions to improve the accurate and reproducible management of information, businesses would now require impossible levels of resources to support their daily operations (imagine the number of filing clerks needed to man the vaults of index cards and paperwork to support today’s large insurance broker). In fact, without the Information Age modern businesses would not be able to support their modern day scale.

But innovation remains a neglected duty, with the majority of IT assessing themselves as not excelling. Of those interviewed by McKinsey, 57% indicated that they were either moderately or not at all effective at finding ways for IT to add value to their businesses (in other words, a failure to innovate based on internal needs). The picture was worse for innovation to improve competitiveness, where 67% of respondents were either moderately or not at all effective at introducing technology better than their business’ competition.

By settling into a routine of design, build and operate, IT is often failing to proactively point the direction to opportunity for Business to exploit … opportunities that business people have no way of understanding or detecting on their own.

IT leadership must grow to the next level of maturity, adding innovation as a core process to their lifecycle management, becoming as routine as specifying, building and operating a new server rack. This can be achieved by adopting key steps as part of the CIO role.

1. Establish your Enterprise Architecture (not new … but, really, have you defined your enterprise architecture current and target states? do you have a roadmap agreed by all stakeholders?)
2. Investigate your environment to improve competitiveness (do you research, subscribe to credible news feeds, have someone appointed to monitor key technologies and trends, have even a sketchy map of your technology landscape, regularly monitor the technology of your business’ competitors, and regularly evaluate the landscape against your business strategy to identify new opportunities?)
3. Liaise with your business’ IT users to spot opportunities for effectiveness and efficiency (pretty self-explanatory … but it is time-consuming … maybe innovate a way to make it easier to get feedback? what’s your immediate reaction when you do get feedback? … if it’s more "they just doesn’t understand IT", maybe you need to adjust your attitude, rather than the audience, to avoid missing opportunities)
4. Continually refresh the IT strategy and target EA (are you working with the business to ensure linkage of IT and business strategy change? does your EA reflect your IT strategy and vice versa? does your ‘current state’ EA truly reflect the current state and do you have a process for updating it with routine changes? is there a process for influencing business strategy based on the findings from environment and internal needs analysis?)

Adding these steps to your CIO office / IT department’s routine procedures in a way that naturally integrates with the rest of the way things are done (design, build, operate) will add innovation as an integral part of daily life. As this begins to produce real business benefits, the ordinary will become extraordinary.

I suggest that whatever gap there has been is pretty much on par with any other business discipline and the rest of the ‘Business’. How often have you heard line managers sighing "human resources" when they have been requested to tighten up performance review processes, or there has been disparaging comments about "bean counters" when finance has introduced a new set of controls.

I believe the Business / IT gap is actually a group-thinking contrivance nurtured within the IT fraternity and happily capitalised on by industry suppliers to develop cross-industry camaraderie and a sense of "we understand your pai". It’s a familiar topic that we can all nod together with some common understanding and feel bonded on a mission to change the world.

Yes, there was a gap when IT was a purely technical discipline before the evolution over the last 30 years towards an integrated business service. But that gap is now much smaller than it was in the 80’s thanks to a conscientious effort of our cross-industry discipline to deliver value to our businesses. The frustration we in IT feel from other areas of the Business isn’t a symptom of a growing gap, it’s a consequence of the increased importance of IT to the Business as a whole.

It’s now time for IT to cease its apologetics and get on with the business of being part of the Business.

What do you think? Are we ready to be part of the Business or have we got some more growing up to do?

But initiating an expansive governance programme with complex processes, detailed templates and a new organisation also can be counter-productive. The negative consequences could include lengthy delivery of the desired results, box-ticking for technical compliance but not producing what the business needs, and the development of antagonism between the governors and the governed.

This approach seems rather heavy-handed where, for the most part, non-compliance is the result of either doing the easiest thing at the time or a lack of awareness that the decisions being made contradict an established standard or policy.

Rather, any organisation with an enterprise architecture must develop a culture of consistent compliance through increased awareness and convenience of exercise.

Most compliant behaviour results from convenience and awareness, but focus on convenience

Discounting deliberate non-compliance as a contributor, there are two primary dimensions that drive compliant behaviour:

• Convenience of doing the right thing; if it’s easy to do, then your constituents are more likely to comply with the rules
• Awareness of what the right thing is; if you don’t know the rules, then only common sense prevails and technical decision-making isn’t always (rarely?) common sense.

The diagram illustrates the combination of these two dimensions to produce four general scenarios.

Chaos results from high barriers to compliance and low levels of awareness of rules & standards, as ignorant decision-makers choose the path of least resistance to achieve tactical outcomes.

Frustrated Disorder results when decision-makers are aware of the right way of doing things, but are faced with high barriers to achieving compliance; people are forced to knowingly do the wrong things as their decision making is channelled away from compliance.

Accidental Compliance is a state resulting from the condition where the barriers to compliance are low, making it easier to naturally do the right thing, but there is general ignorance of the rules; here, the right thing is done by default but, typically, inconsistently.

Deliberate Order is the Nirvana state, where compliance is as convenient, if not more, than doing the wrong thing and awareness of the rules is high; the right decisions are facilitated by reinforcing environmental conditions and an informed constituent acts as agents for compliance, with consistent and repeatable results.

Note that this model suggests that making people aware of the rules and guidelines without providing the facility to comply with relative ease will only result in a frustrated and disillusioned constituency. Surprisingly, many governance implementations feature a detailed communication of the rules and new processes that often disregard the current way of doing things. Perhaps this explains the poor reputation that architecture governance has earned – all it takes is one poor experience for a frustrated architect to tell his / her colleagues, fellow professionals and future employers, emulating the reputation network effect for marketing – it’s harder to go from good to great than to tumble down the league.

Haste and forced urgency results in inconsistency and tends compliance outcome toward chaos

We know the scenario all too well. A dictum from above increases the urgency for a project and applying normal procedures to ensure the outcome is compliant are now viewed as an impedement to the business. "Treat this one as an exception …" is the direction and the governance processes are circumvented. This signals a convenient alternative to other project managers who are always pressed to find faster ways of delivering. Before you know it, this ‘exception’ is being accepted as a norm, devaluing the enterprise architecture and, by ironic extension, resulting in a general failure to enable the business strategy.

Therefore, it is essential that any governance solution includes a defined ‘exception’ process that provides a convenient but procedural means of ensuring the same compliant outcome as for any other project. This would be achieved with an effective prioritisation framework that may accelerated the pace of decision-making for urgent projects, but in relation to the other priorities for the enterprise.

Develop a culture of acceptable behaviour to strengthen compliance

Communicate your enterprise architecture vision to every constituent group, ensuring that the message and benefits are relevant to each audience. Without a common vision that corresponds to the role of each member, the message will be lost and individuals will work towards their own interests and not that of the common good.

Once the common vision (and common good) has been articulated and accepted, then it will be easier to allow the natural social pressures of acceptable behaviour to help add weight to compliant behaviour. For example, specifying a new COTS solution application that has not been included on the EA roadmap for a project solution would result in a loss of reputation for the solution architect at the next architecture review board – not a good look. This pressure will also encourage architects to ask questions from domain engineers to ensure that their designs are compliant, improving collaboration and demolishing those ivory walls.

Clearly, architectures and technical designs that are discordant with the enterprise architecture will produce consequences felt at the business management level. Establishing a culture for compliance across the organisation will ensure that non-compliance will be unacceptable at ever level – it will no longer be non-compliance within IT, it will be non-compliance with the business as a whole, raising the stakes for anyone bold enough to defy the EA.

Conclusion – make convenience for compliance a priority and reinforce compliant behaviours with a postive culture

• Make it convenient to do the right thing first, then improve awareness of the rules to drive compliant behaviour
• Ensure urgent ‘exceptions’ don’t derail your governance initiative by establishing a process for managing exceptions in a prioritisation framework
• Develop a strong culture of acceptability and make everyone a stakeholder in the outcome, encouraging the connection with business enablement.

Common sense, isn’t it?

NB., this replaces an earlier article ‘Understand why governance is needed before deciding on how to govern’