Wednesday, September 29, 2010

Value of models 2

#entarch What are enterprise models for? What is their purpose, status, perspective, scope, meaning?

Even the scope isn't as straightforward as you might think. Okay, the enterprise model is usually supposed to be "enterprise-wide" - but how wide is that exactly? Do customers and supply chain partners belong to the enterprise for modelling purposes, or not? (Don't tell me you can resolve such questions by looking at the organization chart, because that's just another enterprise model, so you're just shifting the problem.) And even if we know how wide, we still need to know how deep. For some purpose, from some perspective.

What about the status of an enterprise model - in other words, what kind of knowledge it claims to represent? Is it supposed to be a simplified description of the current state of the enterprise (AS-IS)? Or an idealized blueprint of some future state of the enterprise (TO-BE)?

Enterprise architects typically produce both AS-IS and TO-BE models, and then produce transition plans to get from AS-IS to TO-BE. This is therefore an exercise in requirements engineering at the enterprise level. The difference between AS-IS and TO-BE can be analysed from many perspectives including engineering (technical design and specification), accounting (cost estimation and financial justification) and sociotechnical (human systems management, sometimes disdainfully referred to as "implementation factors").

In the past I have talked a lot about this process, and I may have created the false impression that the sole purpose for modelling is to support this process.

But enterprise models have another very important purpose. There is a collective management need to make sense of the complexities of the business, and so an enterprise model is a sense-making tool as well as an engineering tool.

For example, an enterprise model might give us a picture of an organization as a set of conversations and collaborations, thus helping the participants in these conversations and collaborations to make them more systematic and focused,

Looking at this model from an engineering perspective, we might identify opportunities to install more sophisticated mechanisms if that's justified, but often it's about making better use of the existing mechanisms.

If the enterprise architect always looks at the enterprise and its models from an engineering perspective, then "better use of the existing mechanisms" may not seem very important.

But I see this as part of the job of enterprise architect – not just fixing the mechanisms but understanding and advising on their effective use. The enterprise architect must therefore be capable of looking at things from a sociotechnical or business perspective, not just an engineering perspective.

If our purpose here goes beyond conventional EA practice, then the requisite scope and focus of the enterprise models changes as well. Conventional enterprise models are dominated by the operational processes, with management information typically regarded as mere superstructure. If we want to improve the manageability and intelligence of the whole organization as a complex sociotechnical system of systems, we need to be interested in the management system - the information flows and coordination mechanisms and feedback loops - not just the operational system.

An enterprise model is therefore a map to support this kind of investigation, as well as a sense-making map to be used within the management system itself, not just a blueprint for reengineering the enterprise.


Thanks to Sally Bean and Jon Durrant for useful discussion.
See also Value of Models 1.

1 comment:

itblagger said...

Hi Richard - I think you are spot on here. The key issue (perhaps failure) of EA is that it should not solely be about 'engineering' (in particular IT engineering) but first and foremost about creating abstractions that allow people to reason about the business. As you mention in another post this reasoning also needs to occur at different levels - which is why I like the idea of business capabilities so much as a way of managing the complexity we need to deal with at a particular level of reasoning. Ian