Successful Modeling: Collect Knowledge from Natural Owners Within the Enterprise

Most people accept that large, complex enterprises need to effectively manage their knowledge about how they oper-ate and seek to operate. Without this understanding, they can’t make informed decisions about how to create trans-formations. Models of the enterprise contain knowledge and support decision making. However, modeling has al-most universally failed to deliver on its promises and to be effectively adopted as a way of managing knowledge to transformations in large enterprises.

This article draws on a decade of experience working with a wide range of clients undertaking transformations in many geographies and sectors. It looks at the question of why modeling by itself fails to provide an effective solution for enterprise decision making. Future articles will explore solutions and strategies that work.

MODELS

To support business transformation, enterprises need to develop decision-support solutions. For this approach to be effective, it is important to be able to separate the enterprise data from the models that represent the data. There are two reasons for this: the nature of models and the nature of organizations.

What Do We Mean By Models?

Models are particularly useful for answering questions. So modeling is often used in design and planning when many alternatives are being considered. Models also often are used to create visual representations, which have the power to provide an immediate perspective on a lot of data. The way something is modeled depends almost entirely on the purpose of the model; that is, on what you expect to learn from the model and, to some extent, how you want to visualize things.

Models consist of data elements related in fairly complex ways: objects, properties of objects, relationships between objects, calculated values, and so on. As they are always designed to achieve a purpose—and no one model can achieve all purposes—data elements will usually appear in many models, each with a different purpose.

More precisely, the term model means semantically explicit representations of some perceived reality. For example, models may be presented visually as diagrams (but clearly most diagrams are not models). Or they may be presented numerically or textually. For example, a cash flow spreadsheet and a project plan are both models.

It is easy to be skeptical of most things purporting to be models that are presented in text documents, drawings, or presentation tools, such as Word, Visio, and PowerPoint. Why? Because it is too easy to make things look the way you want them to look, and this is harder with real models. Of course, talented people, as well as lazy people, can create models that don’t represent reality. But fortunately, these are usually tested fairly easily.

The Inherent Multiplicity of Models—An Analogy from Architecture

The way things are modeled depends on the questions to be asked of the model. If we think about something we are all familiar with, such as a building or a city, we can see that the way we model it will vary depending on the question being asked. See figure 1 for a few examples of the questions asked of buildings.

So, What Does This Tell Us about Modeling Things?

Our answers to the building questions reflect the interests of the different stakeholders: property developer, property owner, property occupier, real estate agent, various construction trades, and so on. Each stakeholder is the natural owner of some data. The multiplicity of models needed has important consequences for the data on which they are based.

Some data elements are common to many models. For a building, these might be the number of floors, the location, the major walls, etc. Other data elements are unique to particular models, such as the range of material characteristics, how things are connected, market characteristics, physical characteristics of the location, and so on. And inevitably, we will find that data elements originating with one particular model need to be reused in another; and probably augmented or renormalized to enable the models to be properly correlated.
The success of our suite of models is going to be critically dependent on collecting and organizing the data effectively. The set of models may well represent the sum of our knowledge of the building, but they are not necessarily a good way to manage that knowledge.

The data will come from the aforementioned stakeholders, who are often the natural owners of the data. It is important that the various stakeholders understand each other’s models and domains.

What Kind of Data Will We Need to Model an Enterprise?

The building analogy illustrates that it is unlikely that we can ever define a-priori a canonical set of data elements that will suffice for all our models. The nature of the questions determines the data required. New questions—and therefore new data requirements—continue to emerge from changes in our environment and behavior.

• As with buildings, we need to understand enterprises from many perspectives:
• How our users (customers, partners, employees) will perceive and react to us
• How resilient our process and systems will be
• How much changes will cost to make
• How much things will cost to maintain and operate
• How things will perform, where things should be (data, systems, people) for optimal performance
• How much value will be generated (by products, services, systems)

Criterion

Questions 

For which we need data on ..

Usability

What will the user experience be like? For example:

What will it look like?

Light sources, surface textures, transparency and translucence. Or more simply, what will the lighting level be and how many lights do we need? 

How it will behave acoustically?

Materials’ acoustic properties, and the location and disposition of building elements, noise sources 

Availability

How resilient will it be? How will it behave in distress? 

The nature of the materials and how they respond to stress, how building elements are connected, etc. 

How it will behave in an earthquake? 

Structural properties, connections, etc.

How it will behave in a fire?

How materials will heat, how they combust, etc. 

Cost to Create

How much will it cost to establish?

Materials, products, volumes and surface areas, etc. Product and material costs, labor rates, etc.

Cost to Own

How much will it cost to maintain and operate? 

Thermal properties, service costs and life cycles, energy utilization, ongoing costs for services, etc.

Capacity

How it will perform with respect to throughput? 

