When I spend time with architects in the IT function, it doesn’t take long before the conversation turns to a great frustration of theirs.
They have a good sense of what the art of the possible in technology looks like, and they’re aware of how much better their portfolio would be if things were done the way it could be.
Yet there is a large install base, one for which there is little to no appetite for change — “it’s not broken, don’t fix it!” — and a corporate preference for what are perceived as low risk solutions, i.e. packages from reputable vendors, with implementation design done by a major consultancy rather than their group.
As a result, they perceive their contribution as limited.
Breaking out of this trap requires the architecture group, paradoxically, to break out of some of the implicit ideas of architecture they have absorbed themselves through their work:
Fully Planned = Lower Risk: I discuss with them how the desire to fully plan out solutions actually leads architects into reinforcing the preconceptions they are trying to overcome. I talk to them about how cities are “built”: they very much just grow.
Try to smooth out traffic congestion in one place, for instance, and it simply moves to another. I talk to them about all the attempts to engineer the flow — one way street systems such as are found in New York City, for instance — and how these, in turn, lead to different kinds of congestion.
Then I point to the recent changes from a one way grid in Vancouver’s Yaletown and Gastown districts to two way streets with on street parking in both directions — and how the reduction to a single traffic lane in each direction actually speeded up the flow, by allowing individuals to have many more viable paths to destinations and through the area.
The one way street grid represents the planned environment, engineered for throughput; the apparently more chaotic world of the two way streets, however, actually has fewer bottlenecks most of the time, although at no time can the “solution” to bottlenecks be found.
Similarly, in IT, we plan applications to fit process diagrams, which show (generally) one and only one “right way” to perform the work at hand.
We provide — and spend inordinate amounts of time designing and responding to feedback for — user interfaces, which gain in turn increasing numbers of functions “brought forward” to the interface in the form of buttons and widgets.
All of these, in turn, make the interface harder to learn, more complex than it needs to be, and — as with our traffic grid example — a system that lacks flexibility or alternative process paths most of the time.
Attempting, however, to ignore growing streams of user requirements, will simply discredit the architectural function.
Instead a steady process of retraining clients in how to think more openly about IT — to think of it as a field of services ready for use rather than as a set of well-defined and rigidly formulated applications matched to business processes — will be required.
As you apply this “two way street” concept more frequently, pockets of understanding will appear.
These are the assets in turn who can assist in the defence of wholesale replacement of existing function in an effort to acquire the necessary agility and flexibility needed for the enterprise to succeed in the years ahead.
Architecture today, in other words, is far more about changing impressions and attitudes than it is about “getting technology right”.