Combining Object Oriented Process and Information Models in the Design of Co-operative Systems for an Area Health Authority

A project-known as the Integrated Cooperative Workspace (ICW)-sponsored under the DTI/EPSRC Computer Supported Cooperative Work (CSCW) Advanced Technology Programme involves the Sheffield Area Health Authority as a demonstrator site for the technology and methods being developed within the project. The Integrated Cooperative Workspace (ICW) project * is researching the issues involved with computers supporting cooperative work (CSCW) in enterprises, and developing integrated methods and Open Standards-based software tools to facilitate this. In this paper, we explain the business issues which provide the rationale for ICW, and describe each component of the ICW methods and tool sets, and the way the components fit together, from a business perspective. We report on the approaches developed within the project, which employ Object-Oriented extensions to Information Modelling techniques, allied to Object-Oriented Process Modelling and an Enterprise Information Service. The notion of 'Three Views' of an organisation: being an Information view, a Process view and a Human Resources view , operating within a User-Centred Incremental Development Route is described. We situate the discussion in the context of a specific application, supporting collaborative management work in a Health Authority. Brainstorm) and two Universities (Sheffield Hallam, City), and is running over two years, from September 1993. It is a £1.


Introduction
Current CSCW applications (Rodden 1991) such as electronic mail, and workflow systems, are effective, but restricted, in that they often provide limited functionality, or a restricted work environment -for example a local area network.The Integrated Co-operative Workspace (ICW) project is engaged in research into the use of IT to support enterprise-wide co-operative work and in developing integrated methods and Open Standards-based (Brockschmidt 1994, Steedman 1993, Lynch 1991) software tools to facilitate groupwork (Cook et al 1991).ICW methodology relies heavily on the Object-Oriented approach to systems integration, development and implementation.
The aim of the ICW project is to push CSCW towards a central position in the organisation of large and complex enterprises by extending the range, integration and reach of groupware applications.In the realisation of these goals, the following are likely to be crucial factors for business success over the next decade: • The ability to manage change in a coherent but flexible way as an integral part of the operation of the enterprise.• The ability to accommodate increased blurring of organisational boundaries.This might be seen in closer collaboration with external organisations (customers, suppliers etc.), or even in single large organisations being replaced by co-operating constellations of smaller organisations.• The ability to operate with less hierarchical and more flexible team structures and processes.The hope will be for an 'empowered' workforce while retaining business coherence and an appropriate degree of control.• Wide and effective shared access to contextually-situated information.
ICW aims to provide support for enterprises facing these challenges by bringing three complementary perspectives together: • Process: the activities that make up the business of the organisation.
• Information: including 'soft' information; document management.• People: the individuals, groups, roles and skills involved.
Open standards are employed, which helps to ensure that applications can be extended over diverse, distributed environments in large organisations and also facilitates the integration of CSCW with enterprises' core and legacy applications.

ICW Overview
A key feature is the close integration of methods and technology, to ensure that solutions are driven by the current and future business needs of the enterprise.The ICW methods framework (Elliot and Steele 1995) incorporates work with stakeholders in the organisation to derive an architecture, requirements and solution for any ICW application.This starts at the level of business needs analysis and works down to the technical components of solutions in a layered, structured way.Information and organisational modelling techniques have been and continue to be integrated with ICL's extant and evolving Process Development Methodology (Warboys 1989).Figure 1 illustrates the overall ICW methods and architecture.

Enterprise-Wide Open Standards
Other Services

Business Analysis
Technical Support

Matrix of organisational culture and personal relationships
Figure 1: ICW Overview The core technologies which are being developed and integrated are: • Process support for people and applications working together.
• Document management, retrieval and imaging (based on the Oracle Relational Database Management System) • An Enterprise Information Server and Browser, acting as a transparent intermediary to diverse sources of enterprise information to support applications and people working cooperatively.
These correspond (though not rigidly) to the three views of the methods framework described below.

