Organisations and enterprises

Many words have been written and many said about organisations and enterprises, and the extent to which they are the same or different.  This article is prompted by a current “debate” over the meaning of “enterprise” and a suggestion that “enterprise” is distinctly different to “organisation”.  I am not so sure about that!

So, this is part of my “normal process” of “thinking out loud” – an approach where I:

  • outline what I currently “think”
  • refine what I think in order to express it in a clear and coherent manner
  • expect to be challenged
  • am offered the opportunity to refine my thinking, based on the questions and challenges arising from articulating my thinking

For me, this is the way I have become better at understanding, articulating and practicing the disciplines of architecting enterprises, governing enterprises, becoming more systems savvy, and of recent times, becoming more brain savvy.

Organisations

In using this term, it is important to distinguish between organisations and legal entities.  Oftentimes, when I think of organisation, I am thinking of:

  • a commercial firm
  • a government department
  • a community entity

This pertains more to the legal status of the entity and to the basis upon which it is constituted, managed and governed.

In this discussion, whilst it includes all of these types of organisations, I am including other forms of organisation, including:

  • an organisational unit
  • a cross-functional team
  • a multi-organisational operation
  • a community
  • a region
  • an industry
  • a profession
  • a project
  • a program

Each of these groups have:

  • membership
  • bounds
  • shared interest and purpose
  • varying degrees of linkage and relationship
  • an existence for some period of time
  • some form of means by which they are “organised”

So to the definition of organisation

an organised group of people with a common purpose

Enterprise

A number of blogs have been written on this topic already, including:

In summary …

an enterprise is most easily understood as an undertaking or an endeavour

Context

Given a systems view of organisations and enterprises, it should not be surprising that there is a need to consider system context, including:

  • the market or environment in which the organisation, enterprise or system exists and operates
  • the economy, community and society within which the market and environment exists

Any organisation, enterprise or system will need to:

  • give attention to entities in these broader contexts
  • understand the relationships that exist or should exist, both
    • across the organisation / enterprise / system boundary, and
    • amongst entities in the external environment
  • adapt the structure and behaviour of the enterprise, both
    • in light of changes in the external environment, or
    • in order to shape and prompt changes in the external environment

These activities are evidenced as an inherent part of organisations through:

  • governance processes (attending to accountability and strategy)
  • intelligence processes (informing the organisation of activity in the external environment)
  • marketing processes (understanding changes and opportunities in the external environment)
  • supplier, partner, customer / consumer, regulator and other stakeholder relationship management processes (providing direct knowledge and understanding of key external relationships)

These represent the means by which organisations attend to life-beyond-the-organisation and about which organisations develop enterprise models to enable them to understand, architect and realise their intended business models and operating models.

In this respect, the business model is the key artefact which prompts understanding and articulation of the balance required between internal and external affairs (so to speak).  Further articles outlining key thinking and practices in this area, include:

Enterprise concept and views

There are a range of benefits that I see arise from taking an enterprise view of an organisation, including:

  • organisation tends to prompt a people / role based view
  • enterprise encourages a purpose and process view
  • enterprise allows the balancing of multiple views including:
    • strategic views
    • process views
    • role / responsibility views
    • information views
    • facilities / location views
    • service views (composite of internal and external sourcing)
    • integration views
  • enterprise provides an abstraction from the connection to organisation and the threat that arises in considering organisational change
  • enterprise enables views that are agnostic to a particular dimension

For me, there is incredible value in taking an enterprise view, but none of the value derives from viewing organisation and enterprise as distinctly different.  Perhaps the following is a reasonable way to summarise?

Enterprise is an abstraction that is orthogonal to organisation

 

Bringing it all together

STORYB~1.JPGOver the last two and a half years, I have written and published over 50 articles which relate to architecting and transforming enterprises.  These have been published on LinkedIn and an index of all articles maintained in the article “Architecting Enterprises“.

About twelve months ago, I started copying these articles across to this blog site.  As I did that, I published a post on LinkedIn which proved to receive far greater views than many of my original articles.  In parallel, Interface Consultants started holding public Lunch’n’nLearn events where I was using content from these articles in sessions on:

  • Curious about being more brain and systems savvy
  • Bootstrapping a systems savvy enterprise
  • Cultivating capabilities
  • Diversity, coherence and assurance (for Boards)

