Architects are responsible for HOW thus capability of WHAT

Many recent discussions were talking about WHY, WHAT, and HOW as outputs of architectural work.   I already blogged about dependencies / linking between them (see http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture_19.html ).

In this post, I would like to outline who is responsible for WHY, WHAT and HOW. But, at first, let go back to basics and define "architect".  My terminology (www.samarin.biz/terminology), says that, in the broadest sense, an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.

Let us look at civil architecture. In each construction project there are three distinct roles: a customer (an individual, or an enterprise), a civil architect (a licensed individual who leads a team in the planning and design of buildings, and participates in the oversight of building construction) and a general contractor (a company which constructs buildings).

A customer contacts a civil architect who presents to the customer a solution (in some kind of visual format, e.g. a drawing or a scale model, because the aesthetics are often very important). After some possible reworking followed by acceptance of the final solution, the civil architect is empowered by the customer to guarantee a good means of construction. The civil architect selects a general contractor and the civil architect works with a foreman – an experienced professional who is in charge of organising the overall construction, including the construction crew.

The separation of duties between these roles is very important – a civil architect and a general contractor are different individuals or companies (by obligation, at least in some countries). Such a separation helps to achieve the appropriate control and quality of the results. Also, it is interesting to note that there is no explicit project manager role per se – each role has to carry out some “project management” duties. For example, a foreman is actually a project manager on the side of the general constructor (and has usually arrived in a management position after experience as a construction worker and not as a professional project manager). 

In the case of IT projects these roles could be mapped in the following way: the “customer” is a business unit, the “architect” is a small group of agreed minds (i.e. the architecture team) which translates the customer’s requirements into a viable plan and guides the execution of that plan, and the “general constructor” is an internal IT development and infrastructure unit (with the potential of outsourcing).

WHY is given as the client's intention, and it is usually implicit. A good architect must make this WHY explicit by asking right questions.

WHAT is given as the client's ideas, but neither in details nor final (for example, some client's ideas may be just impossible because of some rules and laws). The architect must explicitly define WHAT will be produced.

One definition of WHAT (for the client) has to demonstrate that HOW that WHAT is able to satisfy  the client's WHY. The architect must proof that WHAT is not just a nomenclature with smaller WHATs but how those smaller WHATs are properly structured (and properly "work" together) to deliver the requested capability (ability to address the client's WHY). Such a definition is HOW-capability.

(Remember that capability is a proven possession of characteristics required to perform a particular service with a particular results and with required performance. The key words are: "proven" and "performance".)

Another definition of WHAT, which must be prepared by the architect, is HOW-feasibility which is dedicated for the builders. It is usually a blueprint. And the blueprint is just a beginning. The actual construction should be monitored, supervised and guided to guarantee that the final product does corresponds the blueprint.

So the architect is responsible for HOW because he/she has to proof & guarantee the future performance of WHAT.

Of course, architecting modern information systems is more complex that city planning. Information systems are evolving, new technologies are disrupting, new business needs are emerging, services are re-used, processes are improved, etc. At the same time,  the potentials of proper architecture are huge (for example, http://improving-bpm-systems.blogspot.com/2012/11/an-example-of-entarch-contributing-to.html).



Anatoly said...

Functional roles of Architects in IT and in Civil construction have some basic differences. The Role of the Architect is close to a role of the Art designer in civil construction. The civil structural engineer has more responsibility before the customer for the final result.
Important constituting lines of the architectural project aren’t only a beautiful and graceful building image. The size of living rooms should correspond and approach under the sizes of furniture, doors would open in the correct direction, the vent and air-conditioning system and many other necessary for comfort provision must be correctly designed. All needs would be thought over in advance. All components would correspond each other.
People have more identical requirements via versions are in business. Analogy between roles of Architects in IT and in civil construction isn’t too obvious.

Alexander Samarin said...

A chief architect leads a team of which may include "art designers", "landscape designers", and other "subject matter experts".

All depends on the scope of work - if I need to "re-plan" an apartment then an art designer may be enough. If I need to build a separate house (e.g. chalet) then the prior work of a chief architect is mandatory to obtain a permission for construction.

Agree with you that "All needs would be thought over in advance".