Enterprise development

In the article about Operating Models, one of the four primary systems is the Development System as shown in the following figure.

I have been prompted to further elaborate on enterprise development because of:

  • the increasing interest in effective business transformation and business change and the related field of digital transformation
  • some recent commentary on the development system element of operating models

The latter can be found on Andrew Campbell’s Operating Model blog where he comments on the representation of operating models that I have outlined.

This has led me to elaborate further on:

  • the role and purpose of this system
  • the increasing importance of this system
  • the place of this system in the enterprise lifecycle
  • the implications of ignoring this system
  • a maturity view of this enterprise capability

Development System

Let me start by talking about the naming of the system, and by indicating that others may have or prefer alternate names. I chose “development system” because I believe it is helpful to consider:

  • enterprises as living systems which adapt, evolve, develop and mature in response to internal and external factors
  • change and transformation as processes which develop the capabilities of an enterprise to realise its goals and aspirations
  • the transition from an existing operating model to an intended operating model as an enterprise learning and development process

The term also relates well to other enterprise activities such as:

  • business development
  • organisational development
  • leadership development
  • professional development

Role and purpose

The development system exists to fulfill a purpose which can be expressed in different ways, including:

  • Develop the necessary enterprise capabilities to execute business strategy
  • Transform the enterprise from its current to intended state
  • Design, plan and implement the necessary changes to realise the intended enterprise

The system exists from the moment that the founder creates the enterprise through to its current form. It supports the development of the enterprise through its lifecycle. An interesting set of perspectives on the enterprise lifecycle is provided by Ichak Adizes in his book “Managing Corporate Lifecycles”.


In the past, I have not incorporated this system and its subsystems in my descriptions of the architecture of an enterprise. However, the importance of its inclusion has become evident over time. Contributing factors include:

  • Commentary on the failure of business strategy execution. It seems to me that such failure either arises due to poor strategy or poor execution. The latter reflects a failure of the development system – and its role in establishing the necessary capabilities to fulfill the requisite business strategy.
  • Commentary on change failure or project failure. Both of these are about the failure of the development system. An enterprise can have the best strategy in the world, but if it cannot be realised, then it is of no use to the enterprise. Hence, there is a need to understand the adequacy of development capabilities and address these if strategic capabilities are to be realised.
  • The increasing degree of change in the market / environment in which enterprises operate means that the demand and necessity to change and develop is becoming an increasingly important aspect of any enterprise. This is reflected in an increasing allocation of resources to the development system within many enterprises.
  • In John Kotter’s article in HBR – Accelerate, John outlines the concept of a “dual operating system” within enterprises – the operational system and the change / transformation / development system – which he sees emerging in response to the increasing demand for enterprise agility and the significantly different features and culture required in these two systems.

Hence, it seems to me that the demands for enterprises to change, transform and develop in a more adaptable and agile manner for their ongoing viability and sustainability are such that attention to the development system is not just becoming increasingly important, but is becoming unavoidable.


The enterprise development lifecycle is shown in the following figure.

The development system converts business strategy into enterprise operations. The performance system monitors the development system and the operations system in relation to progress and realisation of the intended outcomes. This provides inputs into subsequent cycles of strategy development.

Typically, key activities within the development system will include:

  • Refinement of the intended business model(s) and operating model required to effect the business model(s)
  • Development of the transformation or change strategy to realise the intended operating model
  • Formation and execution of the transformation program to put the change strategy into effect


The implications of failing to give attention to the development capabilities of an enterprise include:

  • Ongoing change and project failure
  • Higher than anticipated costs and lower than expected outcomes in effecting business strategy
  • Unnecessary revision to business strategy due to assumptions that the business strategy was deficient where it may be weaknesses in execution and deficiencies in change management capabilities
  • Unnecessary risk to enterprise viability due to an incapacity to respond to market disruption in a timely and cost effective manner