Methods Framework
ICW methods can be applied to support existing processes and information structures.However, their full power becomes apparent in supporting re-engineered processes and information, and in providing a clearly defined way of managing change.For example, ICL have used the ProcessWise Development method extensively in support of Business Process Re-engineering (Davenport and Short 1990).
It is important to recognise that, given the tremendous variability of the situations to which ICW may be applied, ICW methods are better thought of as a framework into which a variety of specific components and methodologies may be slotted.It provides a set of notations with which to represent the situation (for example an architecture -see below) at each point in the framework.These are designed primarily to allow accessibility for stakeholders in the organisation to understand, reason about, discuss and make decisions about the business and implementation.It also provides a set of methods which may be slotted in at particular points in the framework as appropriate for a particular situation.Although some applications may utilise the whole of the framework, more typically the focus will be on a particular subsection, with some appropriate methods chosen from the range available.
An essential concept is that of an architecture which provides a precise framework within which change can occur.The definition of this architecture can be at a number of levels or layers -each one more detailed than the last.Any given cycle of change may leave the detail in one level untouched, whilst modifying another level -or part of a level -in a way which is described and understood.
ICW recognises three 'views' and four 'levels' (figure 2): The value chain level is concerned with describing systems in terms of the "values" the components contribute to the whole.At this level, consideration is given to "value" properties and how "values" are related in systems without concern for the means of providing such values, or how system components add value.Sometimes this layer may be called the business level.
The abstract level is concerned with describing in abstract terms, not dependent on any particular IT or other implementation, what the components of a solution are, and how they fit together.
The applications level is specifically concerned with describing how the abstract solution may be supported by IT applications.This will relate both to functional IT applications and the use of IT to support the overall behaviour of the organisation.
Finally, the systems level addresses the architecture of the identified IT components to support the required functions and behaviour: including the clients, the servers, the network and so on.
For a full ICW solution, these levels span across three views on the situation (figure 2).These are the process view, which characterises the situation as a set of roles and interactions, the information view, which characterises the situation as a set of related information objects and their attributes and the organisational view, which characterises the situation as a structured set of human and other resources.The three views are situated in a feedback loop, covering the whole project.In deriving and implementing a solution within this framework, the following activities will be involved: 1.
Scoping and focusing the solution to ensure maximum benefits to the business.Determining the desired business objectives and creating the initial solution framework.

2.
Using the business objectives to define the overall architecture and design for the organisation, process and information systems requirements.

3.
Using the business objectives to plan the implementation phases.Identifying the elements to be implemented.4.
Using the business objectives to prepare the organisation.5.
Carrying out the detailed phased specification, design and implementation of each of the successive groups of requirements.Each phase is implemented through from requirements analysis to implementation, followed by deployment or review, prior to the next iteration.6.
Using and reviewing the delivered system or prototype.Providing feedback, new requirements and deficiencies into the next iteration.

Technical Architecture
Just as the methods framework allows us to derive flexible solutions in changing business environments, so the ICW technology (Harvey et al 1994) allows these solutions to be rapidly implemented and modified across a distributed enterprise.The technology lies within an open client-server environment which allows the participating components to interface with each other and with other tools.The primary components are shown in figure 3 and provide: • Document management (IDOC) (Osguthorpe et al 1994) • Organisational information on items such as individuals, roles, resources, locations, workgroups, and their relationships (EIS) (Harcastle-Kille 1988) • Process support for humans and applications working together (ProcessWise Integrator) In what follows, each of the complementary core ICW technologies is described.

Process Support
A key element of a modern organisation is the recognition of the need to understand (and, frequently, redefine) the essential processes and behaviours by which that organisation operates.These processes may be routine (as in, for example, issuing a new insurance policy), but will more usually be a complex system of activity and interactivity amongst the people and systems in which the essential functionality of the organisation is embodied.ICW addresses the issue of supporting such complex behaviours through its process support element utilising ICL's ProcessWise Integrator.
ProcessWise Integrator is based on the idea of co-ordinating the key elements of an organisation (the people, the systems) by explicit support for the interactive behaviours of

PROCESSWISE
those elements in the processes being carried out.In simple terms, ProcessWise Integrator is an IT component supporting the operational business which has knowledge of the various "players" in a process, of the state of the process and of what should happen next.From this position, support is provided to enable the appropriate "players" to carry out the next steps in the process, and so on.The richness of what is meant by these ideas in reality requires an equivalent richness and power in the capabilities provided by ProcessWise Integrator far beyond the simple ideas of a process being a sequence of activities as in typical workflow or document routing applications.
ProcessWise Integrator provides a specialist programming language called PML (Process Management Language) in which the interacting behaviours (the processes) of the elements of an organisation are described.PML is a class-based language with the principal classes being role, entity, action and interaction representing the key concepts to be described.It follows a client-server model with a process control manager server providing the main process support function according to the current PML description.The client components of ProcessWise Integrator are the means by which process support is actually provided to the staff and other systems of the organisation.User interface clients are the link to the staff, whilst application interface clients are the link to other systems.

