Archive for February, 2016

8 caricatures of an Enterprise Architect – Part 1 [Perspective]

Sunday, February 21st, 2016

Management guru Tom Peters once wrote an essay about the balancing acts which a Project Manager has to perform (in 8 different areas) in-order to be effective. Similarly, the book Collaborative Enterprise Architecture details the balancing acts required by an Enterprise Architect with the help of 8 caricatures.

Each of these 8 EA caricatures fall into one or the other extremes when he is confronted with addressing challenges in one of the four core duties (or dimensions as the authors put it) of an EA — the four core dimensions of EA being Perspective, Governance, Strategy and Transformation.

4 dimensions

Perspective: “Helicopter perspective” with little involvement in the hands-on IT business Vs. knee-deep in concrete architecture work in programs and projects

Governance: A laissez-faire approach, where each project has a high level of freedom Vs. rigorous control system in place to supervise compliance

Strategy: Great vision Vs. no long term planning at all

Transformation: Too Fast Vs. very slow

In each dimension, the EA group should find its proper position between the extremes, though no EA will be a 100% version of a caricature.


On one side, an enterprise architect is expected to have a broad overview of both the IT and the business landscapes. On the other side, the enterprise architect needs to retain her grip on the details of business and technology to such an extent that she still understands the reality on the ground. This is a wide chasm that’s not always easy to bridge


An EA who is too decoupled from the community of Project Architects, developers. In some cases, she may be equally unaware of the desires and frustrations of the actual users of the applications.

Symptoms:  A tendency to focus (only) on the “big picture”. However, many of these big pictures she meets in practice have been over-abstracted to the point of insignificance and may no longer address any relevant question.

Another symptom of a cloud cuckoo land is to depend too much on top-down thinking, without inviting or considering enough feedback from the ground

Effect:  EA or EA organization in Cloud Cuckoo Land is ignored or circumvented by both the IT and business departments on the ground.


This is the EA who focuses too much on purely technical issues or works merely as project architect, she runs the risk of neglecting the broad view and is not taken seriously by the business. This promotes the perception of IT as a cost-driving commodity instead of a business enabler. The role of an EA organization is then likely to be reduced to achieve cost reduction by managing standards and conducting IT rationalizations.

Symptoms: An EA who is too much of an “expert” in one or other technologies and who is not a generalist. He is a one-track specialist with a narrow focus on specific technologies or business requirements (such as security, performance, or user interface and stability), and misses a holistic view of the enterprise IT landscape.

Insufficient architectural skills can be another symptom — i.e. believing that an Architect is always someone who can code faster or better.

Effect:  An EA working with too much focus on the details and too little attention to the broad vision, tends to manage only singular aspects of the system. He will fail to fulfill EA’s claim to shape the IT landscape actively and capitulates in the face of complexity.
This situation drives IT into the passive role of a mere commodity. Commodities, however, are primarily perceived as cost drivers. Therefore the IT function will quickly find itself in an endless loop of cost reduction demands from the CEO.
An EA group operating too much on the detail level will not be able to ensure the design of appropriate, business-aligned IT applications.

See also: Chief Technology Mechanic, a derogatory term coined for the CIO running the shop in the above caricature