The development capability is simply another capability within the enterprise. It can be assessed in terms of its maturity, just as any other capability, identifying the different dimensions to the capability and which of these may require improvement. In part, the value of the maturity view is one of acknowledging and leveraging the areas of strength, and determining those particular dimensions where learning and/or change is required. With the increasing degree of change occurring in enterprises, early attention to the maturity of this capability will be critical for many enterprises.

Enterprise resources

In the article about Operating Models, one of the four primary systems is the Resource Management System as shown in the following figure. 

Several comments have been made about the need or value in considering the Resource Management System. This has prompted me to elaborate further on:

  • the role and purpose of this system
  • the increasing importance of this system and the implications of ignoring this system

Role and purpose

All enterprises rely on a range of resources as part of their enterprise capabilities, established to deliver their intended products / services. These resources include:

  • Finance (a means of securing other resource types)
  • People (and their associated knowledge, experience, skills, attitudes and behaviours)
  • Information (both the information consumed and the information generated and consumed by other parts of the enterprise)
  • Assets (fixed assets, plant and equipment, and technology)
  • Materials (or consumables)

The types of resources required can vary significantly across different enterprises and different industries. All enterprises have in common the need to manage finance, people and information. Many enterprises have few assets that they require and can often access the assets on a usage basis without involving the additional activities and responsibilities entailed in asset ownership. Enterprises have varying needs for materials.

The primary role of the resource management systems is to ensure that other systems are readily able to access appropriate resources meeting their performance and other requirements. These systems attend to common activities such as those relating to:

  • financial resources, including management of financial resources, financial transactions (creditor and debtor management), allocation of financial resources and reporting of financial performance
  • human resources, including support for recruiting, employment conditions, training and development, workplace safety and performance management
  • information resources, including sourcing, organising and supporting access
  • physical assets, including the management of the asset through its lifecycle from acquisition / creation through to disposal
  • materials, including supplier selection and management, sourcing, storing and ensuring they are available for immediate use so as not to impede the productivity of the people or machines consuming them


These activities emerge and develop as enterprises grow in size and complexity. They are most commonly seen in the form of Corporate Service Divisions or Shared Service Centres. Their establishment and operation enables others to focus on their core capabilities and ensures that a consistent approach is taken to management and availability of these critical resources.

In some enterprises, intermediate products and services are developed and provided to provide more effective support to the core capabilities within the enterprise. This might constitute specific value adding services around a basic resource. For example, the fleet function in a policing organisation acquires vehicles and fits them out to be an appropriate resource for patrol staff. This takes a basic resource (car) and creates a key resource for a core capability – response to incidents. It is not a core value adding process and capability, rather it is a value adding capability in providing a critical resource.

Without these capabilities, enterprises are prone to:

  • duplicating these capabilities within their core capabilities
  • failing to adequately manage these capabilities
  • compromising overall enterprise performance

Resource development

The extent and sophistication of the resource systems vary considerably for different types of enterprise and different size and scale of enterprise.

In a small enterprise, the resource management capability is most likely to be part of the manager or director roles. As the enterprise grows, it might establish a “business manager” role, which may encompass a range of the resource management functions. Further growth will lead to a point where a Finance Manager may be appointed, or a HR Manager position established. As indicated earlier, these capabilities can grow to the point of an entire Division supporting the resource management systems.

In such situations, one needs to be mindful that some of these systems operate across all functions within the enterprise. So, for example, every manager in a 10,000 person enterprise will have financial management responsibilities and people management responsibilities. There may also be other roles in providing support. For example, in a university setting, when considering the HR or people management system, one needed to be mindful that this encompassed:

  • every employee
  • every manager
  • HR support functions at School level
  • HR support functions at Faculty level
  • HR support functions at Corporate level

In such scenarios, any one of the resource management systems can be viewed as an enterprise in its own right, and will entail a complex set of systems and functions providing support to the entire organisation. Whilst these systems are not part of the operations system, delivering the core products and services of the organisation, they can be critical to the success of the enterprise, and the manner in which they operate may be part of the way in which the enterprise is able to differentiate itself.

