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).

Post a Comment