Elevators’ performance and their patterns of use, vehicular and ambulatory egress patterns and loads 

Optimization

Where should things be for optimal performance; e.g., space planning? 

Costs of people and things, degrees of interaction, etc.2 

Value

How much value it will generate? 

Rental properties; e.g., usable floor space, rental rates, etc. 

Greenness

What will its carbon footprint be and how can this be reduced? 

Connectivity

How well will WiFi operate in the building and how can this be improved? 

 2. Interestingly, this space planning is often objectivily sub-optimal.

As with buildings, the success of our management of the knowledge of the enterprise is going to depend on effectively collecting and maintaining data contributed by many different stakeholders.

ORGANIZATIONS AND PEOPLE

Fragmentation of Interests in Complex Organizations

In an enterprise, many people will employ different perspectives—economic, operations, organization, product, market, contracts, and so on. They will be interested in these at different times: now, next year, and in the future. Most of them, while having a broad interest in many aspects of the enterprise, will only have a detailed interest in, and definitive knowledge of, the specific subset of the enterprise on which they are focused.

So while they may be generally interested in the services an enterprise provides, they may focus specifically on it from a business level perspective. They also may be interested in the technical aspects, the costs associated with a service, how the service is delivered (procedures, policies, information), who or what performs the service, and what agreements are associated with the services. While many people may be interested in a particular service, few will have definitive knowledge of all its aspects. This is clearly less true in very small enterprises, those that have a very slow rate of change, or those that are intrinsically very simple. In what follows we are really talking about large, complex enterprises with an ongoing need for change.

Fragmentation of Models

Often a specific set of data elements is first considered and captured in a structured and semantically explicit way, when something is being conceived, planned, or changed, and an appropriate model is needed. Later these data elements, whose initial purpose was design and planning, are reused in different ways by other models (reporting, etc.). Eventually, when things are made operational, the data elements are updated by different groups with different interests.

In this situation, the form of the data elements tends to be tightly coupled with the specific purpose and implementation of the original model. This militates against most other people interacting with the data elements. It is not that most people are not able to understand the model if it is explained to them. Rather, they don’t want to invest time and energy learning about data and relationships that are, from their perspective, extraneous.

So for most people, only interested in a small subset of the data contained in a complex model, the model will be too complex or contain too much extraneous data. The model will seem like a complex monolithic assemblage of data not necessarily well suited to harvesting the data for reuse. It is certainly not something most people will feel comfortable updating. This is especially the case if the people are not modelers by nature, or not familiar with the modeling tool or technology that was used.

The more generic the modeling tool, the worse this problem is. That is, the more the alien tool becomes an obstruction to shared understanding. Ironically, this obstruction is commensurate with the potential ability of such tools to manage knowledge.

Types of Tools

Generic modeling tools (such as meta-modelers, spreadsheets, etc.) allow users to define their own semantics.3 These tools are useful because of the broad set of semantics they can deal with and the way they allow business people to model in a language that makes sense to them. This means that if an insurance company wants to model a policy or a claim, or an entertainment organization wants to model a theater or a theme park as objects—with specific properties, relationships, calculated values, etc.—they can.
By comparison, dedicated modeling tools deal usually with a narrow set of semantics. A planning tool, for example, might essentially deal with just tasks and resources, while a data modeling tool might handle half a dozen object types.

The Tool Impedance Problem——An Example

A spreadsheet is a modeling tool that most of us are familiar with. Spreadsheets can be used to create complex models. They are also effectively, in a business sense, meta-modelers. The objects that can be represented are constrained (by validation, formatting), and the relationships that can be defined are limited (to formulas, lookups, etc.). Still, a set of business semantics can be defined.
Many of us are quite capable of using spreadsheets and creating such complex models. Yet when someone presents us with their complex spreadsheet containing lots of data and many relationships representing business semantics—and they ask us to review it and perhaps update some data—most of the time our reaction is: “I don’t really want to spend the time understanding your model, just tell me what you want to know.” This is a reasonable reaction.

Which Brings Us Back to Data Independence

The unavoidable conclusion here is that there must be a neutral way, independent of any modeling paradigm, for updating the data elements represented in a model. A way that suits the interest and level of understanding of each person or role expected to be involved. A way, moreover, that ensures the data sets are available for use in models of every kind, making the data fully reusable. Only then will we have a virtuous cycle of data use and update that will result in knowledge being accreted as a natural by-product of day-to-day behavior.

CONCLUSION

Thus, enterprise modeling so far has not delivered on promises because the data sets represented in models have not been visible in a form independent of models. The data have not been reusable by all models, all tools, and all people with an interest in them. The result has been incomplete and ineffective management of the knowledge, making models too expensive to populate and keep current.

by Michael Ellyett, the director of strategy and technology for RHE & Associates (www.rhe.com).