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).
Thanks,
AS
Kind of
3 hours ago
2 comments:
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.
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".
Thanks,
AS
Post a Comment