Jaap van der Kamp, maandag 21 februari 2011
Architecture based on changing objects
What is the colour of data? Usually black, on paper as well as on the screen. Data can be observed, processes cannot. Who ever saw a business process? I have merely seen input, output and actors. The approach described here reveals the integrated nature of data and business processes. It starts with a simple observation of data. The result is an inventory of the object lifecycle with processes being state transitions. The objective of this manuscript is to give an empirical and comprehensive approach to cope with the complexity and dynamics of current administrative and business processes.
In classic modeling there is no ‘natural’ relation between data and business processes. The underlying cause here is the perception of data being fixed in a data model instead of data content being fluent. The information architect sees the structure, the honeycomb, not the honey. In winter, the bees consume the honey and the honeycomb remains. From a bee’s point of view, a lot has been changed that the architect does not perceive.
Let us look at information architecture from the bee’s point of view. The starting point is the object lifecycle of, for instance, a patient in hospital. The lifecycle starts when a doctor refers the patient to a hospital. After preregistration1, acceptance, registration and intake the patient is treated and discharged. The object lifecycle starts with data delivery by the doctor, the object ‘patient’ being regarded as a ‘bag of data’. During the patient lifecycle the data content is augmented, for instance by each treatment yielding new data. Each consecutive set of data corresponds with a new state in the lifecycle, i.e. with a new ‘patient’ object. The transition from one object to another is identical with a (step in the) business process.
Observing and describing changes is fundamental for this approach. Two millennia ago Ovid described a variety of changes in his ‘Metamorphoses’ (Ovid, 0001). He wrote about the most bizarre changes in a strikingly factual way. This approach is intended to do exactly the same. Because data is basic, the approach is called ‘Data Metamorphoses’.
The result is a realistic mapping of data within the object lifecycle, with process steps being the other side of the coin, see figure 1.
Figure 1 Interference of processes and object states in the object lifecycle. An example is given in grey.
Data Metamorphoses is based on observing data. Data is obtained from administrations, being the nutritional soil for Data Metamorphoses. Indirectly, via administrations, Data Metamorphoses provides a view on parts of reality, viz. those parts controlled by the investigated administrations.
Figure 2 The position of Data Metamorphoses with respect to administrations and reality.
Both management information and Data Metamorphoses are ‘meta-administrations’. Where management information deals with recombining and aggregating administrative and external data content, Data Metamorphoses reveals the structure and behavior of administrations and underlying reality. Without knowing these, management information loses context and meaning. Therefore, one of the benefits of an approach like Data Metamorphoses is that it adds meaning to management information.
First: Drop classic data modeling, focus on real data. Take the honey, leave the honeycomb.
Secondly: Choose the primary object that changes throughout the business process. The business process can be the primary process, but it can also be a secondary process; for example, the lifecycle of an employee which shows how a new employee is registered, how he gets his network account, etc.
Figure 3 Choose the primary object for the investigated business process. An example is given in grey.
Data is studied, starting at the beginning of the business process. This is done by observing what people do, interviewing, studying screen layouts, forms, examples of incoming and outgoing mail, spreadsheets, documents, application guidelines and working instructions. In fact you are registering which data and which objects appear to the actors. The result is an inventory of detailed data about the investigated changing primary object.
It is useful to first put the observed data in a spreadsheet and thereafter model it, for instance in the ArchiMate language. On each data element, the following is registered:
The name of the data element. For example ‘name of patient’.
The medium on which the data element can be found such as a particular document or a set of screens. The most obvious way to present the medium in the ArchiMate language is with the ‘representation’ symbol. An option is to document which data elements are found on the medium, see figure 4. The data content of ‘form A’ can be different from the data content of ‘Object 1’ because ‘Object 1’ can be spread over several media.
Figure 4 A medium, for instance a form, with its data content. The connections are drawn as ArchiMate associations.
The lifecycle stage of the primary object in which the data element appears first. The lifecycle stage, being an object itself, is reflected in the object’s name, e.g. ‘referral incoming’, ‘patient registered’, ‘patient being treated’, ‘patient discharged’.
Figure 5 The primary object in a particular stage, consisting of data elements. The relations are ‘composition’ relations. In grey the first object in the patient lifecycle is given.
The source, for instance the doctor who refers the patient to the hospital.
The source object from which the data element is copied to the primary object. For instance when a doctor sends a referral, the date and time of receiving is added to the object ‘referral incoming’ to realize the object ‘referral received’. The source object can be described as ‘receiving data’. The first step in the life cycle is shown in figure 6. This process step is drawn as an ArchiMate service.
Figure 6 The first step in the lifecycle. NB: The object ‘referral’ is seen as a specialization of the object ‘patient’. Instead of ‘referral’ one can use ‘patient referred’.
Figure 7 The resulting ‘Object 2’ is composed of all data of ‘Object 1’ plus the newly added data elements 7, 8 and 9.
The actor which adds data to the primary object in order to realize the next stage in the lifecycle.
The name of the process step that results in the transition of one lifecycle phase into another.
Eventual output objects in which the data element appears, like an outgoing message.
Following the sequence given above, an example is given for one data element.
We look at the data element with the name ‘registration number of patient’.
The first medium on which it appears is the screen of the hospital’s EHR (electronic health record) system.
The primary object is the ‘patient’, the process being the healthcare process.
The lifecycle stage in which the registration number appears first is ‘patient registered’.
The source of the data element ‘registration number of patient’ is the hospital’s information system; it generates the registration number.
There is no source object from which the registration number is copied; the registration number is generated ‘from nothing’ in the mind’s eye of the user. NB: In Data Metamorphoses an object is a ‘bag of data’, so the source object cannot be ‘the EHR system’ or ‘the EHR application’.
The previous object in the lifecycle, this is ‘patient registered’ but without a registration number, is ‘patient with an appointment’.
Actor is the care secretary registering the new patient.
The process step is ‘registering a new patient’.
An output object of the process step is a card for the patient with his name, address, doctor and registration number.
If a condition determines the workflow, a divergence occurs in the object lifecycle. An example is the first assessment of a referred patient. The result of the assessment is ‘accepted = yes’ or ‘accepted = no’. The content of this ‘accepted Y/N’ data element determines whether the referred patient will change into a ‘patient accepted’ of a ‘patient rejected’. Hitherto the origin of a new object in the lifecycle was determined by the presence or absence of relevant data elements. Now we see that the existence of an object also can be determined by the contentof a data element.
Figure 8 Divergence in the object lifecycle based on a condition.
A common way in which the lifecycle diverges occurs when an object is provided with different data and you find this relevant enough to discern a divergence in the workflow.
Figure 9 Divergence in the object lifecycle based on the presence of data element x or y.
Not all data elements influence the object lifecycle. It is not useful to model a divergence if it is irrelevant whether data element x is added or data element y is added. For example a ‘patient being treated’ may have lab results, but also a medicine prescription or a broken leg. Except for the case you are studying especially the lab process or prescription process, there is no need to discern all different combinations. In figure 10 we see neutral data elements, whose presence or absence does not determine the rise of distinct objects within the lifecycle.
Provided with data element x or data element y or both
Figure 10 No divergence in the object lifecycle although the data composition of object 3 is variable.
Processes can be folded together to become processes at a higher level. The object lifecycle corresponds by skipping objects in the lifecycle. In this document no difference is made between activities, process steps and processes.
Figure 11 To a higher level lifecycle. The two process steps / lifecycle arrows between the objects 1 and 3 (left) are merged to a higher level. The result is a shortcut between lifecycle objects 1 and 3 (right).
In professional administrations objects normally only grow during their lifecycle. Data is added and added; data loss rarely occurs. The consequence is that modeling an object lifecycle is relatively easy. A new object in the lifecycle will be composed of the previous object plus newly added data elements, as shown in the top part of figure 12.
When an object loses data elements during the lifecycle, modeling is more elaborate. The ‘magic trick’ of adding the new data to the previous object as a whole is not applicable.
In private situations data loss is common. An example is visiting a concert. Let the process start with a reservation in your agenda, the object ‘concert’ being composed of the name of the concert, your partner, date and time. By getting tickets, the row and seats are added. After visiting the concert the tickets are thrown away. The result is data loss within the object ‘concert’.
The bottom part of figure 12 shows the modeling consequence of data loss. All the remaining data elements of object 1 have to be drawn.
Figure 12 The consequence of data loss on modeling. In the picture above Object 2 is composed of Object 1 plus some data elements. If data loss occurs, the picture becomes more elaborate (below).
Let‘s continue the ‘concert’ case. Throwing away the tickets results in a new object which is identical to the initial object in the life cycle. The new object is the reservation in your agenda, consisting of the same data as the first object in the lifecycle. But it may be clear that in fact this is a different object, a different stage in the life cycle. The difference is not in the data composition, but in the context. The first object has its date and time before the current moment, in the last object the date and time of the concert have expired. This example shows that discerning a life cycle object can be context dependent.
It is not useful to split up data elements into the highest level of detail. For example the Christian name, family name, street, house number and town can be lumped together for sake of simplicity to form only one data element. If necessary this big data element can be split up later.
One process may have different primary objects, depending on the observer. An example is the healthcare process. From the point of view of a doctor, the primary object is the patient. From the patient’s point of view, the primary object is his problem. These objects are basically different because the patient has another collection of data than the doctor. It can be interesting to model the different points of view. Van Rees has worked out an approach based on relativity (Van Rees, 2006).
Figure 13 Relativity. Lifecycle of the primary object in the healthcare process seen by the patient (above) and by the doctor (below).
Closely related to relativity is an approach based on perspectives, such as applied in the management instrument GEA, General Enterprise Architecturing (Wagter, 2009). For instance, from the personnel perspective not the primary process, but the lifecycle of an employee is relevant.
In general an interesting exercise is to use Data Metamorphoses from the point of view of the client. What is the object lifecycle seen by the client, what is important to him, how can we best facilitate him? When your organisation is implementing portals or is busy with chain optimization, doing Data Metamorphoses from the point of view of externals is a nice approach.
ArchiMate’s business layer is characterized by its external orientation whereas the application layer is characterized by its supportive character, according to the ArchiMate Foundation (Bosma 2005). The business layer may change without affecting the service offered to the environment. In a similar way the application layer may change without affecting the business layer.
Data Metamorphoses, as modelled hitherto, takes place at business level. When it is useful to investigate or implement different business processes keeping the information flow unchanged, the object lifecycle can be raised from process to service level, see the figures 14 a and b.
In figure 15 alternative applications are shown in a steady object lifecycle.
Figure 14a Lifecycle change in a layered model. The vertical flow up is process A providing services to an external role/actor. The horizontal flow is the object lifecycle.
Figure 14b Lifecycle change regarded as a service (oval ‘process A’), leaving room for alternative implementations on business level (processes A1 and A2).
Figure 15 Alternative implementations on application level, with ‘Application service A’ and the business layer remaining unchanged.
A classic layer view is achieved by putting subsequent figure 15’s next to each other, yielding figure 16.
Figure 16 Intake process at institution for mental healthcare Rivierduinen, derived from analysis of the patient’s object lifecycle.
Business objects (business layer) are mirrored in representations (business layer) and data objects (application layer). One business object is represented as one or more representations and one or more data objects.
A process in the business layer realizing a lifecycle transition is mirrored in the application layer as a service which may copy data; for instance when a patient is registered patient data is copied from a registration form to the system.
For a practical situation see figure 17, which has been recorded at Rivierduinen, an institution for mental healthcare in Holland. A referral comes in by fax and is enriched by the fax apparatus with the sending fax number, date and time. This is the first transition in the life cycle of a patient, seen from the hospital’s point of view. The next step is preregistration; this is registration of the received referral into the system.
The application services act as data transfers on application level. Data transfers occur from paper to paper, from paper to an application, from application to application etcetera. Metamorphosis is an excellent way to collect an inventory of data transfers; read and write, as well automated as manually. Just look at the application services to specify your Enterprise Service Bus.
Figure 17 – A practical example of layers and lifecycle at Rivierduinen. The business layer is green, the application layer blue. Note the business objects and representations at business level, reflected as data objects on application level. Application services copy data from one medium to another.
A concise version of the Data Metamorphoses metamodel is given in figure 18. The recursive arrow ‘generates object’ refers to the object lifecycle. ArchiMate lacks this arrow.
There are some variations:
Data elements, here given as objects, also can be drawn apart from the object.
A process can be split into a business service and a process, see figure 14.
Figure 18 Data Metamorphoses metamodel.
An object in Data Metamorphoses is a collection of data elements. It is up to the architect or analyst to discern different object states according to the relevance of making difference. What is used to call ‘object state’ is simply an discernable object because of a difference in data elements.
A data element is seen as a low level object which can be split in more data elements or lumped with other data elements, depending of its use.
Normally an object is discerned by the presence of absence of one or more data elements; for instance a patient has a first appointment. In some situations however the object is characterized by its content. We have seen an example in fig. 8; the content ‘accepted = yes’ or ‘accepted = no’ differentiates between the objects. The next paragraph about management information shows a shift from content to object. Here we see three levels: the general metamodel (fig. 18), the metamodel of management information (fig 19 above) and the management information objects (fig. 19 below).
Management information has its roots in the operational object lifecycles, as shown in the management information ‘metamodel’ of figure 19. In grey an example is given. ‘Dimension’ can be cost center, department, team, time, job title, etc.
Figure 19 – Metamodel for management information. In grey an example is given for a simple report presenting the number of patients by employee for a particular team.
Data Metamorphoses is just an approach which has to prove its use in practice on a larger scale. Compared with other modeling approaches such as ISAC, Yourdon, OO and architectural approaches, Data Metamorphoses is characterized by being focused on the primary object. Its aim is giving a simple view of administrations and underlying reality, based on observations. Results are scalable, expandable and reusable.
Integration of objects and processes is not new. An approach which comes close to Data Metamorphoses, is named Object-Process Methodology (Dori, 2003). Both approaches integrate objects and processes in an object lifecycle and intend to cope with complexity. However, Dori’s methodology is aimed at system development, lacks the focus on the primary object and lacks the empirical approach of observing data.
A weakness of Data Metamorphoses is that in some cases no exact definition is given of all possible objects. For practical reasons several possible life cycle states of an object can be lumped together (figure 10). The resulting structural approach is the earlier mentioned flaw of the classical data modelling, but to a lesser extent. An example: the object ‘patient in treatment’ has a data element ‘medication’. But not all patients in treatment do have medication. This weakness does not appear in a sequential lifecycle such as the standard intake process of a patient. The patient in treatment however has a diffuse lifecycle; here the mentioned weakness is apparent. However, patients with medication can be separated as a different object when this is useful.
A weakness is also that Data Metamorphoses is such simple that it requires a good amount of abstract thinking and administrative discipline to do the modelling. The kind of pictures given in this manuscript is not suited to distribute among outsiders who don’t speak the language ArchiMate. On the contrary the resulting pictures, projected on the wall under supervision of the architect, have proved to be a good basis for giving insight and discussion.
Examination of the integrity of the resulting models is done by going back to the source, i.e. the data elements observed before. It is useful to keep a track record of investigated forms (scans, photos), screens (screenshots, photos) and intermediate results such as spreadsheets.
Business processes become more and more complex. Administrations reflecting those processes become even more complex by increased legislation and demands for more efficiency, quality and control. Data Metamorphoses observes administrations, yielding a relatively simple model. Just this insight is needed in our complex world.
By its factual starting point the approach leads to a judgement whether data is missing (poor administrative quality) or whether there is too much data kept (ineffectiveness and risk of inconsistent data).
The approach reveals possible process enhancements.
Essential in ArchiMate is the distinction of layers separated by services. Data Metamorphoses deals with the business layer and application layer. As seen in fig. 16 and 17 an ArchiMate layered model is derived in a natural way from the Data Metamorphoses approach.
The tool Architect has not been developed for architecture based on detailed observations. The result is a quite artificial use of the ‘representation’ symbol. This symbol is used for all data presented to the user, not only forms, but also screens. An alternative for representing screens is ArchiMate’s ‘application interface’. For sake of simplicity one presentation symbol has been chosen.
ArchiMate lacks a ‘composition’ arrow between the representation symbol and the data element. However, the ‘association’ arrow can be used to make clear that form X contains data A, B and C.
ArchiMate does not provide a lifecycle arrow as drawn in figure 1.
Architecture is associated with creativity. A creative job is well appreciated in society. Unfortunately the Data Metamorphoses approach must avoid any creativity because it deals with observing factual data. Creativity is restricted in making a few choices such as ‘which primary object will we investigate’, ‘which picture is useful?’
However, in analyzing the IST, ideas originate to improve processes and information flows. In analyzing the process mentioned in figure 18 a lot of issues bubbled up such as ‘why do we need a registration form?’, ‘can we skip the preregistration and shorten the process?’ Data Metamorphoses stimulates good creative thinking and provides this with a solid basis.
There are a lot of architect and analyst titles: information architect/analyst, business architect/analyst, enterprise architect, and so on. Data Metamorphoses unifies information and business, so erases the distinction between business and information architect.
Data Metamorphoses characteristics:
Data Metamorphoses products:
Added value of Data Metamorphoses:
1 Preregistration: registration of a received referral
2 The language ArchiMate was used in the schematics whenever possible