Introduction

This document discusses central versus the distributed organisations and architectures.

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.

Structures

The two main ways to distribute responsibilities/capabilities (i.e. to organise) are:

Uniform: All units have basically the same responsibility/capability; the units basically operate autonomous, and consequently in parallel. A unit is capable of handling all normal jobs (service requests). Commonly, each such unit is responsible for everything in an area based on geography, language, requestor/customer, availability of resources, …
Examples: general hospitals (covering an area), local manufacturing for local market, conventional telephone exchanges; in computing: a parallel architecture.
Specialised: Each unit reflects a specialised responsibility/capability ('expertise'). The overall job is split into tasks, and each task is assigned to the unit specialised in such tasks, commonly called a department.
Examples: government (ministries), most companies (they may have local sales offices, but have only a single 'main' office and specific development and manufacturing departments); in computing: staged or a pipelined architecture with special units e.g. for floating point calculations, or for vector calculations.

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.

Interaction

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.

Comparison issues

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

Characteristics

Distributed & Uniform

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.

Central/Specialised

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.

Application Criteria

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:

location of interfaces:

distributed input (e.g. effective acquisition);
distributed output (e.g. effective distribution, local (customer) contacts);
transport is slow and/or expensive (long distance transport can not always be shared effectively).

the nature of the job to do:

co-ordination required: when a requests requires a lot of co-ordination, a centralised approach will be favourable; when a request can be handled independently and locally, a distributed approach is favourable (as it requires less inter-department co-ordination than in a large hierarchical organisation);
the size of an average job: the amount of work for a single request may require many resources, i.e. favours a large organisation, which has to be co-located (centralised) for co-ordination. If in a distributed organisation a single unit can not handle a large job, it may outsource parts to its 'colleagues', but that requires considerable co-ordination (and communication); if it can't do that the whole organisation can not effectively handle such large jobs.
availability of resources: are they locally available, can they be moved;
special capabilities (skills/expertise) required: special capabilities may have to be concentrated to warrant their efficient use (specialist workload);
the burstiness of requests, and the acceptable response times: concentration of requests tends to even out bursts, and allow cost effective utilisation of resources;

resilience (redundancy, robustness);
mandate:
is the central organisation willing to relinquish sufficient control to a unit to do its job autonomously (without meddling by HQ);
other reasons, like overhead costs, fashion of the day ('down-sizing'), etc.

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.

Mixed Structures

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.

Comparison

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.

Aspect	Central	Distributed
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, Flexibility¹	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)²	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

Notes:

Flexibility is a nice marketing term but absolutely meaningless when not attributed: flexible in which respect ?
For the same reason, developers find it impossible to achieve the 'flexibility' the customer had in mind (if the customer had any discrete notion of flexibility in advance, he should specify so).
Efficiency is greatly influenced by the possibility to prioritise tasks. When there are not too many high priority tasks, there should be sufficient time to process the low priority tasks. Overcapacity for high priority tasks is a good thing; it does not need to lead to idling.

Epilogue

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.

=O=