For the last few weeks I've been writing about how the techniques of behavioral analysis and how they might help with some of the challenges that we encounter in enterprise level design, for IT Governance and Process Reengineering. In this final article, I'm going to look at how these techniques might help with some of the challenges that we face in enterprise architecture.
Behavioral analysis is a discipline that is generally recognized as coming from the work of the Chicago economist Richard Thaler. The core idea in behavioral analysis is that you can achieve a greater level of compliance with a desired behavior by structuring how information is presented appropriately, by providing feedback and by providing the right incentives. It's been used in a number of areas, most notably by the UK government's Behavioral Insights Team – with such success that this unit has now been spun off and provides consulting services worldwide.
Before talking about the problems in Enterprise Architecture that we might address and how we could use behavioral analysis techniques to address them, it's worth taking a few moments to define the techniques that we will be using. They are:
Authority – people are social creatures, and will naturally follow a group leader. If a perceived leader in the group is doing something, this legitimizes it. So, by providing examples of companies or departments that are perceived as leaders in the space who perform an activity, the activity becomes legitimized.
Social Proof – for the same reasons, we copy the behaviors of our peers. Telling us that an activity is common amongst our peers makes us more likely to accept the activity as legitimate.
Consistency – humans hate to seem inconsistent, so if you can get them to make a small commitment in a direction, it becomes much easier to get them to move further in that direction. But people are much more likely to make what they see as a small commitment, so in this regard the proverb ‘a journey of a thousand miles begins with a single step’ is very true.
Problem 1: obtaining information
The first problem in Enterprise Architecture that we'll consider is obtaining necessary information from involved parties. While people won't directly refuse requests for information, they may not volunteer relevant information, either because they want to 'get it over with' or because the information does not come to mind. A technique we can use is...
- Consistency – the enterprise architecture team can start the exercise by asking information holders and/or stakeholders to identify some existing problems that exist at the enterprise level. This then forms the start of the information discovery exercise; having identified problems, it becomes harder for information holders to resist a team tasked with addressing those problems. The key point is that the initial statement of problems kick start the information discovery exercise.
Problem 2: compliance with policies and standards
The second problem that often occurs in Enterprise Architecture is ensuring compliance with policies and standards. Again, it's not so much a problem of outright defiance as having the buy-in to avoid subversion of intent; if every project is demanding an exemption and exemptions never expire, then policies are effectively useless. A technique we can use in this instance are...
- Authority – the initial rollout should list organizations that have reported benefits from implementing architectural standards; this should be supplemented by listing one or two on the review forms that form input into architecture review quality gates.
Problem 3: diversion to firefighting
The third problem is the recurring problem that architects face too often – that of being diverted off work on regular enterprise architecture and onto fighting more tactical fires. A technique we can use to combat this tendency is...
- Consistency – when the architecture team is given their charter, they should insist that the problems the architecture initiative is meant to address should be listed as part of that charter. This then becomes a reference so that when (not if) solutions architecture concerns start threatening to divert the teams attention, they can then point to the progress made in addressing these original concerns – and remind management of why the team was established.
As we've covered in this article trio, the subject of behavioral analysis is still relatively new – at least in terms of its adoption. It’s likely that as it becomes more mainstream, other applications of behavioral analysis to the wicked problems of IT may well become apparent.