Operating models

This is an article in the series “Enterprise architecture – plain and simple” that I published on LinkedIn Pulse last year. In the article on elements of the description of current or intended architectures, I referenced a number of key models that I use. The first and primary model is the business model, described in another article in the series.

Whereas the description of business models seems to have become more consistent through the application of the ontology developed by Alex Osterwalder, I am not so confident that there is a clear ontology or framework for operating models.

There is research and thinking which has occurred in the area of operating model design. Andrew Campbell of Ashridge Business School runs courses on operating model design and publishes a blog on the topic – Ashridge on Operating Models. He and I have exchanged views and explored the relationship between enterprise architecture and operating model design. We have already published one article on the topic of enterprise architecture – see Why business managers should understand enterprise architecture. We have only a little further to go before we could confidently say that we have shared views in this domain. That represents for me, an interesting challenge and a great learning opportunity!

As I have explored the high level models that different practitioners develop, it has become evident that different frameworks (whether individual or commercial) adopt different ways of conceiving of the primary systems of which an enterprise is comprised. The highest level abstraction of the systems of which an enterprise is comprised, then “sets the tone” for all subsequent elaborations.

In this article, I will simply share some of the patterns and models which I have used quite successfully with a variety of clients. I do not pretend that the framework that I use is any better than any others. I will outline the rationale for the framework and leave it to readers to ascertain whether it seems to provide a satisfactory basis for further development to reflect the operating model for enterprises with which they are engaged.


The primary purpose of an operating model is to express the means by which an organisation:

  • pursues its enterprise
  • realises its goals and aspirations
  • achieves and sustains viable operation

Enterprise system

There are four key systems forming the expression of any enterprise-as-system that I consider:

  1. Operations management system
  2. Resource management system
  3. Governance and management system
  4. Development management system

For many years, I have only addressed systems 1 to 3. Typically, I have not addressed the development management system, because:

  • I was usually part of this system
  • the development management system was usually embedded in the other systems

However, with the increasing degree of change, I am finding that more enterprises are recognising the development management system as a distinct system. This can be seen in John Kotter’s article – Accelerate! – where he outlines the case for a dual operating system. It can also be seen in the increasing profile of Program Management in enterprises and in enterprises where they have established a Chief Operating Officer and a Chief Change Officer.

Operations system

This system is the core system which produces the products and/or services of the enterprise. It is most commonly represented as a value stream, reflecting the core capabilities by which the enterprise transforms inputs into outputs and delivers value to its customers and consumers.

This system may also include support systems which are not part of the primary value stream. These may be systems which require specialist capabilities and are required by different systems in the value stream and deliver internal products and services beyond those provided as part of resource management.

Resource management system

This system manages each of the resource types required for successful operation of the enterprise. At a minimum, this will encompass:

  • Human resource management
  • Financial management
  • Information management

It may also include:

  • IT management
  • Asset management
  • Procurement, contract and materials management
  • Record management

Governance system

All enterprises require governance and management.

With respect to governance, I have drawn on the Tricker Model which is one of the models covered within the Company Directors Course run by the Australian Institute of Company Directors. By drawing on this model, I know that there are many Directors and Boards who will be familiar with the model and therefore comfortable with the subsystems that I include:

  • Accountability and reporting
  • Strategy
  • Policy
  • Performance reporting
  • Strategic risk management

To date, I have not modeled the management system. It seems to be adequately covered by the management embedded in each of the systems that I consider. I have included reference in this area – governance and management – to allow for inclusion of additional capabilities that become evident and require attention beyond those evident in all other areas.

Development system

This system supports the development of an enterprise and effects change in any of the systems. Change may derive from strategy, as the means by which strategy is executed, or from individual systems as part of continuous improvement. It includes:

  • Architecture management
  • Program management
  • Project management
  • Change management
  • Program and project support

I view change through a lifecycle lens taking change from idea to realisation. Key steps include:

  • Initiative formation
  • Investigation
  • Acquisition
  • Design, build and test
  • Implement
  • Review and close


