Magazine article CMA - the Management Accounting Magazine

Systems Modelling: Not a Hobby

Magazine article CMA - the Management Accounting Magazine

Systems Modelling: Not a Hobby

Article excerpt

Modelling is one of the more overworked terms in the systems profession these days. Data models, process models, enterprise models, volumetric models, technical models all exist in our vocabulary. But what do they mean to user and company management?

The easiest way to answer the question is with another. If you intend to build an office building, do you start by digging a deep hole and pouring concrete? No, you create architectural, engineering and construction plans to guide you through a complex (and expensive) process.

Both structures and systems are built using models of the desired end product. The trick is, to create models which will diminish risk of failure, but to avoid modelling for modelling's sake.

Some systems gurus talk about the need to develop a corporate enterprise model as the first step in a new development effort. After all, you need to develop a model to better understand the business, as it is now and as you want it to operate in the future. So far this makes sense.

All too often, the initial high-level model leads to more and more detailed models. Elegant, but the result is that the modelling becomes the end rather than the means. I have known organizations who have spent a year or more modelling without delivering results to help the business.

So where does modelling fit into the delivering of system solutions?

To be effective, a model must:

Have a consistent system of representation so that all like elements are depicted in the same way.

Represent all the elements necessary to describe the particular perspective.

Include only those elements contained within the particular perspective.

Typically, several models are required to describe something as complex as a business, a department, and the application systems within an organization.

The challenge is to determine the appropriate model and level of detail at each step of defining and building new systems. John Zachman of IBM has developed a framework to help clarify this. This framework recognizes the need for different diagrams for each of the key participants in a systems project--the owner, the designer and the builder. Each participant needs a different level of detail and abstraction.

Also, the Zachman Framework separates the three components of data, function, and network. The model of the system becomes transformed for each component as one progresses from one stage of development to the next as follows:

1. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.