Reflecting on the development of these sessions and on feedback from these sessions, it became evident to me that participants in these sessions and readers of this blog need a sense of:

  • the whole story and how the fifty (or more) articles fit together
  • how to find the pieces of the puzzle that are missing without need to read all the pieces that they already know and understand

This is how the process of “bringing it all together” started.  It has led to:

Further content is being developed and will be released.  I hope this becomes an increasingly convenient, easy-to-use, valuable resource for those involved in transforming their enterprises and looking to advance their mastery of this highly rewarding activity.

Feedback on the articles and on this initiative to “bring it all together” is always welcome.  Please feel free to post comments or to contact Interface Consultants or Peter Murchland if you wish to respond privately.  These articles are also used to prompt discussion in the related LinkedIn Group – Enterprise Modeling

 

Banning IT projects

IT-project-banBack in 2012, I attended an IT Governance seminar where Jane Treadwell, former CIO for the Government of Victoria (in Australia) started her presentation with three key assertions:

  • There are no IT projects – there are only business projects
  • There is no IT versus business – IT is part of the business
  • IT Governance by itself is misdirected

So my provocative title is more about the focus and management of projects than about banning IT.

Recently, I started a series of articles on business analysis, including:

These articles were prompted by a range of issues which I have encountered, oftentimes as a result of dealing with “IT Projects” that should be “Business Projects”. In these articles, I have explored some aspects of the relationship between what I called the “trinity of systems”:

  • Business systems (or organisations or enterprises)
  • Information systems
  • IT systems

My recent reading of “Systems Engineering: A 21st Century Systems Methodology” by Derek Hitchins has added some further understanding in this area and prompted the development of this article.

There are numerous definitions of systems – see Enterprises as Systems for further elaboration. For the purposes of this article, the following elements are important:

  • A system is a whole consisting of two or more interacting parts
  • Each part can affect the behaviour of the whole

Distinctions

It is important to understand the implications of this definition, made clearer to me in reading systems engineering papers and books. Derek Hitchins explains it this way:

Similarly, it is not helpful to think of an automobile as a system; without the driver and passengers, it is an artifact, contrivance, or — if you like — an incomplete whole. By itself, it exhibits no purpose, it does nothing, and it is inactive, inert. Add the driver, spouse and children, perhaps, and we have a socio-technical system which travels, seeks out destinations, achieves goals, observes traffic regulations — most of the time — creates a comfortable environment with constantly changing scenery, steers, accelerates and decelerates, etc; none of which the car-as-an-artifact can do on its own. And which, come to that, precious little of which the driver could do as well on his/her own. Bring the two parts together and the whole exhibits properties, capabilities and behaviors … that are, by definition, emergent, since none can be attributed exclusively to either of the rationally separable parts — automobile or driver.

The same line of argument applies to IT systems:

  • An IT system is an incomplete whole without the people who use the IT system, those who create and use information captured, stored, processed and managed by the IT system
  • The IT system may well source information from other devices and process this information into a form more usable by those using the IT system, but the IT system, like the car, is an incomplete whole without people interacting with and using the system

This is also made clear by Peter Checkland in his development of the Soft Systems Methodology, where he makes clear that people are an inherent part of an information system, as it is only people who can apply meaning to the information within the system, and hence to the information and data managed within the IT system. As outlined in Trinity of Systems, people are an intrinsic part of the information systems that enterprises establish. It is really only the enterprise-as-system that is the whole, with the IT system being a critical and integral element, but only a part of the enterprise.

Implications

There are a number of critical implications that arise from this understanding:

  • an IT system cannot be successfully created and implemented in isolation of the containing business system (enterprise)
  • the use of an IT system must always be considered in the context of the containing business system
  • the benefits of an IT system enabling and supporting the containing business system are largely realised by the business system

Isolation

In designing an IT system, account needs to be taken of how the IT system will be used. This requires the designer to conceive of the different ways in which the IT system might be used, and particularly to appreciate those ways which will be regarded as:

  • more convenient
  • more valuable

