The GRAAL project (is.cs.utwente.nl/GRAAL)
15 November 2004
In a landmark article published in 1968,
This work breakdown will be reflected in the structure of the designed system, because each designer will work on his or her own part.
We see this law at work in the way infrastructure is managed. Infrastructure is partitioned into domains, and for each domain, there are one or more infrastructure domain specialists who follow the technology market, translate business strategy into acquisition decisions for their infrastructure domain, and generally manage that domain. In all organizations studied, we found an isomorphy between the infrastructure domain architecture and the infrastructure management department, which was organized according to the same domains. This has an unexpected consequence for any reorganization of the infrastructure architecture.
This can be a hindrance to change, because infrastructure managers tend to derive their status, and also their salary, from the number of domains they manage.
In the business
For example, if the business is structured according to departments, where each department handles a set of business processes, then the business system design group should organize itself in the same way. This has the consequence that business system architects are in fact requirements engineers for particular business departments. They build a relationship with that department in which they build up implicit knowledge of user requirements, and develop an early warning system for impending changes in user requirements long before these changes are ratified officially.
The importance of such a relation was emphasized in one of the case studies we did. The organization in question was divided in a number of departments, all of which served a specific part of the company's market. The IT department was organized according to the company's structure: for each department there was a business unit in the IT department that handled all IT related work for the specific department. Each unit had its account managers, architects, software developers and maintenance personnel. The advantage of structuring the IT department in such a way is that specific knowledge about a department is concentrated in one business unit.
At a certain point in time the IT department was
reorganized according to the software development process. All account managers
were put in their own business unit, as were all architects, software
developers and all maintenance personnel, respectively. The original idea was
that each member of a business unit (e.g. an architect) can be assigned to
projects of different departments, depending on availability of personnel
within the business unit. Note that this is in contrast to