Roles Architects can Play

Roel Wieringa (

The GRAAL project (

University of Twente, the Netherlands

15 November 2004


This text in pdf format


Roles architects can play

To understand roles architects can play, we show the layers in the diagram of the three worlds of the alignment problem.



The diagram shows the role names that we use in GRAAL in bold. There are no standard roles nor are recognized roles named in a standard way, so the diagram shows various names of other roles that are related to the GRAAL roles, although they are not synonymous with them. The core message of the diagram is that two kinds of architects must cross domains: the requirements engineer, who translates needs and desires from the social world to the sofwtare world, and the physical architect, who does the same for the physical world.

        The business architect analyzes business problems and goals, and designs business solutions. These solutions may involve now tasks, processes, roles, departments, structures etc. to be realized in the business.

o       The enterprise architect does much the same, but usually at high aggregation level.

o       The process architect does the same but focusses on business processes as a solution. In terms of the GRAAL framework, he or she focusses on the behavior aspect in the business world.

o       The information analyst analyzes information needs in the business, and the information architect designs infomation flows and structures as a solution to business problems. In terms of the GRAAL framework, these two roles focus on the information aspect of the business world.

        The requirements engineer analyzes business problems and goals and designs ICT solutions. The requirements engineer produces a software requirements specification.

o       The functional designer focusses on the desired functions the software solution. In terms of the GRAAL framework, he or she focusses on the services to be offered by the software solution.

        The physical architect takes care of alignment between the social world and the physical world.

o       For example, a building architect analyzes problems and goals of a business and designs a building that meets those needs and goals. The building architect produces blueprints and other specifications to be used by builders.

        The software architect analyzes a software specification produced by a requirements engineer and designs a software structure that will implement this specification.

o       Some companies call software architect solution architects. This is misleading because software may be a problem to be solved rather than a solution to be implemented.

o       A system designer does te same as a software architect but on a less grand scale.

o       The data architect designs data structures.

        The infrastructure architect analyzes problems and goals for the software infrastructure. He or she estimates the need for infrastructure resources by business systems, analyzes business problems and goals, and designs an infrastructure that meets those needs and goals. Infrastructure architects usually also deal with alignment with hardware.Infrastructure architecting is a demanding task, for infrastructure architects therefore consider business systems, the business iteself, as well as hardware.

o       Infrastructure architects are also called technical architects or This is misleading, for there are other things technical besides software and the hardware on which it runs.

o       Yet another name of infrastructure architects is IT architect. This is misleading too, for there are other IT systems besides infrastructure systems.

o       A technical designer does the same thing as an infrasdtructure architect but on a less grand scale.


Any of these roles can be exercised in a high aggregation level or a low aggregation level. Some physical architects design cities; other design buildings. Some business architects design an entire business; others design a single worlplace/ Some requirements engineers analyze the needs of an entire business and design an entire application layer; others analyze the needs of a particular user group and design one application as solution. Some software architects design complex distributed applications; others design a single module. Some infrastructure architects design a new architecture for the entire infrastructure layer; others design the architecture of workflow managenent support. In general, the grander the sacle, the more we are inclined to call the designer an ``architect'', and the smaller the scale, the less we are inclined to call the designer an ``architect''. This is explained in the white paper ``Architecting is Designing''.