Prospective users are more likely to use the system if it is easy and convenient to use. This is part of what is considered through the lens of user experience.

Prospective users are more likely to use the system if it delivers value, either by better meeting their needs (effectiveness) and more easily meeting their needs (efficiency).

Use

Not only does the use of the IT system need to be considered in the context of the business function and objective it is supporting, but there is also a need to consider the “future” of the business function.

If the function does not deliver sufficient value, it may be targeted for change, possibly eliminating the need for the supporting IT system.

If the IT system substitutes for the business function, this will change the dynamics of the broader system of which the business function is part. Consideration will need to be given to the impacts on “other parts” within the broader business system or enterprise.

Benefits

Since the value of an IT system is derived through use of the system, the primary benefits of the system are realised by the business users of the IT system.

In the past, it was often assumed that the IT organisation unit should be accountable for realising the benefits of the IT system that they delivered. Now, it is more appropriately appreciated that the business users (and business owner) are the people who have the capacity to realise the benefits. This is directing greater attention to ensuring that business practices change such that optimum value is realised through use of the IT system.

Conclusion

Organisations that:

  • bring a stronger business focus
  • consider the business systems being enabled by the IT systems
  • ensure the business owner and users make judgements about the value they can derive from the investment in establishing and maintaining and IT system
  • hold the business owner accountable for the benefits of an IT system

are more successful in establishing, maintaining and using IT systems that deliver greater value to their enterprise.

Being clear that they are undertaking a business project is a helpful step towards doing this.

Being more systems savvy

What questions does this title prompt?

  • What is meant by “systems savvy”?
  • How systems savvy am I?
  • How systems savvy are the organisations of which I am part?
  • What is the value in being (more) systems savvy?
  • Why should I bother thinking, reading or trying to be (more) systems savvy?

Being (more) savvy

Let’s start with some synonyms for “savvy”

shrewdness, astuteness, sharp-wittedness, sharpness, acuteness, acumen, acuity, intelligence, wit, canniness, common sense, discernment, insight, understanding, penetration, perception, perceptiveness, perspicacity, knowledge, sagacity, sageness

“savvy” reflects the degree to which we understand “things” and can apply our knowledge and understanding to “things” and how we create, maintain and use these “things”.

Systems

Now, what about “systems”?

“systems” are one of the common ways in which we make sense of “things”, how they work and how to change how they work. In one respect, “systems” are a figment of our imagination. Why do I say that? Well, often different people view, describe and understand the same “system” in different ways. Lots of systems are sufficiently large and complex that we can’t know all that there is to know about the system. What we know about the system is influenced by:

  • what we know, in general
  • what we observe and experience in seeing and interacting with the system

Since that is different for each person, it is not surprising that the same system can seem different to different people. Hence, I find it helpful to appreciate that others probably have “a different system in mind” than the one in my mind.

Systems savvy

So, when we speak of being systems savvy, we mean that a person appreciates the finer points of understanding, designing, realising, and operating an entity through the lens of “systems” and is effective in designing, realising, operating, maintaining and changing “systems”.

Here are a couple of critical elements that are brought to bear in thinking about systems:

  • every system is part of a bigger (containing) system
  • many systems include feedback mechanisms

Every system is potentially part of more than just one containing system, prompting us to consider how a system-in-focus must operate in the context of being a part of a greater whole, where the other parts impact on the system-in-focus as much (or sometimes more) than any change to the parts of the system-in-focus might realise.

The feedback mechanisms enable the system to adjust to external factors over which the system-in-focus may have no “control” ie. they are open systems (when often “closed system” thinking is applied to their design and operation).

In particular, we also mean that a systems savvy person appreciates and practices the finer points relating to “social systems” – systems composed of people. Why? Because there are a number of critical differences between social systems and other systems.

Social systems

There is much to explore and understand about social systems – hence, our interest in continuing to:

  • explore new territory in this field
  • apply our learnings
  • share our learnings

