Enterprises as Social Systems

This is one of a number of articles which elaborates on a principle which I outlined in enterprise architecture principles.  The original article was a first draft, and I fully expect that some of these principles will need to be revised and/or refined.  Elaborating on the principle here should help in the process of testing the degree of shared understanding, relevance and practice amongst enterprise architects and contribute to establishing well expressed and strong principles, acknowledged as fundamental to the practice of enterprise architecture.

The following outlines the original draft of the principle.

Enterprises are commonly socio-technical systems

Rationale

• The vast majority of enterprises use a range of technical systems / technology to enable them to more cost-effectively deliver their products / services
• The operation of socio-technical systems constitutes a mixed operation of social and deterministic systems

Implications

• Architecture and design activities must be clear as to the system-of-interest being architected / designed
• Determination of the boundary between social and deterministic systems requires consideration of:
  • the degree of autonomy / control required
  • the degree of flexibility / certainty
  • the nature of the solution  as technical / adaptive
• Determination and expression of scope in terms of the social system not the deterministic system

This article will explore the background to the formulation and inclusion of this principle.  One of the potential outcomes is that a strong view emerges that this “principle” should be classified as a foundation concept, rather than a principle. Either way, it is an important underpinning to the mode of thinking required of successful architects of enterprises.

Definitions

There are a number of definitions that need to be outlined in order for readers to clearly understand the intended meaning of particular expressions in this discussion.

• Purposeful entity – being able to change both means and ends in different environments
• Social system – being a purposeful system composed of purposeful parts
• Deterministic system – being a non-purposeful system composed of non-purposeful parts
• Socio-technical system – being a social system which makes use of technology / technical systems, thereby being a purposeful system composed of purposeful and non-purposeful parts

For further elaboration on these definitions, see the article – Enterprise as system

Background and rationale

One of the drivers for including this principle is my experience that there are different architectural thinking habits and practices applicable to different types of systems.  That is, we cannot afford to assume that all the architectural practices which we apply to deterministic systems are appropriate to social or socio-technical systems.

Social systems are dynamic systems.  Their design and management requires non-linear thinking.  They also require a different mode of engagement as a social system is able to architect, design and organise itself – something that a deterministic (or mechanistic) system cannot do.  Hence, the need for different approaches.

Another driver for inclusion and exploration of this principle is that it seems that the nature of socio-technical systems is the basis of significant difficulties in relation to their design and realisation.  This arises most often when the design of the technical system is not integrated with the design of the social system, and where the tail (technical system) ends up wagging the dog (social system). 

Exploring the implications

The primary implication in an architectural context is to be clear about the system-of-interest being architected – as to whether the system is:

• A technical system
• A social system using one or more technical systems

There are a number of approaches which are used to ensure the distinction is understood, covering different parts of the development cycle, including separating:

• business architecture descriptions from technical architecture descriptions
• business capabilities and technical capabilities and their dependencies
• business objectives, information system objectives, and technology system objectives
• business scope, information system scope and technology system scope

An example of this separation is shown in the following diagram.

Another implication is the necessity to clearly determine the boundary between social and technical systems.  This requires consideration of:

• the degree of autonomy / control required
• the degree of flexibility / certainty
• the nature of the solution  as technical / adaptive

Technical systems enable enterprises to apply control and to achieve consistency and certainty within known parameters.  Social systems deal much more effectively with variety through provision of appropriate autonomy, with flexibility and adaptive responses.

Given that people have the capacity to choose between changing means or ends, it is important that scope is expressed in relation to the social system such that the ends are defined.  If the scope is expressed in technical system terms, the social system will have flexibility to vary scope as it has the capacity to explore different ends, even when the means (technical system) is constrained.

Some alternative perspectives

In seeking to architect socio-technical systems, there are a number of challenges arising from the inter-relationship and inter-dependency between the social system and the technical system(s).  The following are two different ways of exploring the technical system and its relationship to the social system.

Technical systems as prosthetics

One way to consider the technical system is to consider it as a “prosthetic” for use of people, whether they be external people (such as customers or suppliers) or internal people (employees).

The technical system exists to support nominated business processes and business functions.  The use of the prosthetic will enable the person to take actions that would otherwise be:

• too slow
• too difficult
• too expensive
• impossible

The prosthetic operates to enable the user of the prosthetic to:

• access required information
• generate and share required information with others
• undertake a process in a consistent manner

Where additional capabilities become possible, then there is an opportunity to change and improve what the user does.  At the end of the day, though, the business objectives and outcomes fall with the user of the prosthetic, not the prosthetic itself.

Technical systems as workspace

Another way to look at technical systems is to consider them as providing and enhancing the workspace for the relevant people using and occupying the workspace.

The people are able to operate in the available “information and process space”, deciding for themselves what facilities to use and take advantage of, and where the information and tools will enable them to more effectively fulfill their responsibilities and achieve their overall business objectives.

There are interesting parallels with other architectural domains.  We tend to think of an architect designing the building structures, forgetting that the structures define the spaces in which occupants will have a particular experience.  When designing technical systems, there is significant value in giving consideration to the workspace experience that is being envisaged in designing and building the system.

Each of these two scenarios – prosthetics and workspace – place the technical system in its appropriate context – as a means to an end that may be determined dynamically by the user, based on the particular conditions existing at the time.

Conclusion

All that said – I think I need to find a simpler way to express this principle – watch this space. Comments and feedback welcome!!

 

This is the second in a series of articles elaborating on enterprise architecture – principles.

 

Other series:

• Enterprise architecture – plain and simple
• Enterprise architecture – digging deeper
• Enterprise architecture – for Directors

Arrange a Conversation