Overall, this conceptualisation of an enterprise-as-system has enabled successful:

  • development of architectural models
  • formation of program strategies, plans and roadmaps

It seems to prompt reasonable coverage of the activities of any enterprise and it seems to be easily understood by stakeholders with whom I engage.  Further elaboration has been provided in relation to:

  • Enterprise resources
  • Enterprise development


Since initially publishing this article, Andrew Campbell has published Operating Model Canvas which provides a clearer articulation of operating models.  In due course, I will publish an update which outlines the elements of my thinking and practices that extend beyond the approaches outlined in Operating Model Canvas.


Enterprises as systems squared

Enterprises as systems …

Enterprises as systems of systems (or systems squared) …

Makes sense! Seems reasonable! But what does it really mean? How does it help in making sense of the enterprises in which we engage and the change or transformation required to realise the goals and aspirations of our enterprises?

A system of systems sounds like it is a hierarchy of systems embedded in systems. Closer inspection indicates that it is more complex than that!

Sole trader or freelancer

An interesting starting point is provided by considering a sole trader or freelancer – a one person enterprise. That should be simple! What systems are encompassed within their enterprise-as-a-system? Likely candidates include:

  • Business development system
  • Contract management system
  • Financial management system
  • Work management system
  • Service delivery system

How do each of these relate to the others? How should they relate to each other? How might they be organised to readily support enterprise development and growth?

Even for a sole trader, key principles and models are helpful in establishing an effective operating model which supports future enterprise flexibility, agility and growth.

Professional services enterprise

For several different professional services enterprises, I have used the APQC Process Classification Framework as a reference model for likely systems in their enterprise. An example of what this might look like is shown in the following figure.


Whilst this is portrayed as a systems hierarchy with systems composed of subsystems, it is evident on closer consideration that the system relationships are more complex than this.

For example, every executive, manager and supervisor exercises the people management system. In fact, every employee is part of the people management system. Hence, customer service staff and customer service managers are part of both, the customer service system and the people management system. Effective operation of the customer service system, as with all other systems, is dependent on a range of subsystems, including:

  • people management system
  • finance management system
  • IT management system (if IT systems are relied upon as part of customer service operations)
  • asset management system (for office and other assets which might be used)

Similarly, any enterprise subsystem could be subject to change and improvement. In such situations, elements of the business capability management system (eg. program management or project management) may be exercised in effecting improvements to the relevant enterprise subsystem.

With various of these system interdependencies in play, it is critical in planning and executing any improvement initiative for one or more enterprise subsystems, that clarity is established as to:

  • the subsystem(s)-of-interest
  • the containing system(s) of which the subsystem-of-interest may be part
  • the embedded systems which may be part of the subsystem-of-interest

Supporting technology systems

Many organisations have subsystems which are dependent on supporting technology systems, where technology encompasses any entity other than people which represents and enables the application of embedded processes. Examples of subsystems using technology include:

  • manufacturing production subsystems which operate production lines, robots, and other machinery
  • hospital intensive care subsystems which use highly sophisticated medical monitoring and life support technology
  • the vast array of organisations that use IT systems to support finance management subsystems, people management subsystems, customer management subsystems and other enterprise subsystems

This extends the system-of-systems line of thinking into addressing more complex networks of people-based-systems (soft systems) and technology-based-systems (hard systems), enabling consideration of:

  • subsystems composed of a combination of soft and hard systems
  • differing relationships and dependencies, where a single technology-based-system might provide support to multiple people-based-systems and a single people-based-system may be reliant on multiple technology-based-systems
  • application of differing methods required to deal with soft systems versus hard systems

It is in such situations of complexity that architectural methods are applied to enable multiple stakeholders and multiple solution design and delivery roles to develop shared views and deliver solution components that can be integrated into the full system-of-systems. This is where various forms of abstraction are applied to consider the parts of the enterprise requiring change and improvement, including:

  • inclusion and exclusion of subsystems
  • composition and decomposition of subsystems
  • generalisation and specialisation of subsystems