Here are a couple of the most critical differences from our perspective. Social systems are:

  • self-designing, self-realising, self-operating, self-maintaining
  • reflective of how we make sense of the way in which we work or should work together
  • often the means by which we conceive, design, realise, operate and maintain other systems

Further elaboration on social systems is provided in a separate article.

Being brain savvy

Given that systems exist in our minds, as we learn more about how our minds work, we have the opportunity to change how we deal with systems in our minds.

Understanding more about how we think, feel, act and learn and applying this understanding is what is encompassed in being “brain savvy”.

So, we are interested in:

  • being more brain savvy
  • enabling us to be even more systems savvy

A range of different elements that are important to understanding systems, and how we govern, design, realise, operate and change them are explored in other articles, which can be found in this index.

Who are we? We are Associates with Interface Consultants. We offer services aimed at helping clients become more brain and systems savvy.

Interface Consultants are holding a lunch and learn event on being more brain and systems savvy. Further details are available on EventBrite.

Exploring business capability gaps

Over ten years ago, I encountered a professional services organisation which was seeking to improve the performance of its sales capability. As I looked at their existing capability, I found:

  • well-defined processes for the various elements of the sales cycle
  • a leading CRM based system to support the process
  • effective coordination, collaboration and measurement across the team and with other parts of the enterprise
  • good support mechanisms for proposal development, review and submission

Yet, there were significant differences in performance across the different members of the sales team.

This brought home to me the people element of any business capability – there are elements of people’s skills, knowledge, experience, attitude and behaviour which influence how successful they are in their roles. No amount of process improvement or systems improvement or supporting IT tools would make any difference for some individuals.

It was not longer after this that I started an assignment with another client, where we were engaged to develop a high level business and technology architecture, gap analysis and roadmap for business and technology initiatives to improve the performance of a division involved in major infrastructure projects. The Executive had already determined the key business initiatives but had not assessed where technology could best contribute.

It was at this point that we decided to undertaken an initial assessment of the ten identified initiatives, asking the Executives to nominate for each initiative, the extent to which the gaps in current capability were attributable to deficiencies in:

  • business practices – people’s skills, knowledge, attitude and behaviour
  • business processes
  • business information systems

This proved to be an important initial assessment, as there were a number of initiatives where the information systems were regarded as highly suitable, but attention needed to be given to business practices. This allowed us to direct more time and attention to deficiencies in business process and information systems, and for the Executives to attend to improvements in business practice.

A few years later, two different clients required assistance in developing business and technology architectures, assessing critical gaps and developing associated business and systems transformation roadmaps. It was at this point that we developed the following visual for prompting conversations with business executives around the composition of their business capabilities and the nature of the deficiencies that were impacting on their business performance.

CC

 

This could be developed further, going from a qualitative assessment to a more quantitative approach. In all likelihood, such analysis is more likely to be part of the development of a detailed business case than in the broad assessment of capability gaps for development of transformation strategies and plans.

Irrespective of these issues, this approach to exploring different dimensions and perspectives as to the deficiencies of business capabilities has proven to be very helpful to a wide range of business executives. It has been particularly helpful in opening their eyes to the possibility that significant business improvement may be achieved through quite small investments in improving business practices rather than the normally large investments required in improving business processes and supporting IT systems.

This was borne out again in a recent client situation where there were significant concerns about the delays in generating employment contracts. Initially, the HR Executive and IT Executive started exploring the need to integrate a recruitment system and a payroll system. As early analysis was undertaken, it was determined that the delays were attributable to the manner in which requests were prioritised and allocated, and that a change in the organisation of staff and in the triaging of incoming requests would make a far greater improvement than any initiative to integrate the two systems.

This is not meant to imply that IT systems cannot make a difference – simply to make clear that other factors can be more significant, and that there is a need to understand the business-system-in-focus and options for improving its performance. Such an approach requires the business architect or business analyst involved to appreciate the distinction between the business system and any supporting IT systems.

This article has been developed to further elaborate on the manner in which being clear about the distinction between business systems, information systems and IT systems is important and of value to business stakeholders and business improvement project members, first introduced in the article “Trinity of systems”.

Trinity of systems