Document Management
Modern enterprises require a rich network of inter-related informat ion to support their processes.In addition, the processes often consist of the production and transformation of information.This is often 'soft' information, in the form of documents.
To support flexible and creative processes, powerful ad hoc information retrieval and browsing is needed.At the same time, for business coherence, clearly defined information structures and inter-relationships are required.The Oracle IDOC component of ICW provides a toolset to support these complementary requirements.As with ProcessWise, the toolset is specifically designed to support changing organisations and incremental development.With both ProcessWise and IDOC, the precise, structured correspondence between the process or information model, and the system implementation allows the evolving reasoning of stakeholders about their information requirements to be mapped directly and rapidly to an evolving solution.

Enterprise Information
Process and Information Management occur within the context of a complex organisational environment.The Enterprise Information component of ICW provides an object-oriented conceptual framework for the modelling of this enterprise information in a generic manner, and a set of software services that enable new and existing information repositories to be accessed using a common data format.The intention is to make common stores of enterprise information accessible to a wide range of groupware applications both within and independently of ICW.
In the EIS, information is presented in a common format (regardless of its source) to the processes and users that require it.For example, both Process and Document Management applications can access information about the members of an enterprise and the organisational structure of that enterprise from an X.500 Directory Service and an Oracle database, enabling identification of suitable candidates for task performance and information dissemination.This information needs to be stored in only one place, rather than in each application.
Support for integrated Enterprise Information is provided by two software services.

The Enterprise Information Service
The Enterprise Information Service (EIS) is intended to provide uniform access to enterprise information which is stored in a variety of underlying databases.It achieves this aim by converting information to the "canonical data schema", and then providing and integrating the data as required.

The Enterprise Browser
The Enterprise Browser (EB) (ref EB) provides the user with the means to view and modify data comprising the enterprise model -that is, the schemas of the base class hierarchy and the schemas and objects created to represent the particular enterprise.The EB is simply another application that uses the EIS, but through the EIS it allows human users to access, browse and modify the enterprise model, and is thus the users' access point to the EM.

An example of ICW's application
Two 'demonstrator' implementations are central to the ICW project.One of these is in the public administration sector (Sheffield Health Authority), providing support for cooperative management and decision making in a complex networked organisation, the other is in the pensions industry.This paper will now concentrate on the Sheffield Health Authority demonstrator to illustrate the ICW components.

The Sheffield Health Authority (SHA) application
Post NHS reform Health Authorities embody (sometimes in extreme form) many of the challenges and trends faced by management in the '90s.They are relatively small organisations at the hub of a huge healthcare enterprise (involving about 20,000 people and a £350M budget in Sheffield).The reforms impose a requirement on the Health Authorities to monitor healthcare provision, to ensure that it is efficient, effective and equitable.In order to achieve this, SHA must be able to: • Access and apply a vast research and knowledge base concerning the effectiveness of various healthcare services.
• React quickly and meaningfully to a wide range of external stimuli from parliamentary questions to local press stories.• Use quantitative and qualitative methods to monitor and improve health services.
• Analyse and understand the health needs of local communities.
• Mobilise all the skills and expertise of a multi-disciplinary work force.
• Continually re-configure services to utilise new clinical technologies and processes.
SHA's organisational solution to the problems posed by these demands has been to emphasise multi-disciplinary workgroups that go beyond traditional organisational boundaries.Work processes require continual "re-invention" and involve distributing tasks to multi-disciplinary workgroups.Public accountability means that senior management needs to know -often very quickly -what is happening within these workgroups.ICW methods attempt to help implement SHA's operational strategies by supporting: • Management and retrieval of a complex network of continually evolving qualitative and quantitative information.• Flexible management of distributed multidimensional workgroups and organisational structures.• Ability to monitor and manage complex processes.
• Constant organisational and business change.
The SHA scenario chosen as a basis for the ICW demonstrator was circular handling and is described in the following paragraphs.Problems inherent in the processing of circulars are typical to many SHA activities and the scenario poses a well defined problem domain for ICW to use as an exemplar.
Figure 4 shows a dataflow diagram of the paper-based circular handling system.Briefly, the following steps make up the life cycle of a typical circular: 1.The DoH sends the circular (including attached documents) to the SHA indicating that a response is required and the deadline by which the response is required.2. A list is created of x many workers identifying who needs to receive a copy, who needs to respond to the circular and who should lead the response.3. The distribution list is attached to the circular which is then copied x many times and placed in internal post.4. Workers identified as needing to respond to the circular send their response to the response leader.5.The response leader formulates the response document (an amalgam of all the individual responses) and sends it to the DoH.
Many problems exist with the paper-based system and occur to varying degrees.Some of these are outlined below.
The distribution list is inaccurate because the person allocating the circular does not have the required knowledge of worker's roles and responsibilities.This results in: • Circulars being received by people who don't need them • People who need to see the circular being missed off the list • The circular being received more than once by the same worker The response deadline is missed.This may be due to a combination of the following reasons: • An inaccurate distribution list • The length of time it takes to prepare the circular for distribution e.g.log the circular, create the distribution list, copy the circular, send it through internal post etc.
Past circulars are difficult to store and retrieve because: • Copies of the various documents are kept in many stores and are therefore duplicated.
• The main store (the registry) is large and relatively unmanageable  The ICW methods framework was applied to the above scenario in order to improve circular handling in terms of speed and quality of circulation and response.Scoping and focusing of the problem area was performed using the SODA (Strategic Options Development and Analysis) methodology (Eden 1989).SODA involves working (via interviews and workshops) with stakeholders to elucidate their views of the strategic issues facing an enterprise (or a part of it), and the relationships between these issues.The results are represented graphically in cognitive maps.These maps are discussed and reconciled (or not!) in workshops, and used to define ways forward.In this case, the end-point of this was a focus for the application (the handling of Department of Health circulars), and a set of business targets.Having been derived through SODA, the focus and targets had the consensus support and understanding of the stakeholders involved.
Following this, a parallel but linked analysis from both the information and process viewpoints was performed, as described below.This finally led into the implementation of a solution focused initially on information modelling and IDOC, with ProcessWise and EIS support as secondary views on the problem domain.