These issues are explored in other articles, including:


Enterprises as social systems

This is one of a number of articles from my series on LinkedIn Pulse where I elaborate 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


  • 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


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


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 – Enterprises as systems

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.


All that said – I need to find a simpler way to express this principle.

Comments and feedback welcome!!

Further reading:

  • Soft Systems Methodology in Action – Peter Checkland
  • Thinking in Systems – Donella Meadows
  • The Fifth Discipline – Peter Senge
  • Beyond Alignment – John Gotze

Enterprises as systems

This is part of a series on LinkedIn Pulse about Enterprise Architecture – plain and simple which I am progressively migrating to this site.  In exploring what is encompassed within the description of an architecture, I referenced the conceptual framework provided by ISO 42010 – Architecture Description which includes:

  • An architecture description expresses an architecture
  • A system exhibits an architecture

Enterprise architecture is predicated on the notion of an enterprise being viewed as a system (which exhibits an architecture). This posting explores some of the implications of viewing an enterprise as a system. It is my view that this is an important foundation stone for enterprise architecture, and that there are significant opportunities for enterprise improvement simply through better understanding systems and system principles, without the necessity to understand or change the structure and architecture of an enterprise.

There are a wide range of views in relation to systems and extensive writings and analysis of this topic. I do not pretend to be an expert in this area or to have read widely on the topic. Our understanding of the concept of system is critical to our view of:

  • the architecture exhibited by a system
  • the approaches available or required to change a system
  • the elements to consider and reflect in our architecture descriptions
  • the nature and scope of enterprise architecture

In my view, the following are key factors in some of the differing perspectives on enterprise architecture.

  • Enterprises are social systems, with most being socio-technical systems
  • Enterprises are systems of systems
  • Systems are intrinsically tied to our mental models and our use of language

My “systems architecture” journey over the last forty years started in the world of operations research as it was applied to improving policing systems. This included being part of a multi-disciplinary group with sociologists, psychologists, demographers, criminologists, statisticians, mathematicians and computing specialists. It included measuring behaviours and modeling systems to inform options for changing systems. In particular, it was an introduction to dynamic systems and their use of mechanistic systems.

During the middle years, my time was spent with designing information systems and IT systems, and acting as a facilitator to help business people understand IT systems and IT people to understand business systems and enterprises. In more recent years, I have started exploring fields such as systems thinking to broaden my understanding and ability to change socio-technical systems more effectively and successfully. This has included reading:

  • Thinking about Systems – Donnella Meadows
  • The Fifth Discipline – Peter Senge
  • The Fractal Organisation – Patrick Hoverstadt
  • Recreating the Corporation – Russell Ackoff
  • Beyond Alignment – Applying Systems Thinking in Architecting Enterprises – John Gotze (editor)

Social and socio-technical systems

I have found the definitions of systems provided by Russell Ackoff to be helpful. (If you want to appreciate how many different definitions there are of systems, then you may wish to refer to the Encyclopaedia on Systems and Cybernetics under S and view items 3322 to 3421)

Ackoff also provides a classification of systems with respect to whether the parts or whole are purposeful, where a purposeful entity is one which has the capacity to change both ends and means in differing environments (ie. it is more than simply having a purpose). This results in the following system classes:

For me, this was quite helpful in appreciating the differences between deterministic systems (in which I have had significant involvement through information systems and IT systems) and social systems. The former are designed and architected by people but do not have people as elements. Whereas the latter are composed of people, and therefore are self-architecting, self-designing, self-organising. This has significant implications for the architecture as it can be changed by any member of the social system.

Socio-technical systems then brings together the notion of social systems (enterprises) and their use of technical systems, being a wide ranging form of machines and technologies, leading into the space of empowering enterprises to realise their goals and aspirations through effective use of technologies, and ICT (information and communication technologies) in particular.

Systems of systems

