I spend a lot of my working time talking to senior business and technology executives at client companies about complex strategic issues involving the use of technology in business. It's a big part of what I'm here to do and I enjoy it immensely, but over time it tends to distance you from the more mundane and practical realities of corporate technology life. Occasionally, however, something comes up that puts me back in touch with the "nuts-and-bolts" crowdthe people who have to make the strategies real on a day-to-day basis.
One such eventa request from a client to assist in the initial screening of internal candidates for a new corporate systems architecture teamgave me the chance to sit with some of the people who do the day-to-day work of corporate IT. I should point out that I don't generally do this kind of screening interview myselfnormally we would assign one of our certified business or systems architects to the taskbut the request was urgent and there were no architects immediately available (they're a very busy group). I was able to fit the interviews into some slack time on my schedule, and I really like the challenges of being a good information systems architect (I was one myself for nearly a decade). So I jumped in.
In the event, I had a great time; the candidates all acquitted themselves extremely well and I was able to steer the client toward what I think will become a very competent architecture team for its global information systems program.
So why am I telling you all this? As so often happens when I do something out of pattern, the interview process triggered some ideas and issues that I haven't thought about for a while. Back in the early 1990s, just as process re-engineering was entering the mainstream and somewhat pre-ERP, I was invited to debate the role and relevance of "enterprise IT architectures" before an audience of our clients and account executives. One of my colleagues was set to take the pure process view, proposing that all you really need are some appropriate standards and adequate operational flexibility to deal with business uncertainty. I planned to take the engineering viewthat with enough analysis and design you can cover all the possibilities, so that's why you should build an architecture. My debating partner was one of the smartest people I've ever worked with, so I did a lot more preparation than I usually do for this kind of event.
But as I put the material together for my side of the debate, I found myself questioning whether I could actually defend the position I was being asked to take. It was not so much that I was coming to think that an enterprise architecture was a bad idea, but rather that it wasn't enough of a good idea. There are limits to what architecture can do for you, and these limits are important. Let's try some analogies.
The building is not the city: Architects mostly work on single structures or, at most, small groups of related structures that are reasonably closely integrated. They focus on blending form and function around a possibly diverse but essentially finite set of purposes (you can live in a warehouse, but not without extensive transformation to the structure or major compromises on facilities) and within a generally well understood set of constraints (economics, ergonomics, aesthetics and safety) balanced against the capability of available materials, construction skills and established engineering practices. Over time, these constraints move around quite a bit, but they stay essentially at the scale appropriate to a single building or small group of buildings.
Master plans that take too long are generally overtaken by events. Look at the master-planned communities that were popular in many places in the 1970s and 1980s (Las Colinas in Texas is a good example). Many of them ran afoul of changing economic and demographic trends and were never completed (leading, in the Las Colinas example, to a partially constructed and essentially useless monorail system). Those that still exist have often had to evolve in very different directions from their initial vision. A willingness to adapt is just as critical to a viable long-term plan as is the initial clarity of the "design."
Zoning rules matter as much as designs. The right building in the wrong place (or in the right place at the wrong time) can still be a failure no matter how good a job the architect did. Sometimes the timeline for success can be a significant multiple of the construction time (the development of Canary Wharf in London's Docklands comes to mind) even if the vision is clear and the design appropriate. Sometimes you just have to wait for the world to catch up.
City planners and architects don't always mix well. They have different priorities and (it seems to me) mental models of success, even though they often share skills and training. They also operate on very different scales in both space and time. Yet both are necessary to fully realize an efficient, pleasant and workable citywith all too few examples of real success and all too many examples of what can go wrong when the right balance isn't struck.
So what does all this have to do with the subject of IT architectures?
I would argue that we IT experts face many of the same problems when we attempt to lay out a complete, enterprise-scale vision for the efficient and productive use of technology. It seems to me that we depend too much on "architects" and not enough on "city planners" who establish, monitor and evolve our "zoning" rules. As a result, we have createdand we continue to try to createunmanageably complex platform and application architectures that are more reminiscent of Jakarta than Chicago.
A "pattern" approach to architecture remains fundamental to much of what we build across many disciplines. In an ideal world, successful patterns would be what mathematicians call "fractal": essentially the same at any relative scale. We don't yet know how to do this consistently when designing towns and cities (although we seem to be getting better at the scale of neighborhoods). Nor do we have an equivalent understanding of fractal scale in our information systems, though we often behave as though we do. Quite a few of the "architectural" failures we encounter are a result of this dissonancemaintaining a living and useful enterprise data model as opposed to a database schema, for example. And we compound the challenge with extended timelines reminiscent of the failures of the master planners of the 1970s. By the time we are half done, changing business needs or evolving technologies have overtaken our master architectures.
I don't have any easy answers to this. Humans (even techno-humans) seem to really like the presumed stability and certainty that comes with a rich and richly envisioned "big picture," even if they know at heart that it will never actually be realized. In some cases they like it so much that they keep building it, even though there is abundant evidence that what they are building will never be used (although once in a while they are so far ahead of their time that the world eventually catches up with them).
I do think we need to balance our architects with some zoning specialists, however. With a better balance, we would avoid some of the unneeded duplication and overlap of platforms and application architectures we often have todayand understand better where the gaps are that we need to plan to fill, whether or not the "architects" want to work on them. If we can get complexity down and common services in place, we can improve automated provisioning and free up resources for the things we really want to do. And we can create "cities of automation" in which our architects can really shine.
John Parkinson is chief technologist for the Americas at Cap Gemini Ernst & Young. Please send comments on this column to email@example.com.