The Information View
The information value chain level is defined by business goals, and aspects of those goals.In the SHA demonstrator, these were taken directly from the SODA interviews and workshop.
Figure 7 gives a sample of these.
Before describing how this view is constituted, it is important to understand the type of information involved.Here, we are mainly concerned with "soft" information -typically document information, rather than the kind of "hard" structured information or data more usually associated with relational databases.Examples are: policy documents, minutes of meetings, letters, memoranda, books, articles, pictures, photographs, video clips.Although these kinds of objects can be partially described by structured information (date, author, reference number, etc.), their main significance lies not in this, but in the unstructured information (e.g.text, image, moving image) residing in them.Often their significance also crucially depends on their context.For example a letter can often only be understood in the context of a sequence of letters which preceded it, and to which it forms a response.
Information of this kind is generally used in a way which doesn't follow rigid relationships, as users go about their work.Hence, relationships are very much for guidance and support for users in reasoning about work processes, rather than being prescriptive.This is unlike many of the situations supported by traditional data modelling techniques, such as entity-relationship modelling (Benyon 1990).
In this context, the goals of information modelling are not to derive a "correct" data model for a solution, as in a typical data modelling exercise.Rather it is to provide a framework and representation to help stakeholders to analyse their goals.Following on from this, it should represent a solution and allow the relationship between a solution and these goals to be clearly visible.
The information value chain level is defined by business goals, and aspects of those goals.In the SHA demonstrator, these were taken directly from the SODA interviews and workshop.
Figure 5 gives a sample of these.To facilitate relating these to the abstract level, business goals are represented as entities (shown on the left), and aspects of them as attributes (shown on the right).This is refined into the abstract level (shown in figure 6), where the actual information objects and their relationships are defined.Links can be drawn between the Value Chain level and the Abstract level information views indicating which sets or aspects of information are used to meet which business goals.
The notation used to model the abstract level is that of an Enhanced Entity-Relationship (EER) model (Elmasri and Navathe 1994).The EER modelling concept builds on existing Entity-Relationship modelling techniques to include the object-oriented concepts of:

Minimise embarrassment
Influence policy of DoH (etc.) • Specialisation -taking an entity (known as the superclass) and forming a set of subclass entities which are specialisations of the superclass.• Generalisation -the reverse of specialisation.Defining a superclass entity from a group of entities.• Inheritance -subclass entities inherit all the attributes of the superclass entity.
The advantages of using object-oriented models are discussed in the conclusion of this paper.Suffice to say at this point that the application of object-oriented techniques enhances the analysis and design of enterprise-wide systems by (amongst other ways): • Enabling the reuse of models and software modules by different organisations • Producing more reliable and secure software components (through reuse) • Models being more easily understood by business people and end-users • Relating well to business rules and the changing of these rules • Enabling the linking of information, process and organisational views Readers are referred to texts by Martin 1993, for a list of the advantages of object-oriented techniques and Joergensen 1992, for a comprehensive overview of object-oriented information modelling.
Figure 6 illustrates an EER model of the abstract level of the information view.Each lower level entity, or subclass, in the diagram inherits the attributes of its superior entity, or superclass, and all the other classes in the tree branch above it.The levels are denoted by the ∪ set union operation symbol indicating that one entity belongs to a subset of the other.
Entities have attributes, which correspond to the fields of information held for each object of this class.
Rules apply for the membership of subclasses.The circular symbols containing the letter "d" in mean that membership is "disjoint"; for example a member of the library item class can only be a member of one of the subclasses, book, pamphlet or video.In contrast, if a circular symbol contained an "o", this would signify that membership of the subclass is "overlapping"; a member of the superclass may be a member of more than one of the subclasses.We are also informed by the double line ( || ) that members of some superclasses must be members of at least one of the subclasses.For example, a member of the class library item must be a member of book, pamphlet or video.On the other hand members of the class document out do not have to be members of any of its subclasses.
The EER concepts described so far enable the representation of a hierarchical structure whereas in real life information is much more flexible.In figure 6 the subclasses letter and memo are each members of two superclasses and inherit attributes from both superclasses.This concept is known as multiple inheritance and leads to the development of a lattice rather than a hierarchy, providing a more accurate model of the information relationships as they exist within the organisation.From this abstract level, an application level and system level for the information view can readily be derived.These, and the formal relationships between the levels, are not described here, because of lack of space, but they are relatively straightforward.

The Process View
Just as the information view is concerned with entities and relationships, the process view is concerned with roles and interactions.The modelling notation used in the ICW project is that of ICL's ProcessWise Development Method.A role consists of a set of behaviours that form a distinct part of a process and is diagramatically represented by ellipses.An interaction is an exchange between two roles to progress a process.Interactions are represented in the models by lines joining the ellipses.Arrows are used to signify one-to-many and many-to-many relationships, lines without arrowheads signify a one-to-one relationship.The concepts of roles and interactions make sense both at a high level (i.e.Value chain level as shown in figure 7), and a low level (i.e.Abstract level as shown in figure 8).
The value chain model is formed in terms of roles and interactions as shown in figure 7.This shows both the relationships between organisations and a grouping relationship, where common elements are contained within an outer diagram.For example, the NHS providers, Voluntary organisations, Non-NHS providers and general practice are all organisations which implement an 'improve health' relationship between SHA and Sheffield Residents.Clearly this represents an extremely high-level view of SHA's business.However, it provides an indispensable "grounding" in the core business objectives of the enterprise.From this, we can progressively "zoom in" on components, providing more detail, until we arrive at a detailed description of one process, such as that shown in figure 8, which depicts one small part of SHA's role and the SHA -DoH interaction.This figure provides an abstract level description in the form of a role-interaction diagram which identifies actual staff functions and interactions concerning the chosen 'circular handling' processes.It can be linked directly back to the core business objectives, for example providing crucial insights into whether the process actually contributes to core business success.The following paragraphs describe the processes involved at the abstract level of the planned computerised circular handling system.
The cataloguer role receives circulars from outside the SHA and is responsible for storing the circular and its catalogue information in the electronic library, and also notifying the distributer of the circular's presence.
The distributer is responsible for allocating a circular to the appropriate people in the Authority.Access is required from the library for information regarding the circular (and potentially for other information).The distributer determines who in the Authority should be responsible for coordinating any required response (the response leader), who else would be expected to contribute (worker) and who might be interested in knowing about the circular (also worker).Once this set of people has been identified, the distributer notifies the individuals concerned of the circular, related material, and the set of identified people (i.e. the members of the circular distribution list).
The response leader and the set of workers form a work group concerned with handling the circular and with producing any necessary response.These roles have access to the library for information about the circular and anything else they might deem appropriate.They interact with each other as a work group.The response leader may produce a response to the circular if this is required.Deadlines will be established for pieces of work to be carried out and these The next step in creating the process view would be to expand each role to model the system level of the circular handling process.This would show the various software and human components which make up each role.Lack of space in this paper means that they have not been included, however they can be found in Snowdon et al 1994.

