Building a Relationship with the IT Architect

by Dr. Bartosz Kiepuszewski, Senior Consultant, Cutter Consortium

In the field of enterprise architecture, many architects are very critical of John Zachman's well-known framework. A number of extensions have been proposed for the framework (see, for example, the work of Cutter Senior Consultant Ken Orr, including his Executive Report "Business Enterprise Architecture Modeling"). Some architects I have spoken to have even joked that it is a real asset to them that no one seems to know exactly how to use Zachman's framework because it gives them consulting opportunities.

In a recent assignment, I revisited Zachman's original paper ("A Framework for Information Systems Architecture," IBM Systems Journal, 1987). During that rereading, I came to a realization that it may not be the framework that is the most important contribution of this paper but the first few paragraphs that talk about the role of an architect in general. We all know how much confusion in the industry the term "architecture" generates; a lot of engineers seem to equate it with "high-level design." There is an equally strong and vocal camp of architects who strongly disagree with this point of view. However, when we think about building architects or interior architects, we instantly feel the true value of this profession.

Have you ever been involved in the refurbishment of an apartment or house interior? Many of us have. Have you ever used the help of an interior architect? A lot of us do it by ourselves, but some of us employ architects. My ideal architect would possess some very important qualities: based on the interviews with my wife and me, he or she would be able to get a good understanding of our needs, translate them into specific requirements, reconcile our differences (which may be no small task, mind you), and propose a certain, consistent architectural style that would match both of our needs. The architect would be a great listener and at the same time, would have a very broad knowledge about different technologies that could be used in the house. This person would advise us of new technical possibilities and current trends and would tactfully criticize some "outrageous" ideas that would invariably spring up during "requirements gathering" sessions. She or he would be able to point out that some ideas might sound great but their realization would blow our budget out of proportion.

Our architect's great modeling skills would allow him or her to put our ideas into a "conceptual" model that we could easily relate to ("yeah, that is exactly what we meant!"). Such a model would obviously be free of meaningless technical details. But interacting with us, as hard as it sounds, is only half of an architect's job. More important, I would want our architect to supervise the construction team, making sure that what we talked about is actually going to be delivered. I would want our architect to create another set of models for the construction team (if that's what is necessary to renovate my house) and to represent me in front of this team (as I most likely will not have the time nor the skills necessary to engage in technical discussions with the contractors about the differences between polybutylene and copper piping).

But to have this work properly done, I would need to trust my architect; trust that he or she has not misinterpreted my ideas and needs, that he or she will always work in my best interest, and that he or she will not be influenced by any particular supplier or, even worse, act on behalf and in the interest of the construction team.

Over the years, I have come to think that the work of an IT architect is not much different than that of a building architect. Being a sponsor of an IT project, I would like to build a trust relationship with an IT architect so that this person understands my problem, proposes the most appropriate IT architecture for a given problem, and then supervises the actual construction -- acting in my best interest and on my behalf. The main issue often becomes how to find such a person (or team of people). Procuring a trust relationship is a Catch 22: if you go with the time-and-material-based contract, you will fear that your architecture team is more interested in its prolonged existence on your project than the project's quick and successful completion. Setting a fixed-budget, fixed-scope contract (if you can possibly fix such scope of work) is even worse, as it goes directly against building trust.

I have recently seen a tender for an architecture project from a big government agency. The agency wanted to hire an architecture team to come in and in four months build an "architecture." Since the agency feared that each potential tenderer would interpret the work product (the architecture) differently, it strived to define precisely what was to be delivered. To this end it required that the final product comprise models for each cell in Zachman's framework (the first four rows, to be exact). I can only guess that its hope was to produce these artifacts and then hand them over to one or more potential system constructors. In my mind, such an approach shows a great misunderstanding of the true value of a good architect -- this way of procuring the architecture does nothing in terms of establishing a trust relationship with an architect; an architecture team won't even supervise the system construction, so I will not be surprised if the produced artifacts turn out to be not very useful during the system construction. Which brings up another point: the belief that filling in all cells in Zachman's framework is all that is required to build a system is, I believe, a major misinterpretation of the framework itself.

An architect essentially translates user needs into a system architecture that corresponds to these needs. A good architect is both a skilled requirements analyst and an IT system designer. But what is most important is her or his ability to develop a trust relationship with the user and always act on behalf of this user. The late Cutter Business Technology Council Fellow Peter O'Farrell once told me that being a great consultant is not about immediately having all the answers that your client needs -- it is really about being someone whom the client can trust. If we think of an architect the same way, then the difference between architecture (or architect) and the design (or a designer) becomes quite obvious and distinct.

-- Dr. Bartosz Kiepuszewski, Senior Consultant, Cutter Consortium