veryard projects - innovation for demanding change

Enterprise Modelling

Richard Veryard

Summary: In the application of Information Technology to business problems and opportunities, most of the focus is on new and maturing technologies, such as object technology, component-based development, workflow management, open distributed processing and internet/intranet/extranet. With this focus, technological enthusiasts attempt to demonstrate better and better solutions to yesterday's business problems.

In many enterprises, the business focus for IT remains the same: using IT to create 'strategic' applications, and to simplify and integrate the business processes. But business transformation needs to go further than this.

The business agenda of the 1990s introduced such issues as Total Quality Management, Organizational Learning, Customer Relationships, Knowledge Management, and Strategic Alignment. For IT to address this new agenda, we need new ways of thinking about enterprises and working out their requirements.

It turns out that the new technologies have a contribution to make to these requirements. Now read on ...

We model enterprises. Many people model enterprises, for a variety of reasons. We take the role of consultants, modelling to support interventions into our clients.
Does the client want it?

Can the client believe it?

Can the client understand it?

Can the consultant deliver it?

Does the client need the consultant?

What is the consultancy good for? 

We want a better understanding of how our client organizations work and change themselves. This understanding helps us identify interventions that are:
  1. desirable - the outcome is worthwhile for the client
  2. feasible - the intervention has a reasonable chance of having the desired effect
  3. necessary - the client organization is unlikely to achieve the desired effect without our help (i.e. we should be providing added-value, not gratuitous interference)
  4. demandable - the intervention can be understood as desirable, feasible and necessary by the client (i.e. there is a meaningful account of the intervention within the client’s model of reality)