There seems to be an increasing lack of understanding and subsequent lack of appropriate analysis and design in relation to the distinctions and relationships between:

  • Business systems
  • Information systems
  • IT systems

This problem underpins a number of the issues that I outlined in the article IT systems as means not ends. It has prompted further discussion with colleagues and clients, and led me to conversations with Nigel Green, exploring the issues and responses that he outlined in the book “Lost in Translation“.

This article seeks to:

  • describe the problem space as I see it in various client settings
  • outline how I conceive of this in systems terms
  • explore the implications of our failure to address these problems
  • share some of the thinking tools that I use to undertake more effective analysis and design in this area

Outline

Let’s start by outlining what I mean by each of these terms, and hopefully, what you would assume that I intend to convey when I use these terms. You might wonder why I am bothering to do this? It has been my experience that these three terms are sometimes used interchangeably, when they are distinctly different (but related).

Business system

A business system is the combination of all elements which operate together to fulfill a business objective. A business system can entail some or all of:

  • people, their knowledge, skills, behaviour, attitudes, observations, thoughts, actions
  • process, implicit and explicit ways of “doing things”
  • information, no matter where it is stored, including in computers, on paper, and in people’s minds
  • assets, equipment, materials and supplies
  • customers, suppliers, partners, regulators and other entities with which the business system interacts

Such systems could be part of an organisation, an entire organisation or a multi-organisational system. Examples include:

  • Production system within a manufacturing organisation
  • A retail store
  • Criminal justice system

Business systems include the information systems which they use to achieve their business objectives. Yet, business systems are more than information systems. They include a range of entities and activities beyond those involved in or relating to the information systems used by an organisation, including:

  • machines in a factory
  • rooms, furniture, food storage and food preparation devices in a restaurant
  • medical equipment and supplies in an operating theatre
  • people’s abilities to use these items and their interactions with each other

Information systems

An information system is the combination of elements required to collect, store, manage, remove, archive, access, analyse and report a nominated collection of information, including:

  • people who record, update, manage or access the information
  • records, irrespective of the medium on which they are recorded
  • structures, whether they be documents, forms, images, databases
  • processes which are invoked by people or technology in recording, updating, managing and accessing the information

As noted by Peter Checkland in Soft Systems Methodology in Action …

The boundary of an information system, if we are using the phrase seriously, will always have to include the attribution of meaning, which is a uniquely human act. An information system, in the exact sense of the phrase, will consist of both data manipulation, which machines do, and the transformation of the data into information by attribution of meaning. Of course, the designers of the data manipulating machine will have in mind a particular set of meaning attributions and will hope that the manipulated data will always be interpreted as particular information – but they cannot guarantee that, since users are ultimately autonomous.

Information systems encompass more than the IT systems that may be used to support them, including:

  • the people and the processes and interactions that occur beyond an IT system that may be used
  • other methods of recording and communicating information, including different media and the different methods of manipulating and interpreting the activities in which the organisation engages and interacts with other people and other objects

IT systems

Information technology systems encompass the hardware, software, networks, databases, configuration data which are composed in a particular manner to fulfill defined activities.

Little elaboration is required (hopefully) to distinguish IT systems from information systems and business systems. Yet, in the undertaking of business change projects, sometimes referred to as IT projects, the focus of the project is limited to realising the nature and intended function of the IT system, with little, and certainly insufficient, attention to the information systems and business systems which the IT system is required to support.

Extending beyond these definitions

There is a sense in which I have described:

  • an IT system as being encompassed within an information system
  • an information system as being encompassed within a business system

Of course, it is more complex than this, as information systems and IT systems can and often are created to be used by more than one business system. Nevertheless, the distinctions identified in a “simpler” scenario still apply.

There is another element to the distinctions and relative importance of business, information and IT systems. The business system provides the context within which information systems and IT systems are conceived, designed and realised. Such activities require consideration of the balance between the cost of creating and operating these systems, and the value derived by the business system in using these information and IT systems. There are numerous situations in which there will not be sufficient justification for creating proposed information systems or IT systems because the total cost of ownership (creation, operation and sustainment) exceeds the value that could conceivably be derived.