Another feature of enterprises is that they are systems of systems. I wonder whether there is a tendency to think of this as a hierarchical structure where there is a progressive breakdown of the enterprise into sub-systems, sub-sub-systems, etc, whereas I am conscious that there are a range of overlaying systems, possibly viewed as a mixture of horizontal and vertical systems, but perhaps more appropriately seen as a network of systems and their subsystems.

If nothing else, this warrants careful attention to the “system of interest” in this complex web of systems, such that our discussion and exploration of the exhibited or intended architectures are related to a common entity of interest. Much confusion and debate arises through our different assumptions and perspectives on the nature and focus of the system, and requires us to provide visual aids, examples and supporting narrative to establish common understanding (whether that be amongst different members of an enterprise or amongst EA professionals).

The feature of systems of systems also gives rise to the fractal nature of the models that we develop to better understand the systems of which we are part and which we seek to change and improve.

Systems, models and language

Our understanding, communication and collaboration to give effect to enterprises and to change them to better realise the goals and aspirations we hold for them draws upon the models we develop to reflect these systems. This, in turn, draws upon our own mental models and our use of language as a key means for the way in which we think and communicate about our enterprise.

One line of thinking from the field of systems thinking holds that systems exist only in our minds. Adopting this as a principle which underpins enterprises and their architectures has offered me helpful new perspectives and insights into the challenges of effecting change in enterprises. A range of experiences reinforce the value of this principle and the way in which it “makes sense to me”.

One aspect of this dimension of enterprises is reflected in my characterisation of one of the roles that I perform as being an “enterprise babelfish”. This role is one in which attention is given to the different terms and language used by those within the enterprise to speak and describe their enterprise, and to be able to differentiate and distinguish the different meanings being applied to these terms. By helping enterprises to better understand the different ways in which members conceive of their enterprise, it is possible to develop a clearer, shared understanding which enables members to engage and collaborate more effectively.

The way in which an enterprise thinks and speaks of itself / themselves is an important dimension in developing descriptions of the current, transition or intended architectures of the enterprise. This falls into the realm of enterprise ontology (although that is not an expression I use in conversation with clients!!).

As you might expect, much more could be (and probably will be) said on each of these topics.

IT systems are a means not an end

Many business transformation and business improvement initiatives entail the use of supporting IT system(s). Often these initiatives are described, scoped, designed and delivered as IT projects. As a result, the primary focus becomes the scope, requirements, design, construction and adoption of the IT system. In so doing, these projects often fail to give sufficient attention to the broader “business system” which equally needs to be designed and delivered if the proposed IT system is to be effectively used and if the goals and outcomes sought from the use of the IT system are to be successfully realised.

Business-IT-systemsIn these circumstances, the business analysis that is undertaken:

  • defines the scope around the IT system (which constitutes the means) rather than around the business system (which constitutes and realises the ends)
  • fails to give sufficient attention to the “containing” business system within which the IT system is intended to be used
  • addresses the hard system (IT system) with insufficient attention and inappropriate skills and tools for attending to the soft system (business system)
  • encounters difficulties in evaluating variations in scope as it is the business system which provides the context for evaluating the value to be derived from the proposed use of IT functionality

These deficiencies can be redressed by taking a systems thinking based approach to business analysis. Such an approach will bring benefits through:

  • giving consideration to the system-of-systems constituting the enterprise which is the focus of the improvement / transformation initiative
  • applying a soft systems methodology which takes account of the differing system views that stakeholders may hold and enables the building of a shared conception of the enterprise in which they are engaged
  • giving attention to distinguishing between the sophisticated model that the IT system and information system will sustain and the real world context that it represents (thereby avoiding the common problem of confusing the map with the territory)
  • giving recognition to the IT system and information system being a “part” of the broader “whole” where the outcomes derived from the “system-whole” are distinguished from the outputs of the “system-part” which may not be given sufficient account in various analysis and project methodologies

Each of these will be explored in more detail in subsequent posts.