We also want a better understanding of our own consultancy practice. This helps us identify ways of performing these interventions more reliably, more cost-effectively, and with fewer ethically untoward side-effects.
An enterprise is a way of being enterprising.  A single firm or SBU may be modelled as an enterprise. In addition, an entire market (such as the Stock Market or the Lloyd's insurance market) may be modelled as an enterprise.

Our clients are usually enterprises of one sort or another. In addition, our clients may participate in larger enterprises, and be composed of many smaller enterprises. We may therefore develop several nested enterprise models.

An enterprise model represents an enterprise as a system. A model is not a representation of 'reality', it is a representation of the 'reality' of some person (or group or organization) - in other words, an imaginary or symbolic construction whose relationship to 'reality' is always problematic. To read a model, you need to know its purpose and perspective (by whom, for whom) as well as its scope.
An enterprise has a model of itself. Enterprises are 'self-conscious' systems that contain models (pictures, images, descriptions) of their own behaviour and intentions. The behaviour of the system is controlled by the system's model of itself. (Such systems are known as 'anticipatory systems'.) 

As consultants, trying to intervene strategically in an enterprise, we often need to challenge the enterprise's model of itself (either in absolute terms, or relative to its competitive environment). Enterprise modelling is therefore a critical element in the collaboration between consultant and client; we always attempt to make our models accessible to the client.

An enterprise model can be used to reveal holes in the enterprise. Crudely, a hole is something within the scope of the enterprise that the enterprise has no way of managing, or even speaking about. We are primarily interested in those holes that cause symptoms - i.e. the pathogenic ones.
An enterprise model has three faces:
  • agent structure 
  • conversation/collaboration structure
  • service/obligation structure
An enterprise model has three faces, each using a different type of diagram. To detect and understand the holes in the enterprise, we need to look at two or three faces at once. We refer to this as 'split-screen' analysis. (We use computer tools that can show several diagrams side-by-side on the screen.)
An enterprise model defines a set of agents.  Each agent may be regarded as a goal-seeking system, capable of making demands on the enterprise. We call these stakeholders. However, for the purposes of simplifying our model, we may defranchise some of the agents: their demands are not legitimated (in this model). In other words, we don't necessarily regard all the agents as stakeholders, we often see many of the agents merely as actors (human or machine) performing a role. When we are modelling other people's 'reality', it can be useful to be aware of whom they defranchise, and why.
An agent has behaviour which is more or less predictable. For some purposes, we can regard an agent (even a human being) as an object. We describe objects in terms of their behaviour (how they respond to various input messages or other stimuli) and their vocabulary (the language they use for communicating with other objects).
An enterprise model defines a set of conversations or collaborations between agents.  Each collaboration may be realised as a set of exchanges. A collaboration has a vocabulary (syntax and semantics, at least), and a logic. The logic of a collaboration can be expressed as a set of invariant propositions (or responsibilities) that the collaboration is trying to maintain.

We can explain a collaboration as a composition of behaviours of the collaborating agents. For effective collaboration, the agents need to relate their individual vocabularies to the vocabulary of the collaboration.

An enterprise model defines a set of services or obligations between agents.  Management hierarchies and legal contracts are both regarded as forms of obligation.
We identify two kinds of enterprise: positional and relational. Positional enterprises are those that try to defend a fixed position - for example, a fixed competitive niche or market share.

Relational enterprises are those that are driven by the demands (actual or anticipated) of their customers. 

Relational enterprises are considered to be superior to positional enterprises. Total Quality Management demands relational enterprises.
In positional enterprises, the service/obligation structure dominates the conversation/ collaboration structure.  Additional conversations/collaborations may be required for survival, but these are not legitimated by the service/obligation structure.

Actual responsibilities of individuals and groups (what they really strive for, get blamed for) can be derived from their position in the organization hierarchy.

Much of the activity of the enterprise goes to serve the interests of an elite within the enterprise (upper management, the family, the clan), which may not be in the interests of the enterprise as a whole.

In relational enterprises, the conversation/collaboration structure dominates the service/obligation structure. Obligations (including management authorities and reporting relationships) are set up to support meaningful (customer-facing) responsibilities. This is a Good Thing.
Transforming a positional enterprise to a relational enterprise involves legitimizing new types of conversation. All enterprises include some conversations about conversations: in other words, conversations that frame (set the ground rules for) other conversations. Let's call these second-order conversations. There is a hierarchy of second-order conversation.

In hierarchical organizations, these second-order conversations are implicit, and dominated by the management hierarchy or by the 'family'.

We need to introduce third-order conversations: not just conversations about second-order conversations (these are still just second-order) but conversations that reflexively unfold the logic of lower-order conversations.

There are four levels of conversation. Most enterprises are unable to handle all four levels of conversation. Levels of Conversation: WHAT, HOW, WHO/M, WHY
The physical environment can inhibit conversations. An office, factory or laboratory provides space in which some conversations (interactions) are made physically easier and/or given symbolic importance. Good architects are conscious of these implications of physical design. However, we don't transform an organization merely by moving it into open-plan offices, or rearranging physical status tokens.

Similarly …

The information environment can inhibit conversations. Formal information management systems (including bureaucratic measurement and reporting systems, computerized data processing systems, and library and archive systems) provide a data platform for conversations. This means that strategic judgements are based on evidence provided by these systems, and are formulated in terms of the vocabulary of these systems.
In most organizations, the information environment relies on an inadequate, simplistic and out-dated enterprise model. Underlying the design of these formal systems is a model of the enterprise from the IT perspective - or more often, a series of mutually inconsistent models. 

Enterprise models from the IT perspective usually commit three types of error: 

  • lack of correspondence with users' models 
  • lack of coherence - the model fragments
  • lack of decidability - the IT processes lack any means of detecting or correcting correspondence and coherence errors 
Underlying these errors is an IT practice which deploys an inadequate, simplistic and outdated view of the world.
IT can be regarded as an enterprise in its own right The provision of information systems and services to an enterprise is itself an enterprise.
To transform an enterprise from positional to relational, you need to transform all significant subsystems from positional to relational. I'm not sure how to prove this, but it seems plausible.

It follows that we have to make IT more responsive to the business, rather than focusing on software engineering stuff. (For many readers, this may not be a new idea. But we may have reached it by a novel route.)

For most IT organizations, the challenge is to transform the software process. The focus of this transformation is on responsiveness to business requirements, and a user-centric notion of software and information quality.

When information systems are well designed, they provide an environment for people to perform creative and productive work; they are not merely machines that perform some portions of the process while constraining other parts of the process. Sadly, this is the exception rather than the rule.

Quality of software and information demands a rethink of validation, verification and testing. And we need to critique the simplistic way that IT professionals view the world. 

Software process improvement is already occupying a great deal of IT attention and resources. Unfortunately, much of this effort is going to make IT even more entrenched in the positional orientation. For example, two major software industry initiatives - TickIT and the SEI Capability Maturity Model for Software - focus on conformance to a predefined set of professional IT practices.

Requirements for information and systems need to be formulated in terms of conversations (collaborations and their vocabularies) rather than services (functions and their procedures). In contrast to prevailing IT practice, we model information based on how the information figures in conversations. We identify and analyse entity types or objects as 'speech acts', in terms of their declarative content, rather than in terms of their correspondence to imagined chunks of reality and/or procedure.

We use these speech-act-inspired information models to rethink and expose the errors underlying legacy data systems and services, and to plan remedial action.

We specify our requirements for new information systems using these information models, specifying the syntax and semantics of the conversations that the database is to support, rather than merely formatting particular man-machine exchanges.

Meanwhile, business users need to work with what's there. To support new conversations using old data systems is sometimes inconvenient rather than impossible. To the extent that the false ontologies and epistemologies of the data systems can be made apparent, the data from these systems can be 'shredded' and reconstructed to generate information that has greater meaning and relevance in terms of the desired conversations. Data from the computer can still be used, but with an interpretation that exposes their limitations.

If we get this right, the conversation hierarchy can be turned upside down. Instead of strategic user conversations being framed by IT conversations, now the IT conversations are framed by strategic user conversations.

And as consultants, we work with both the business users and the IT practitioners. Enterprise modelling has a number of uses.
  1. To identify desirable, feasible or necessary business strategies. For example, a hole in the market structure may indicate an opportunity for a niche player, or the need for a strategic alliance.
  2. To align IT strategies with business strategies.
  3. To formulate requirements for specific IT systems, or to find ways of using existing systems and data more effectively.
  4. To create a platform for changing the enterprise.


Contact Details