The Organisational View
Currently, the abstract, application and system layers can be expressed in terms of the Enterprise Model utilised by the Enterprise Information Service.Alternatively, in a processfocused implementation, the ProcessWise Development Method provides for an organisational model.However, it is felt desirable to add further depth and linkages to such representations, and it is hoped to address this issue in the latter part of the project.

Linking the Information View and Process View
The three views of an ICW application; information, process and organisational correlate at each architectural level.In this section we explore how Process Models and Information Models map onto each other at the abstract architectural level.
EER models can be created for the process and organisational views in addition to the information view.There are three top level superclasses, information item, role and person representing each ICW view; • Information Item Ð information view • Role Ð process view

• Person Ð organisational view
Figure 9 illustrates these superclasses and the relationships between them using the standard Entity-Relationship notation.An role entity, for example, is played by a person entity.effectively showing the information used by each role.It also specifies whether the links are active (the information is transformed by the role or interaction) or passive (the information is necessary for the performance of the role or interaction, but is not modified) by the create action and read action labels.
It is interesting to note that the person and information item entities cannot be mapped in this manner because the access a person has to information is dependent on the role he or she is playing at the time.There now exists a set of mappings between the role and information type entities, which can be extracted and modelled in the context of role-interactions, as shown in figure 11.We can show the interaction between role pairings in terms of the information which is used in the working relationship.For example, the distributer and worker interaction is facilitated by circular information, whereas the response leader and worker interaction operates on response information.Additionally, interactions with the outside world are included to show where the circular came from and where the response is sent to (i.e. the DoH).The role-interaction diagrams in figure 11 can be combined into a single diagram (such as that shown previously in figure 8), expanding the detail to show components of the information where they are particularly relevant.The changing state of the circular as a result of processes performed on it is more obvious when detailed in its constituent parts.For example, it can be seen from figure 8 that the circular begins as a hardcopy document, is then converted to an electronic document by the cataloguer and annotated with a distribution list by the distributer.

N.B., the arrows signify a one to many relationship and not the direction of the information flow
The matching of roles and the information items processed by role interactions can also be accomplished when beginning with a Process Model, i.e. one model can be extracted from the other.It is also useful to compare models which have been created independently of each other to check that they correspond.Within the ICW framework this occurs at each of the four architectural levels.

Conclusion
Health Authorities, like other organisations, have a set of business goals which must be achieved if they are to succeed.An understanding of these goals is crucial to information systems design, particularly in the development of enterprise-wide systems.
The application of abstraction is extremely useful in gaining an understanding of business goals.Use of object-oriented methods in the ICW project enables more accurate and useful levels of abstractions to be modelled at each of the four architectural levels.Further, they allow for the integration of process and information views, providing a richer base for the analysis of an organisation's information processing requirements.At a high level of abstraction business share the same set of business rules.Object-oriented modelling of business rules enables the re-use of the models by different enterprises.For example, the components of process, information and people can be said to be the basis of any organisation.
Object-oriented models provide a good basis for the mutual understanding between the information system professional and the user (be they actual users of the system or indirect users) because: • Users can relate to object-oriented concepts because they think in terms of events, objects and business policies that describe the behaviour of objects (Martin 1993).• The appropriate level of detail can be modelled, hiding all irrelevant information from the user.• Scenario situations can be easily modelled allowing for changing business goals, i.e. "whatif?" questions can be asked.
It is important to recognise that the ICW Methods Framework is not tied to any particular technological implementation, rather that the principle of platform independence is a paramount objective.

Figure 5 :
Figure 5: Information view: Value Chain level

Figure 6 :
Figure 6: Information view: Abstract Level

Figure 7 :
Figure 7: Process View: Value Chain level

Figure 8 :
Figure 8: Process View: Abstract level of the information associated with the circular.It is the responsibility of the various individuals in the Authority to note these deadlines and to work to meet them.

Figure 9 :
Figure 9: The three top level ICW superclasses

Figure 10 :
Figure 10: Information item and role mappings.

Figure 11 :
Figure 11: Role interactions for SHA circular processing

Strategic Analysis (including scoping and focusing) Information Process Organisational Structure Implementation Feedback Business Drivers Value chain level Abstract level Application level System level
• It is difficult to retrieve a circular without knowing the title or reference