In an article about the IT Architecture Profession (PARDEE03), Tom Pardee wrote:

"If asked for an example of architecture, many people would point to Daniel Libeskind's design for the Ground Zero redevelopment. [...] By contrast, IT typically defines architecture as plumbing, hidden structure, and standard interfaces. This definition suggests that IT architecture is different from traditional architecture, and that it is an issue of interest to a limited technical audience—not the enterprise in general. This impression is reinforced by the diverse and uncoordinated roles played by today's IT architect."

Is this right, or should the IT Architect challenge this status quo? What can the construction industry teach us about the role of the architect contrasted with the other professions?

The English language only provides us with a limited number of tools in this area, so unfortunately we have to use overloaded terms like "design"...

Ask a building user or owner about architecture, and they are interested in two main things: the "grand design" (i.e. the big ideas, the overall form of the solution), and the "visible design" (how it looks, and how it actually works in day to day interaction with its users and the environment). The architect's primary concern is to deliver a solution on these two levels which firstly meets the objectives of the various stakeholders, and secondly provides sufficient guidance so that it can be built in line with "the architecture".

It's not actually the architect's job to know about plumbing and so on, except to understand how the requirements for and by plumbing contribute to the overall set of constraints (providing enough space for pipe runs, header tanks etc.) In the example of Daniel Libeskind's work, it is clear that structural engineers and other specialists contribute most of this within the framework of the overall design.

Even on a smaller scale, like the loft extension for a house, the architect focuses mainly on visible factors, the structural engineer contributes things like beam sizing and roof structure, and the builders then agree a lot of detail "design" as they tackle each aspect with real materials and exact measurements.

The construction trade is quite happy with these three separate roles. Architecture, Civil or Structural Engineering, and building are quite separate qualifications, skill sets and professions. Any relevant topic can be described from each viewpoint. For example consider two excellent books on the durability of buildings: "How Buildings Learn" is an architectural book, but "Why Buildings Fall Down" takes a structural engineering focus.

 So don't accept the limitation "IT typically defines architecture as plumbing." As a software architect, focus on three things:

• The "grand design" and how it (the solution) meets the various stakeholder objectives,
• The structure which underlies the "grand design", and how it will meet the quality requirements (adaptability, performance etc.),
• The "visible design", and how its users will understand it.

Different aspects of "visible design" matter to different people. For an end user, it's the user interface. Now the architect may not get involved in the details of screen layout and function, but he or she will want to establish a clear set of metaphors for the user (so they can easily understand how it works, and it works that way consistently), and a clear set of guidelines for those who are building the user interface (so that they are also consistent, supporting the same metaphors).

For programmers, the "visible design" comprises things like the design patterns and overall class structure. Again, the architect must try to set up clear metaphors (like a layered structure of components with well-defined interfaces) and guidelines so that the detail design and construction follow the "grand design".

In a recent paper (KAZMAN03) Rick Kazman identifies a similar split: architecture is about the rules and metaphors, design and implementation are about the application of those rules to specifics.

So don't believe that we should accept "IT architecture = hidden oily bits of plumbing". As architects, we should embrace the high level visionary role, focusing on how the solution delivers real value to the users.

The other things are still important, and an architect may well be involved in them. The architect may do some design, and some coding, and other things. The reality is that most software architects can do these , enjoy doing them, and have to do them to get the job done. But is it "architecture"?

Maybe we need to identify two different professions, analogues of the difference between architects and structural engineers in construction. Or maybe the concept of "IT Architect" requires a more complex layered/component model. But architects  of all sorts, in IT as elsewhere must aim for the high ground, and challenge anyone who thinks that software architecture is about plumbing and hidden interfaces.