A Model For Company Documentation

Discovering the model: In a simple thought experiment we try to find out how a company runs its electronic bookkeeping, what sort of hard- and software they use, how they are organized, we shall identify people, their roles, who does what and of course we would like to find data, how they are generated, protected, reported and so on. Our final target: Define the object granularity for internal controls.

So let  us “walk into” the company X and look for hardware and software. We look for hardware and software first, as nobody ever could work, if there were no such objects. So let us freeze all activities inside our company X and take a snapshot picture.

Walkthrough 1st Part

At first we have to walk into the building (container top-level-class). Then we move into rooms (container-sec-level-class); in the rooms we see cabinets (container-third-level-class) and hardware: computers (servers, clients, mainframes..), network cables linking systems,  hubs, switches, telephone systems, printers, scanners, jukeboxes etc. But IT-equipment without software won’t make sense. So we can postulate the existence of software: operating systems, applications, firmware etc.  Let us call this collection of containers and all of the IT-stuff the IT-Universe (a universe needs space!) of the company X.

IT-Systems (active components like server, client, hub, switch, telecom & phone devices, ADSL/DSL modems,  network-printers, PDAs, Laptops, USB-sticks… and passive components like archive disk, worms, CD-ROMs etc.

Infrastructure (or IT-Links): Cable and radio links.

IT-Applications: all kinds of user applications but no operating systems and firmware; but many databases behave like applications. Operating system and firmware are considered to be platform attributes to certain IT-System (no computer is active without OS, no compound device runs without firmware).

To make the container hierarchy part of the IT-universe makes sense as the container upwardly inherits the level of protection necessitated for IT-Systems and so on.

All the objects identified so far, quite naturally, are objects of internal control and IT-management. At present we do not care about granular attributes for the objects identified by now. We know those attributes anyway.

All we have done so far was to simply collect objects of perception and slot them into a bit of classification order. It looks like that.

Building, rooms and even some cabinets are labeled. Room labels carrying people’s names and department or division names induce the existence of organizational structure, i.e. individuals seem to have roles (when working, at present everything is still frozen). There are evidently three types of roles: a) The set of allowed actions when working with an application (not an IT-system which was understood to be mere hardware!), b) roles of IT-personnel enabling functionality, access, maintenance etc. and, last but not least c) management activities without IT-application support (meeting, report discussion etc.). The role category splits into three classes which is easily achieved by attribute allocation.

After identifying the individuals by their labels (names) the organization (structure and structural objects we perceive) comes along with: Department, role and person, the perceptible elements of the organization.

Nothing works without data! We find vouchers, documents, journals, accounts, master data, tax data, contracts, invoices, notes, minutes etc. as paper or electronic representation on computer screens and obtain the basic classes:  Master data, documents, vouchers, accounts, journals and protocols. Is there anything else (between elementary digital data set or paper document) that does not fit into these classes of data objects?

Walkthrough 2nd Part

End of the freeze phase. Live comes into the enterprise. Events are taking place. How can they be classified? If a new IT-System (no matter what sort of) first some IT-action have to be taken: Setup, SW installation, user access right etc. We observe IT-events which, of course, are part of a governing pure IT-process  (like the 34 processes of Coso/Cobit and its possible 318 IT-objectives or potential “activities”). What we realize (in our three-minute consciousness window) is a semaphoric, i.e. uninterruptible event. The perceptible event as a procedure or process step. Once a user has the right to work with an application (again, not a system, even though the client pc used is an IT-system) we see two types of actions. Those with inherent accounting relevance, as data are entered into the books (Biz-events) reflecting the reporting-relevant part of a business event. And we have those procedural events (Proc-events) that do not affect the enterprise value situation but which are triggered by business events. We observe Proc-events as pre- or post processing of data, controls, permissions etc. We have found 3 types of events.

Walkthrough 3rd Part

Internal Control?Now comes the blue sphere where all the thinking, organising, structuring, controlling,  etc. takes place. Most of this may be beyond perception. But “documentation” boils this down two showing the outcome. An that again is quite simple.

All of the “regular”, i.e. planned IT-events are sub processes (e.g.  Coso/CoBit). Data on the IT-event go into the IT-Journal (name, class code according to Coso/CoBit, person executing it and a list of related documents: signatures, approvals, logs, authorisation, reported to etc.): that’s it. Any “irregular” IT-event has to be reported to management or IC and enters the IT-Journal as an “exception”. The IT-directives show hat has been established and what is in force now.  What has been done to reduce or avoid risks emerging in the IT-universe? It is in your IT-Security danger-solution operator applied to each element of the IT-universe. This gives us the documentation recorded on execution of it-governance.

Internal Control? There is a regular report or someone is reporting something. The content gives rise to an action. The action is an IC project involving some risk analysis? The outcome of the project is the implementation of some kind of IC instrument, i.e. an IC-application? What ever IC event has taken place can be found in the IC-Calendar. What else do we need to keep track of Internal Control?

Governance should be based on principles: policies, guidelines, codex, etc. A list of the standards the company has taken steps to comply with, how risks are handled, what sort of tools used and a calendar stating principle override events completes the steering  activities.

Walkthrough 4th Part

The remainder now is laborious, but simple. For the individual objects now documentation objects have to be modelled or existing models integrated or referred to (like e.g. the Coso maturity model or any other). The partial models for the Biz-event, the IT-event, the ICS are discussed in detail in the CookBook.

Into these models the specific attributes are put in place and the objects are linked with one another. Also more complex attributes can be assigned in check lists form.

We should keep in mind that our objects are “documentation object” intended to reflect the real world. The whole Ganymed model is an “enterprise documentation model” based on intuitive perception.

Did you realize? We were drawing heavily on Adele Goldberg’s thinking discipline of object orientation, Husserl’s phenomenology and Whitedhead’s view of the world which not “is”,  but “happens”.

Result: The procedure documentation can be represented completely in XML (when DTD or pattern collection).