The kind of people who visit Orbus Software’s website might be focused on processes or architecture, they might be focused on governance. They’ll all share one characteristic, however – they are required to think strategically as part of their roles. But what exactly is strategy? A brief search will turn up plenty of definitions. While no one definition stands out as best, some common themes do emerge. The analysis of a situation to identify the key elements. The identification of options and the costs and benefits of each one. The selection of an optimal course of action out of a number of possibilities. One dimension that is present, but often unspoken in all of these definitions, is the need to identify patterns.
Identifying patterns is an integral part of any analysis, and an ability to identify patterns is just as important whether you're defining an enterprise architecture roadmap or identifying ways to transform the governance of IT. This is probably why most of the people that I've encountered in these fields are not only quite good at identifying patterns, but also enjoy doing it. To some extent, it even becomes an unconscious habit, and this is where we need to be wary.
Patterns depend on classifying items based on their characteristics. For example, what is the difference between a process and a function? What makes two applications potential replacements for each other? Why might it be possible for two processes to be consolidated? The problem is that each of these entities has a large number of characteristics – which means that it's possible to identify patterns between all kinds of items.
Several years ago, I worked with one IT architect who would identify patterns as often as some people say 'um' in the middle of a sentence. One moment you'd hear “You know, Salesforce is just like Windows, because they both act as platforms for applications.” Five minutes later, it would be a case of “modeling tools are like genealogy software, because they map connections.”
The problem is, you can find similarities between any two objects if you remove enough detail between them. An iPhone is just like a napkin, because you can use both of them to take notes. A process narrative is like Google Maps, because they both give you instructions in how to move from one state to another. And so on.
So the question becomes, when is this habit of looking for patterns useful, and when is it just an amusing intellectual exercise? The question that I find helpful for cutting through this thicket of analysis is “so what?” Or to put the question in more precise and diplomatic terms, “what actionable prescriptions can we draw from this insight?”
Ultimately, what turns any analysis, any identification of patterns, from an academic ivory tower exercise, is how it can help us identify and formulate the correct plan of action. When you have a gift for finding patterns, it can be all too tempting to fall into the trap of thinking that identifying the pattern is an accomplishment in itself. But for any pattern, any analysis to be useful, it has to help guide activities.