Great tweet from @judyrees this morning. "Metaphor can create powerful insights that become distortions, as the way of seeing created through metaphor becomes a way of not seeing."
When people talk about the "alignment" or "gap" between business and technology, is this just a rhetorical metaphor, or is it supposed to have a literal meaning?
I can easily understand the concepts of "alignment" and "gap" when we are talking about similar things in the same space. For example, there is a gap between my house and the house next door, and both are roughly aligned with the houses opposite. I understand what these terms mean geometrically (literally "earth-measurement") and could measure them to a reasonable degree of accuracy.
However, if someone started to talk about the "alignment" between his love life and the works of Shakespeare, I could only really make sense of this as an interesting metaphor. It would be absurd to try and measure this kind of alignment using geometrical instruments.
In order to take the notion of business-IT alignment seriously (i.e. as more than just a metaphor), we have to have some way of understanding "business" and IT" to be similar objects within the same kind of space. One possible way of doing this would be to define a distance relationship between the IT department and other parts of the organization, in terms of the interaction and coordination between separate organization units. As it happens, I did some work in the 1990s on enterprise modelling, where we experimented with the notion of "interaction distance", although I think I'd now call this "collaboration distance".
This is perhaps what is implied in a recent Strategy+Business article, which identified enterprise architecture as a way of "closing the distance between IT departments and business units" [Hugo Trepant and Daniel Newman, Strategy by Design, August 2010, via @andrewtuson].
The notion of collaboration distance can also be used to help understand the degree of alignment or misalignment between separate business organizations in the context of a complex business relationship - for example the relationship between Ford and Firestone. (See my post on Supplier Abuse.)
An alternative interpretation comes from George Ambler (@CIOLeader) who suggests that "it is the mindset gap between biz and IT that's the biggest gap of all". To interpret this literally, one would need a way of measuring the distance between two mindsets, and comparing distances between three, but at least we are talking here about notional alignments and gaps between instances of a common class.
Where I have greatest problems with the notion of business-IT alignment is where "business" and "IT" are spoken of as complex wholes apparently occupying completely different spaces. Of course, one possible tactic for enterprise architects is to produce a simplified representation of "business" and a simplified representation of "IT" within a chosen EA framework or modelling language, and then to define "alignment" in terms of some congruence relationship between the two representations. But we should be both surprised and deeply unimpressed if enterprise architecture were unable to manufacture this kind of simplified alignment, and we should be wary of circular arguments that promote the value and validity of these frameworks in terms of alignment while simultaneously defining alignment in terms of these frameworks.
Finally, I want to draw attention to a significant weakness in current enterprise architecture thinking and practice. Despite the constant rhetoric of alignment, the models and frameworks in common use provide no basis for reasoning about alignment, with all its costs and complexities. Enterprise architects profess to understand structure, but there are some important aspects of structure that are generally not addressed.
I've always thought the need for IT alignment with the business had a fairly clear meaning. The IT is generally there to support the business, and do that only. 'Support' may mean help the business carry out its functions more quickly and at lower cost (the IT comfort zone) or extend the business by giving it new capabilities, take it into new markets. It's when the IT agenda starts to be driven by the desire to learn or try new technology when the business doesn't need it that one type of misalignment arises.
ReplyDeleteThe misalignment can happen the other way round. Budgetary constraints in tough times can cause the business to lay off IT staff with vital knowledge of IT systems and make responding to a recovering market more difficult.
I think "business" and "IT" _are_ similar objects within the same kind of space: It's the business people and the IT people that we're talking about, with their different motivations. "Trust" again, in VPEC-T terms.
People on the purely business side are more likely to have their motives aligned with the aims of the business - assessments, bonus schemes, promotion should all be aimed at keeping that alignment. There will be exceptions - the salesperson who has the next job lined up and is more interested in collecting contacts, say - but this is less so than on the IT side. Decades after we'd hear "their loyalty is to 'IT' more than the company" it is still often true.
Thanks Roy.
ReplyDeleteYou define alignment in two ways.
Firstly in terms of processes - supporting, helping, giving, taking, learning, trying new technology.
Secondly in terms of intentions and values, motivation and trust.
According to the first definition, IT Processes are aligned to the business if and only if they are completely dedicated to what the business needs. The problem here is that there may not be a single view as to what the business needs. IT people can always argue, and may genuinely believe, that the long-term needs of the business will be best served by technological innovation and by preserving (as you say) "vital knowledge of IT systems", while other stakeholders may fail to see the potential benefits of these activities. Does enterprise architecture have a privileged vantage point for adjudicating such differences of opinion, and for deciding where true alignment lies? If so, it needs to have a way of reasoning robustly about alignment.
No doubt these differences of opinion arise from differences in value-system as well as differences in mindset. VPEC-T certainly helps us pay attention to these differences, and may help us to find ways to build constructive relationships between people with different value systems, rather than assuming that the value systems must always be "aligned".
Aligning the motives of business people with the aims of the business is an interesting structural problem in its own right, a problem for which HR is notionally responsible, and many large organizations are grossly dysfunctional in this respect. You mention disloyal sales people, but I'd also want to mention top management whose remuneration packages may lure them into short-term actions (including M&A) that destroy shareholder value.
So there are many complex alignments here rather than one simple one, and I'd like to see alignment treated as an aspect of structure rather than a rhetorical principle.
This comment has been removed by the author.
ReplyDeleteGreat post. Reliance on metaphor and incommensurability between metaphors—particularly in business—is an "orphan area" that doesn't have a devoted discipline.
ReplyDeleteIt's hard enough to get the problem recognized, perhaps because it's one of those cases of us not being aware of the medium we swim in (to introduce another metaphor!).
gap can be measured by amount of transformation / translation layer is needed to come down from business requirements to technical specifications.
ReplyDeletemanual translations or transformations are meant of course
ReplyDeleteTaking into account the tiers of an EA, the business, technology and people. there is always the possibility, if not the reality, that the technology malserves the business operation in that the UIs are primitive, the processes poor, the data hard to get, the application too slow etc.
ReplyDeleteAlignment in this case means that technology can be properly adjusted, once one models the EA blueprint, to better serve the business operation.
Another aspect is the difference in interests, skills, culture and aims between the business and IT departments, with IT seeming to have a mind of its own.
While this relates to people organization it is still an EA issue, i.e. EA in the wider sense. Alignement often means that the IT has to be re-organised to serve better the business units rather than the grander IT intentions.
In terms of different mindsets, the IT is often set to implement latest technology for instance while the business vows to keep any technology as long as it works reasonably cheap.
In term of skills and interests, for instance, people in ITwill easily move between industries, their skillsset being IT. So their interest is to keep updated their own skills with new technologies rather than work with the mainframes the business still employs.
Misalignment maybe measured as a gap between the reality and proper business operation. Both business and IT architecture and the gap measurement and implementation are entities in the same EA space.
But true, I've not seen yet how alignment can be shown on an EA (framework) structure except indeed in own GODS-FFLV. But this leads to a discussion about frameworks rather than alignment.
To conclude, while EA uses today a lot of buzz words or metaphors if you like, some of them have roots in practice. Alignement does.