This is one of the fundamental reasons why an adequate understanding of any business system is required in proposing, designing, building and sustaining any information system or IT system.

Implications

Hopefully, the key implications of understanding and addressing the distinctions between business systems, information systems and IT systems are evident from the descriptions that I have provided for each. They are distinct and different. Each interacts with the other. The existence of an information system or IT system enables a business system to operate in a manner that is not possible without such systems. Design of any of these systems requires consideration of the interaction between all three types of systems and their design and future operation.

Hence, the key implications seem to me to be:

  • Design of each of these systems requires consideration of the design of the other systems in play
  • Design of information systems and IT systems requires consideration of the business systems they are intended to support in order to evaluate whether there is sufficient justification for the proposed scope and functionality of these systems

Tools

There is a wide range of thinking, analysis and design “tools” which can be used to ensure improved quality and integrity of the design, construction, operation and sustainment of business, information and IT systems.

Three key methods that I use in the early stages of proposing, designing and justifying information systems and IT systems relate to clear definition and articulation of:

  • Objectives
  • Scope
  • Systems

For objectives, I seek to clearly articulate:

  • the objectives of the business (system) – business objectives
  • the objectives of the information system – system objectives
  • the objectives of the project (being to realise the intended business system, information system and IT system) – project objectives

For scope, I seek to clearly articulate:

  • the scope of the business system – in business function or business process terms
  • the scope of the information system, but often the scope of the IT system
  • the scope of the project

Careful and diligent attention to expression of these and the distinctions between them has proven highly valuable in reducing project risk as they provide valuable reference points for all subsequent project, operations and sustainment activities.

Further clarity is provided by describing:

  • business context for the business system
  • system context for the information and IT systems

These aid in giving attention to the encompassing systems of which the business, information and IT systems are part, providing further clarity to the scope and function of the intended systems, where it will need to be recognised that changing the “part” may not realise the outcomes sought within the “whole” – typically being the ecosystem within which the business system will be operating.

Other tools are outlined in the following articles:

Enterprise dualities

There are a range of conceptual pairs that I have found to be important to understand and consider when architecting enterprises. Each of these pairs constitute a duality where change of one encompasses or allows change to the other. Understanding both dimensions of each of these dualities is essential to the successful architecting and design of enterprises. Equally, changing one without appreciating the other is changing can be fraught with danger! The pairs that come to mind include:

  • Self and other
  • Enterprise and organisation
  • Internal and external
  • Information and process
  • Means and ends
  • Capability and outcome
  • Autonomy and control

Self and other

I have listed this first because people are intrinsic to all enterprises. People conceive and pursue enterprises. Many enterprises entail collaboration with others, engaging them in the ongoing conception and pursuit of the enterprise.

From the outset of our lives, we engage in a process of understanding ourselves. The concept of “self” unavoidably entails the concept of “other” – to define “self”, we must be able to differentiate “self” from “other”. Consider the development of a child, coming to understand themselves as separate and distinct from:

  • their mother and father
  • the world or environment in which they live

Our understanding of ourselves is as much informed by our understanding of others, and vice versa. We communicate with others and that communication changes them. They communicate with us and that changes us.

As we collaborate with others in conceiving and pursuing enterprises, we engage in developing a shared conception of our enterprise and the manner in which we pursue it. We share our conception and others conception may be challenged, reinforced and possibly changed. They share their conception and the same may occur.

The models that we develop as part of conceiving and pursuing our collaborative enterprise inevitably entail ongoing changes to self and to others. In my experience, they are more successfully conceived and pursued when I give due attention to the manner in which others can and do contribute to the enterprise.

This duality prompts consideration of numerous dimensions, far more than can be covered in this article, providing an valuable source of topics for future articles, including:

Enterprise and organisation

“Enterprise” has a number of different meanings. Often it is used as a synonym for organisation, as in:

  • enterprise-bargaining and organisation-wide-bargaining
  • enterprise-agreement and organisation-wide-agreement
  • enterprise-development and organisational-development
  • our-enterprise and our-organisation

