Last update PvD
Central versus Distributed
This document discusses central versus the distributed organisations and architectures.
There is a great similarity between the organisation of people and the architecture of systems with respect to issue centralisation versus distribution: both are resources structured according to their responsibilities/capabilities to reach the overall objectives.
An organisation is a particular structuring of people into departments and/or units characterised by the distribution of their responsibilities. The architecture for a system means the structuring of components or units according to their functional capabilities.
A related aspect is specialisation (which will also be discussed).
The rest of this document considers the distribution of responsibilities/capabilities for people/systems into an organisation/architecture as basically the same problem.
The two main ways to distribute responsibilities/capabilities (i.e. to organise) are:
Note that above describes two extremes for the purpose of discussion. And here, uniform has the emphasis on qualitatively uniform, not quantitatively. I.e. identical regarding structure/architecture and responsibility/capability, not necessarily in size.
A determining factor for the structure is the amount of interaction between units to complete a job. The interaction is usually transport, either of information (communications, e.g. meetings, telephone calls, datacom) or material (parts, semi-products).
Functions which require a lot of interaction –apparently of unequal value, and thus specialised– must be co-located.
If the amount of interaction between units is considerable, co-location of the specialised units is favoured: centralisation. If uniform units can do most jobs autonomously, there is no need to be co-located; on the contrary, there are multiple reasons to disperse the operations: distribution.
Note that we are talking about interaction to complete a job, not the managerial interaction between a unit/department and the (central) headquarter like financial reporting and management directives.
This implies that the contrast uniform versus specialised is in practice also a distributed versus central contrast. I.e. distinct organisational/architectural solutions. Further down we will also discuss a kind of mix.
Typically, in order to remain manageable (due to the 'scope of control'), a large organisation tends to distribute its responsibilities into specialised units ('departments'), i.e. distribute according to the specialised structure described above. This will certainly happen for a large centrally-organised structure, but will also occur within a distributed (uniform) unit when it grows beyond a trivial size.
On the other hand, centrally organised structures may have local representation (e.g. sales offices/front-ends), and distributed units will have some central management office or headquarter.
All this obscures straightforward recognition of the basic structure. The easiest way is to look at the characteristics of the units: when there are multiple similar units, and each unit is autonomous for normal operation, it is a uniform and distributed structure; otherwise it is a centralised and specialised structure.
Note that there can be specific reasons to have particular organisation/architecture, for example ease of control, robustness (fault-tolerance by redundancy), or required/desired local presentation. We will address that later.
The rest of this document discusses distributed organisation versus the central organisation, considering it also the uniform versus the specialised controversy. And similarly valid for systems (take for example the PC versus mainframe-debate).
Essential for a distributed organisation is that units are autonomous, at least for normal operations. There might be some central functions (e.g. policy, arbitration, facilities) but they should not be involved in normal daily operations (decision making) of the units. Distribution of responsibility means that there is no master/slave relationship, or a front-end function; the distributed units should have sufficient capabilities and mandate to handle the jobs themselves. Possibly, that mandate will be subject of discussions from time to time (and it may shift over time).
However, there must be some relationship between units, otherwise it is a collection of unrelated units and not an organisation. Also, for very large jobs units may co-operate; but than one of the units will act as the project leader/main contractor. The relationship between units is peer-to-peer (i.e. it will only work with mutual co-operation), and preferably client/server (i.e. a customer/provider relationship) on a transaction basis. Often there is some kind of competition between the units, but they should operate as a single entity (which they ultimately are) towards the outside world. The competition between the units may prove to be a risk and an advantage for the whole organisation.
Units should have the same basic functional capabilities (qualitatively; there can be quantitative differences). Differences in capabilities will lead to distinct classes of units, which is of course possible (and do actually occur) but obscures this discussion.
The greater size of a central organisation commonly forces a hierarchy (in technical terms a master/slave relationship). Work is typically distributed to the specialist departments, each contributing its expertise to the overall solution. To some extend, work is carried out after another i.e. serially, and requires co-ordination. It implies synchronisation, delay, and overhead.
Though a central/specialised structure requires more complex and close co-ordination than a distributed/uniform structure, it is also a structure we are more familiar with.
Separation of responsibilities between departments is commonly poorly formalised (for the greater part it is obvious which department is responsible).
A distinct risk is that the specialised units may become entities on their own ('empire building'), and responsibilities of departments may overlap or leave gaps. Struggle for power between departments is pretty common. When things go wrong –not unlikely between the 'empires'– it will lead to 'finger pointing'. Work which involves multiple departments tends to suffer from delays and poor quality.
Also, as control is less clear, abuse and fraud are more likely to go unnoticed for very long.
When centrally structered organisations/architectures become very large, the will also pose a heavy load on infrastructures (e.g. require a lot of electric power, wide roads and huge parking lots).
However, size can also be advantageous in that it results in a more effective use of resources, in particular of specialists. Grosh's law (on computer hardware) states: A performance increase factor n can be achieved at sqrt(n) costs (valid except for the extreme low-end and high-end). And even without Grosh's law: as the load tends to even out with many requests, it will be easier to utilise (specialist) resources in a central structure than in a distributed structure. Think for example of hospitals.
A basic question is why one would ever want a distributed organisation/architecture ? Well, some jobs are more effectively when carried out in a distributed organisation/architecture. The applicability of a central versus a distributed organisation/architecture depends on:
If there are no clear arguments for a central/specialised or distributed/uniform structure, the 'other reasons' predominate the applicability. The actual distribution is typically based on physical grounds (e.g. geographics).
The success of a any solution depends on proper architecture, i.e. definition of the organisation in responsibilities (clear separation) and interfaces for inter-relations (interworking).
A central hierarchical structure is very common, but often less effective. A distributed solution offers attractive characteristics (scalability, modularity, robustness), but a good design of the architecture/organisation is crucial.
Effectiveness is defined by the objective(s) of the organisation/architecture, which is unknown here. Effectiveness is determined by the (business) processes in- and between the various units/departments, and no organisation chart is showing that.
Probably most existing organisations/architectures were structured using the correct arguments, but as costs and priorities change over time, the arguments have to be re-evaluated after some years.
A mix of central and distributed functions is of course possible though it may lack clarity. Like some aspects centralised and others distributed (e.g. financial reporting centralised, manufacturing distributed). A more intricate example: end-to-end monitoring of a connection through a network requires distributed data collection to a central management centre. However, there can be multiple management centres, each responsible for a group of connections, or an area in the network.
In such a structure it is very likely that the mandate on the autonomy of the distinct units is discussed regularly.
For comparison of various aspects in Central versus Distributed organisation/architecture one has to assume similar use of resources and similar performance. Note that the table below provides only general statements, which may be inapplicable for specific cases.
|Organisation||Large, hierarchical, perceived as monolithic||Small, flat, flexible|
|Responsibility||Seemingly simple (responsible for everything); however when it gets big, it tends to get diluted (overlap and gaps between areas; 'finger pointing')||Good, clear responsibilities (also essential). Units need mandate for autonomy|
|Control||Commonly through a hierarchy, i.e. indirect. Poor when large||Direct & relatively easy (when no inter-unit co-ordination is required; potentially poor when many units are involved). Units may become too independent|
|Information, Data||All in one place forces all applications to go there; however, data integrity is doubtful (poor visibility)||Good data segmentation required (which is not easy); synchronisation can be an issue. Otherwise integrity should be Ok|
|Communication||All internal, typically not formalised||Communication with peers is formal and more of the external type|
|Scalability||Limited by supporting platform and complexity. Size changes the problem||Virtually unlimited; depending on the nature of the job limited in practice by the number of interactions with peer units (diminishing yield)|
|Modularity, Extendibility, Flexibility1||Point of concern (large system → unintended side-effects)||Straightforward; one may have local variants|
|Resources||Strong local demand (e.g. people), with the risk for depletion/costs||Modest and distributed demand|
|Costs||Less resources, but relatively expensive||More resources, but relatively cheap due to re-use/standardisation/competition. For development, design will be more expensive|
|Efficiency (price/performance)2||Good by economy of scale, however counteracted by overhead, 'empire building' and 'finger pointing'.||Modest due to utilisation loss (e.g. skill mix problems, resources can often not be redistributed). Interworking may also lead to more overhead|
|Robustness||Vulnerable||Very good when well structured (i.e. taking care about interdependencies)|
|Complexity||In implementation||In design (architecture)|
|Maintainability||Cumbersome||Easy, but more expensive due to dispersion|
Above comparison emphasises the extremes for the sake of discussion. In many cases of a distributed structure, it will be a mixed structure (some aspects centralised, others distributed) and/or it will use classes of uniform units (distinct levels of capabilities/responsibilities, which more or less contradicts the concept of 'uniform'). And of course there is the matter of size in the 'uniform' unit.
Also, here the organisation of people and the system architecture of components is considered identical at the abstract level. But people can handle differences and exceptions with ease, whereas in systems it presents a major problem.
Similarly, interfaces between structural components must be clearly defined in an architecture, but are often pretty vague in an organisation (which will lead to misunderstandings and debate from time to time).
A point to keep in mind is that the central/specialised versus distributed/uniform controversy may be present at multiple levels of abstraction. For example, at one level of abstraction it is distributed/uniform, whereas at the next level it is central/specialised. A good illustration is the telephone network: at the network level it is a distributed and (rather) uniform structure of exchanges, but at the exchange level it is usually a central and specialised structure of modules (though some exchange systems are also distributed).
For redundant systems see Redundancy.