In architecting enterprises, it is helpful to bring a different meaning into play – as outlined by Len Fehskens when I encountered him through LinkedIn and more recently through the Association of Enterprise Architects and their journal, of which he is Chief Editor. Len encourages us to consider

enterprise as an undertaking or endeavour

In doing so, it is then possible to make a clearer distinction between the organisation that we establish to pursue the undertaking or endeavour and the undertaking or endeavour itself. It also enables us to apply the concept of enterprise in a range of different ways that are not tied to the scope of an organisation, including:

  • a new product or service as an endeavour
  • a multi-organisation endeavour
  • a project as an endeavour

Each time the conception of the endeavour changes, there will be a necessary change to the organisation established to pursue the endeavour. Each time the organisation is changed, we create the capability and opportunity to pursue different endeavours.

Internal and external

This is a more general version of self and other, but applied to any entity or system. As we create and define the boundary which “defines” the entity or system, so

the boundary creates the distinctions of internal to the boundary and external to the boundary

If we change what we regard as internal, then we are changing what we regard as external. If something changes externally, then this may cause us to change something internally.

For some enterprises, their ultimate failure has arisen through a failure to recognise the external changes that have been impacting their enterprise as each enterprise responds to external needs by making internally developed offers.

Information and process

This is probably the earliest “pair” that I encountered, as part of my role as a business analyst.

For any process, it is possible to identify:

  • the information consumed by the process
  • the information generated by the process

For any information, it is possible to identify:

  • the generating process
  • the consuming process

Hence, the view that one does not exist without the other. This has provided the basis for reviewing and assuring the quality of business requirements documents, checking that there are identified processes for the information requirements, and that there are identified information domains and entities for the process requirements.

Means and ends

This is a well known pair that comes in a variety of forms:

  • means and ends
  • strategies and objectives
  • how and why

They can exist in a cascade where:

  • Strategy A is pursued to realise objective 1
  • Objective 2 reflects Strategy A
  • Strategy B is pursued to realise objective 2

These elements may be used to explore:

  • business objectives and business strategies
  • program objectives and program strategies
  • project objectives and project strategies
  • system objectives and system strategies

Change the objectives and it is necessary to change the strategies. Change the strategies and different objectives may be realised.

Capability and outcome

Whenever a different outcome is required, there is a need to determine whether that demands new or different capabilities. Whenever a different capability is available, there is the opportunity to realise new of different outcomes.

There are several modeling techniques which enable effective exploration of this particular duality:

  • Benefit realisation chains aid in understanding the chain of outcomes that are required in order to realise ultimate enterprise goals and outcomes. Once developed, it is helpful to explore the capabilities required to deliver each benefit / outcome in the chain
  • Business capability models aid in reflecting the capabilities existing within an enterprise or required to pursue an intended enterprise. Once developed, it is helpful to explore the gaps in capability to inform a change or transformation program, and to articulate the outcome measures for each capability which aids in evaluating progress and degree of success.

Autonomy and control

Consideration of autonomy versus control arises in a range of situations, most commonly in relation to:

  • Governance
  • Management
  • Process

In a governance context, there is a recognition of the separation between the governing body and management. Governance creates an environment through articulation of strategy and policy within which management are expected to operate. Strategy and policy which are too prescriptive limit the capacity of management to respond the dynamic nature of the environment in which the enterprise operates. Alternately, ill-defined strategy and policy may offer a degree of autonomy such that management pursue outcomes beyond those identified by the governing body.

In a management context, managers and staff reporting to a manager will give consideration to the degree to which the manager controls staff or empower staff and affords them a degree of autonomy. Staff with little autonomy will often speak of being micro-managed, implying a degree of control beyond that which they deem necessary.

In a process context, consideration needs to be given to the conditions within which the process operates and the extent to which these can be accommodated by a process which prescribes what should be done versus a process which relies on the knowledge and skill of staff to determine what should be done.

In each context, increasing autonomy entails decreasing control and vice versa. Careful attention is required to determining the appropriate balance between autonomy and control.

Conclusion

Each of these dualities are important to the successful architecting, operation and sustaining of enterprises.

Perhaps there are other dualities of which you are conscious and which you find important to consider?