# Capture the Current State

Gregory Uppington

► To cite this version:

Gregory Uppington. Capture the Current State. 4th Practice of Enterprise Modeling (PoEM), Nov 2011, Oslo, Norway. pp.162-177, 10.1007/978-3-642-24849-8_13. hal-01572386

HAL Id: hal-01572386

https://inria.hal.science/hal-01572386

Submitted on 7 Aug 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Capture the Current State

Dr Gregory Uppington

YouSoGetMe Pty Ltd

The paper describes the evolution of an enterprise engineering / architecture approach and solution through three case studies, emphasising the contributions of lessons learnt from each case study to this evolution, each presented with results used as input for refinement. The decade of experience with what could very much be dubbed 'enterprise modelling', the extent of the effort combining frameworks and methods to model and capture the current state of the enterprise, and the apparent maturity (if only in practical terms) of the 'solution' is well described and it is easy to follow the advancement throughout the entire process. Along the way the author has ran into a number of known, quite formidable challenges in the field of business analysis and enterprise engineering. The case studies focus on practical orientation and highlights lessons learnt for each step. The paper results in an interesting and detailed conclusion.

# 1 Introduction

Corporations, institutions and others competing in the global economic and trade environments require organisational efficiency to survive. Understanding of the enterprise is therefore essential for management to connect and combine people, processes, systems, and technologies to ensure that the right people and the right processes have the right information and the right resources at the right time. While there are many ways to deliver this understanding, this paper describes how a web-based solution called 'the Company Bookshelf' combines enterprise engineering and architecture (EE/A) with business analysis to address some of these challenges. From the model first developed in 1998 alongside the Generic Enterprise Reference Architecture and Methodology (GERAM), the Bookshelf has not been implemented in any organisation yet as the time has been spent profiling organisations, hospitals and government departments, gauging how the solution meets their requirements, assessing how the solution solves common organisational problems, and seeing how it compares to other systems. The approach, frameworks and the Bookshelf have been re-thought and refined through many scenarios in local, national and multi-national organisations, both real and virtual, however this paper presents only three of the case studies. The Bookshelf has its foundation in GERAM, and utilises the Generic Reference Model (GRM) - a model based on the Federal Reference Architecture (FEA) Reference Models (RM). The author believes automating the GRM through a web-based system creates an EE/A solution suitable for the majority of organisational forms, particularly government institutions. Whilst the aim of the research in 1998 was to provide a design-model for multi-national corporations (MNCs) involved in a Keiretsu, the Bookshelf has since evolved into a solution that captures and
shows the current state of an enterprise (what each part of the company does
and uses). Of more significance to the author are the challenges that had to be
overcome during the course of its evolution:

- How to represent and capture the enterprise: the practical significance.

- How to use what was captured: the transferability of results.

The author believes the approach used to overcome these challenges have
evolved enough to become a suitable and mature solution intended to benchmark
industry best practice, and make the solution suitable for most organisational
forms.

## 2 The Results: Using what was Captured

The second challenge (how to use what was captured) is provided first as the screens show how the frameworks are held within the solution. The Business Screen in figure 1 shows the business view of 'using what was captured'.

### 2.1 The Business Information

Whilst there is nothing remarkable about this screen, it shows the organisational
hierarchy. The authorised user enters the different descriptors of each level, and
names their business entities at each level. On the Business Screen of the Book-
shelf, the user selects the Architecture Office in circle 1.

<figure><img src="image_2.png" /><figcaption>Fig. 1. the Business Screen</figcaption></figure>

Each business area on each level usually has one management position, and
two purposes:

- Purpose A: to provide its products and services,

- Purpose B: to manage itself, so it can achieve purpose A (Bernus, 1997).

The functions (shown on the tabs of circle 3) are one of two types:

- The 'product and service' (PS) business-functions (2a), or

- The 'management and control' (MC) business-functions (2b).

The tabs in circle 3 are the names of the business functions, provided by the
business area selected in circle 1 ('Architecture Assessments' function). When
the user selects a function, they are able to view its' processes, and tasks (circle
4). The user views (circle 5) documentation, templates, artefacts and information deemed important for the task by the actors responsible for that part of the business, within its' context, shown in figure 2. These results are useful when

<figure><img src="image_3.png" /><figcaption>Fig. 2. *Resources of the Task*</figcaption></figure>

the organisation gives authorised access to their areas of responsibility, then new
executives, managers and employees coming into the organisation could become
functional earlier and contribute to its revenue much faster. This practice (called
on-boarding) significantly increases productivity rates and throughput, decreases
coordination costs and employee anxiety by permitting employees to identify
with their new employer and understanding the company's values and priorities.
The Profile Screen in figure 3 shows how the Bookshelf 'uses what was captured'
in a different manner, showing an 'EE/A profile view' for a selected part of the
business.

## 2.2 The Profile Screen

The solution extends the Business, Information, Application, Technology (**BIAT**) view from the Australian Government Architecture (**AGA**) to show a profile of a business area, its people, processes, technologies, and (hard and soft) information to management and executive stakeholders. This BIAT is a commonly used perspective in government departments in Australia and the AGA forms the foundation for many key initiatives such as e-health and enterprise transformation. The AGA is based on the FEA. In the Profile screen the user selects a part of the business or a function, process or task in circle 1, and then selects what they want to see about it in circle 2. The example in figure 3 shows the details of the information systems used by the Architecture Office. The user has selected to see current-state details about the integration overview document, the user devices, the infrastructure pattern, and the non-functional requirements of the SOE, in the context of the Architecture Office. Whilst this seems quite straightforward, this lets the user view any item of description of any architectural element about any application used by the selected part of the business, and about any part of the business. The author applies the BIAT domains where each domain is subdivided and categorised to hold relevant information. The objective of the Bookshelf is to allow organisations to capture the important details of their enterprise from the organisational structure down to specific processes while showing the interconnections between the components of the enterprise. This baseline profile of the enterprise is a current-state snapshot showing the
<figure><img src="image_4.png" /><figcaption>Fig. 3. the Profile Screen</figcaption></figure>

work done in each area of the business and what resources (documents, info,
roles, systems, technologies, networks, etc.) are required. The aim is to use one
system that knows the current state of the enterprise information, so you can
capture it once and use it often in other systems. This profile perspective was
created during the first case study, and addresses the challenge of how to capture
and represent the enterprise.

3 The Background Experience

The approach used to capture the current state of the enterprise stems from the
authors related work in the Globeman 21 (GM21) project. The GM21, started
in 1994, was a part of the Japanese IMS (Intelligent Management Systems)
program till mid 1999 (Bernus 1999). Participants were:

* Twenty industrial partners including Toyo Engineering Corporation (TEC), Hawker de Havilland, Toyota, Mazda, Omron, NCR Norge, Mitsui Engineering & Shipbuilding, and Newport News Shipbuilding;

* Eight research institutions including Fraunhofer Institute, CSIRO Australia, and Japan Institute of Industrial Science; and

* Six universities including Griffith University (Australia), University of Toronto, University of Tokyo, and University of Virginia and Helsinki University.

The GM21 was an industry-led project for product life-cycle driven plant en-
gineering and demonstrated the application of life-cycle architectures to large
scale enterprise engineering for virtual enterprises (VE)(Bernus 1999). Together
with others, the author created the model showing the design of all organisations
involved in a multinational Japanese Keiretsu.

The model identified each relevant enterprise business entity (EBE) of each
organisation involved in the Keiretsu, the key part each EBE played, their re-
relationships and feedback loops with other EBEs, and the elements within each phase of each EBEs design. This was called the **VRIDGE** model (Virtual and Real Information Technologies Driven Global Engineering) and gave a logical place-holder for any activity, document, artefact or information from any phase of architecture, design or operation for each business entity (Bernus et al, 1997).

## 4 Early Aims of the Solution

From engagements to provide EE/A understanding of enterprises between 1998 and 2003, the author found nearly every project began with analysis of the current state. Unfortunately after a number of engagements, the author had difficulty remembering precisely which document had the right information about a selected part of the business, where it was, and its status for each project. The author was looking for a system that showed the current state of the enterprise, where the information was always current. To solve this issue, in 2003 the author created the first version of the system which held the VRIDGE model. The system provided empty electronic placeholders for each phase of the design of the business. This version helped capture, organise and manage the complex information for a large-scale business transformation for a telecommunications company, but it had a number of issues. As part of the analysis, the author found many applications and systems that could show one or more representations of the organisation in its own way (Uppington, 2011), but the only 'system' that could be used enterprise-wide, and hold all different descriptions of the enterprise was the classic 'one-large-folder' on a corporate drive, usually subdivided by division and then by project or business area or both, and hardly ever life-cycle managed. In 2005 the author designed a mockup solution to capture and present the current state description of each business area of an organisation in its correct context, using the language of the business, to accept information and artefacts created by any other system, feed information to other systems, be non-proprietary, affordable, and keep the information current and applicable, and easy enough to use. Product comparisons at the time let the author discover there was no solution that satisfied the above requirements, let alone be affordable and understandable for a cost centre director and their employees to use easily; and decided to build one. During engagements for MNCs, the author used GERAM to provide the life-cycle phases of enterprise design, showing how the phase outputs fit into a hierarchy of the business area. Each enterprise design phase produces documents describing the relevant parts of the business, and the management, strategies, business processes, information, applications and technologies for each business area. Figure 4 shows the outputs of each life-cycle phase for any entity. The information within these outputs usually describes the resulting EBE, and belongs to a single domain of description. For example, the Mission Statement of an entity is a document that belongs to the Strategic Domain of that entity. This hierarchy is noted as the domains of the Generic Reference Model (GRM), used to overcome the first challenge: how to capture and represent the enterprise, and was identified during the first case study.
<table><caption>Fig. 4. Influences on the Generic Reference Model</caption><thead><tr><td>GERA Life-Cycle Phase</td><td>GERA Life-Cycle Phase Outputs</td><td>Enterprise Business Entities</td><td>Domains of the Generic Reference Model</td></tr></thead><tbody><tr><td>Identification of the EBE</td><td>Strategic EBE details, PS &amp; MC details</td><td>Highest level EBE, customers, Suppliers, buyers, ...</td><td>Strategic</td></tr><tr><td>Concept Phase</td><td>Enterprise MVI, Policies, identification of sub-EBEs, PS &amp; MC details</td><td>Branch (1st subdivision)</td><td>Strategic</td></tr><tr><td>Definition Phase</td><td>Strategic details of each EBE, PS &amp; MC details</td><td>Department (2nd), Division (3rd), Cost Centre (4th), Program (5th)</td><td>Strategic</td></tr><tr><td>Design Phase: Functional Design</td><td>Details of functions of each EBE, PS &amp; MC details</td><td>Each Program EBE</td><td>Business</td></tr><tr><td>Design Phase Detailed Design</td><td>Decomposition of Functions to Tasks, resources, roles, artefacts, etc of each EBE</td><td>Each Program EBE</td><td>Business, Business-info, Application</td></tr><tr><td>Construction and Installation Phase</td><td>Business and Technical Architecture, change mgmt artefacts, etc of each EBE</td><td>Each Program EBE</td><td>Business, Business-info, Application, Application-info, Technical, Network</td></tr><tr><td>Operations Phase</td><td>Business and Technical Operational detail of each EBE</td><td>All EBEs</td><td>Business, Business-info, Application, Application-info, Technical, Network</td></tr><tr><td>Renewal, recycle or Disposal Phase</td><td>Business and Technical Change management details, projects</td><td>Any EBE</td><td>Change Management of every domain</td></tr></tbody></table>

# 5 Practical Significance 1: Represent the Enterprise

Case study one was the catalyst for defining an approach and a perspective that could profile each part of the business as an entity, using a generic model in a consistent and measurable manner.

## 5.1 Case Study One: Healthcare Enterprise A

The organisation involved in the first case study was a government healthcare department. Its structure followed the shared-model concept where some ICT support is provided by one division for most other divisions. The hierarchy of the department had four levels of management from the CEO (highest management level) to the director of each cost centre (second management level). The sub-hierarchies of each cost centre differed with some having extra levels of management between a director and employees. The enterprise architecture (EA) function was provided by a single division to all other divisions. This division was managed in numerous directions by successive directors. All artefacts and documents were kept in the classic main storage folder on a corporate drive organised first by division then by folders and then accessible to selected employee levels only. This information-management model proved to be cumbersome and difficult particularly when sections of the storage folder belonged to disparate divisions conducting projects on the same areas of the business. It was evident that knowledge of the current state of the enterprise was largely expert knowledge. Most documented information could not be confirmed as current due to overlapping projects. When areas of the enterprise changed as a result of a project, not all other areas knew of the change. At this time the author decided to define the organisations' EA framework to show each part of the enterprise. The definition of the EA framework resulted in an approach that could apply the BIAT framework onto each business entity on each level of the existing organisational hierarchy. This provided an orthogonal view of EE/A and gave a way for enterprise projects to be assessed for their degree of impact in the BIAT domains for each business area involved in the project. The approach could be applied to
each entity in a consistent and measurable fashion due to the identification of
each function type, described below.

**5.1.1 Identifying the Enterprise** GERAM identifies a number of definitions of the enterprise on numerous levels of abstraction (Williams and Li 1999). It has been found that each business area on each level of the organisational hier- archy is a strategic EBE with its own performance requirements, objectives and drivers (Kaplan and Norton, 1996). GERA supports the EBE can be any part of an enterprise: a multinational corporation, an organisation or government de- partment, a division, a branch, a small-medium business, a cost centre, office, a business unit, team, or a program (Williams and Li 1999). Each EBE can be po- sitioned on the organisational hierarchy where each subsequent level represents a lesser authority (Clark and Thrift 2005). Therefore using GERAM we can say each business area on each level of the hierarchy is an entity. Successful man- agement of a business entity should include planning and measurement. Because planning is strategic in nature, then each management entity has its own strate- gic domain. The author used the FEA PRM to position the strategic elements of each management entity, showing where its measurement was applied. Since each entity had a strategic domain, the author stacked the AGA BIAT domains underneath it to form a profile for each entity. Whilst the approach was correct, the mistake uncovered a few years later showed there was not enough distinction between the functions of a Management and Control (MC) entity, compared to those of a Product and Service (PS) entity.

**5.1.2 Identifying the Function Types of each Entity Type** The GERAM approach gives structure to each business area of the enterprise, to identify the MC entities, their strategies, management functions, systems and technologies used; and the same for the PS entities (Bernus, et al, 1997). Whilst this may seem trivial, the distinction is useful when describing the functions of each type of entity. The organisation is the sum of its entities and most entities provide (A) some form of product or service, and are (B) managed to do so. On closer analysis, it can be seen that each entity on each level of the enterprise hierarchy is managed (B), but the products and services (A) of any entity on any level are only provided by the functions of a cost centre belonging to that level. In short, managers perform mostly management functions for each hierarchy level, and employees perform mostly product and service functions at the lowest hi- erarchy level. This understanding was important for designing the interface in figure 1: the Business screen above, as selecting 'Level Management' presents the MC functions of each layered entity in the hierarchy; and selecting 'Prod- ucts/Services' presents the PS functions of each nested entity in the hierarchy.

* If the user selects an EBE (a Branch), and selects the Products / Services (2a), then the solution will show all Products and Services (PS) functions for all Cost Centres within the Branch.

* If the user selects any EBE and selects Level Management (2b), then the solution will show the level management (MC) functions for the selected EBE on that hierarchy level only.
This captures the organisational hierarchy and separates the functions of the MC entities from those of the PS entities. The MC functions are used for reporting the performance, while the PS functions are used for providing the performance. The author relates these to the FEA Performance RM and Business RM.

**5.1.3 Identifying the Hierarchy of Functions** The function has a hierarchy from its highest level: function, to its lowest level of decomposition: task. The task has a single human role, numerous resources attached to it, can be described but cannot be subdivided. Even if the task is known by many other names, it is still grouped with likewise tasks into a process, which are grouped further as desired. The function name is the connector of the task to the entity which manages it. The hierarchy of the function is important because:

* the PS function is performed by the lowest level PS EBE, which is an entity and is managed;

* the task is a part of the function, and is performed by a person;

* functions are described differently than tasks, which are again different to process descriptions;

* the business information and information system are used by the task;

* the application-information is connected to the information system.

The functional hierarchy is identified because it is where the business processes are described and held. Because of this, the author allocated the functional hierarchy and its contents to the Business Domain. The information, applications, technology and networks were seen to be in place because of the business processes, and therefore were layered underneath the business domain.

**5.1.4 Results of Case Study One** The paper-based EA framework was accepted by the authors director who was unfortunately removed from office before implementation. The new broom swept clean and it was never discovered if the approach was correct or not. These following results were found some months later when designing the system for the approach and numerous frameworks to work together:

* The approach captured each part of the enterprise, but unsuitably mixed purpose A and purpose B together. A way was needed to more clearly recognise and portray the difference between management and employee functions, and to identify those roles and their scope of influence.

* The solution needed to capture the hierarchy of the enterprise, and be able to change any name or description of any of its levels.

The approach was extended to include these findings, and was tested in manufacturing and service organisations which focused on capturing the part each business area played in projects, and gave additional findings:

* a way was needed to capture each project schema, and to map it to each entity involved in the project, thus creating the timeline,

* a way was needed to map each project artefact to where it resides in the enterprise profile, and

**5.1.5 Functional Subjectivity** The author found the grouping of related activities on selected hierarchy levels is subjective and according to the desires of
its creator regardless of whether the function is made up of one or many tasks. In case study one a process-model seven layers deep was re-organised to a four level hierarchy. This showed the author the functional hierarchy for MC and PS functions can be the same because their representation is subjective. There are numerous names for each level and a different number of levels of decomposition for each function in some organisations. This proved to be a key difficulty in achieving process standardisation and interoperability between business areas in case study one. However because the layering is subjective, and the function always has a highest level (function) and a lowest level (task), the author suggests using four levels because the basic tenet for standardisation of most things is to standardise its representation. Identifying the grouping and layering of items into levels as being subjective allows the Bookshelf to use one interface for the organisation to standardise their functional-hierarchy levels, and then for each business area to complete the details. In this way a Keiretsu involving numerous contractor SMEs and one main guiding MNC can create their own four layer pattern for interoperability purposes. The approach and the solution were re-worked and refined to include these requirements in a web-based prototype. The prototype was used in case study two by other researchers as the base to create industry specific programs. The author has drawn on their published articles and his own experience for the second case study.

## 5.2 Case Study Two: Multinational Mining Enterprise

The second case study was to use the prototype in an organisation where architecture was a topic confined mainly to the IT Department. The prototype was tested and verified against stringent business requirements:

1. Capture all entities of the organisation.

2. Give management a view of the business areas they were responsible for.

3. Map the entities impacted by projects before the project begins.

4. Create and manage the architectural domains, their multiple frameworks and artefacts (models, templates, assets and other forms of documents and deliverables, their version control, check in / check out, and life-cycle management functionality), and programs of work (assignment of subordinate projects, roles, tasks, activities and steps).

5. Manage programs, projects, roles, resource utilisation, and performance.

6. Create and manage a workspace allowing each user various views per role.

7. Automate and integrate the TOGAF framework into the operations of the enterprise by pre-populating EA frameworks (TOGAF) and their document repositories for various workgroups based on their project type, and allowing management review of all project requirements including roles, artefacts and other resources against milestones and critical review points.

8. Map similarity between artefacts, helping achieve standardisation.

9. Help manage the delivery of programs and their projects, including task management and status.

### 5.2.1 Results of Case Study Two
The prototype satisfied the business requirements. It correctly mapped the business functions occurring in the different
levels of the organisation, and allowed local naming so as to be suitable for all ar-
eas and domains of the enterprise. However, through discussions some additional
findings suggested some desirable changes.

1. Stakeholders preferred variants of the information depending on their role.

2. Each actor wanted to use their own words and methods to map more naturally their work protocol, and for information to be communicated in a form appropriate for them.

3. A preference was expressed for information to be viewed per area of responsibility (programs, projects, and geographical areas), and for responsibility to be viewed per domain in relation to those EA items that would change consequent upon an event in a project on any part of the EBE.

Unfortunately the researchers report the lines of communication between techni-
cal and business personnel were not amenable to productive debate. There were
strongly held, incompatible views of the architecture function and progress de-
pended upon *how useful the line business units find [EA] in supporting the busi-
ness run initiatives and how well they are able to maintain and upgrade core EA
assets (global EA Governance Framework) and communicate them in a timely
and effective manner* as described by Turner et al (2009) *there was confusion or
*misunderstanding as to where all key architectural artifacts reside*. Case study
two showed the prototype was deficient and a refined approach and solution was
developed. The solution was holistically redesigned allowing for modular inter-
operability, numerous existing functionalities were refined and simplified, some
were removed and some added. The solution had to be usable by most employ-
ees, provide relevance as perceived by internal factions, and allow each in-house
expert or SME to express their expertise.

5.3 Case Study Three: Healthcare Enterprise B

The third case study spent a year verifying (but not implementing) the Book-
shelf with a multi-campus healthcare organisation where the design, operation
and understanding of architecture was a topic easily discussed by numerous di-
visions and departments, just using different names. The enterprise structure
followed the shared-model concept where nearly all ICT support was provided
by one division for all other divisions. The hierarchy of the organisation had
four levels of management from the CEO (highest level) to the director of each
cost centre (second bottom level). Each EBE had consistency in the number of
management levels within each cost centre. This provided uniformity within the
enterprise and how it managed its numerous layers of customers and clients. Ar-
chitecture was seen by the enterprise as complex, but able to be organised and
controlled largely due to the efforts of its information division. The dominant
ethos within this division was aimed towards effective internal communication for
the successful management and refinement of the delivery of services to the busi-
ness, so the business could deliver its services. Knowledge of the current state of
the enterprise was expert knowledge openly discussed and also captured in doc-
uments for each particular project. Customer-based (patient or care) knowledge
was captured differently to enterprise-based (strategic, tactical and operational
business management) knowledge, yet all knowledge was confirmed by other ac-
tors as part of daily work practices. The documents describing the enterprise were held in one central storage area with access controlled by division, then by folders, and then to selected employee roles. This information-management model proved to be cumbersome and difficult particularly when the storage area belonged to disparate divisions and information efforts overlapped. It was a history of the past, where the present was unknown. Due to the questionable currency of documents, each area of the enterprise to be impacted by any new project was re-analysed.

### 5.3.1 Results of Case Study Three
The Bookshelf was assessed against more than twenty projects over a year but never implemented due to contractual reasons. This led to further refinement of the approach and to another redesign of the solution, because:

* A way was needed to connect the organisational hierarchy with the functional hierarchy and better accommodate the difference in the management levels within each cost-centre.

* A way was needed to accommodate the different languages used by different levels of users in different business areas.

* Users needed the ability to view all business functions involved in the end-to-end solution, drill down to any level of architectural description, and to capture that description.

* Users needed to see the different entities in each value chain, supply chain, business case workflow, patient workflow, patient flow or info stream.

* A method was needed to create and show the repository for employees to enable capture of their documents, artefacts and EA descriptions for each domain in each entity, to capture and show the policies and standards for each entity, to capture and show the QA and review processes for each information item, and to update these as part of work practices.

* The EA governance and management models required integration into the approach and the solution to ease the burden of compliance for these issues.

* The information and knowledge contained in the enterprises data is subject to government-imposed confidentiality, to corporate confidentiality agreements, and to very high social expectations, therefore the Bookshelf had to be secure and able to operate within the clients firewall.

## 5.4 Combining the Findings

The aim of case study one was to provide a common profile for each business entity, which would combine to form a picture of the entire enterprise including buyers and suppliers. Case study one showed:

* Each entity in a hierarchy has its own Strategic Domain.

* Managers perform management functions for each hierarchy level and employees perform product and service functions at the lowest level.

* The functional hierarchy of each business entity could be captured in a common way for standardisation, comparison and business modelling.

* All business-function information belongs to the Business Domain.

* Adding the other AGA domains underneath these creates a profile view.
* Each domain has a number of layers, which have a number of categories, which are also subdivided.

Case study two showed the solution had to be useful for managers as well as technologists, and had to accommodate corporate politics and be resilient to the socio-technical and socio-political phenomena within the enterprise.

Case study three showed the domains of the GRM should be the 'strategic, business, application, technology, and network' domains, to capture the enterprise profile relevant to each task and to where it resides in the organisation. The task is tied with the information system used. Because of this connection, the Information Domain is organised as two sub-domains, as Business-Information and as Application-Information (an extension of Kilpelinen 2007).

<figure><img src="image_5.png" /><figcaption>Fig. 5. The hierarchies define the GRM</figcaption></figure>

Figure 5 shows connecting the organisational and functional hierarchies creates a line of sight upwards from the task through its management layers, and downwards to the application and infrastructures that support the task. When profiled, it creates the GRM. How the contents of the GRM are organised is described below.

5.4.1 Defining What's Important Most of the layer names were drawn from the FEA RMs which provide the taxonomy and ontology for describing resources within the enterprise. While case study one showed a lot of information could be put into each domain for each business area, case study two showed the information describing each business area in the domain of reference had to be collected and classified according to established frameworks for that domain, and in the users language. The author used the four layer FEA PRM and TRM hierarchies to create the four layer GRM hierarchy.
<table><caption>**Table 1.** *Table 2: the GRM hierarchy*</caption><thead><tr><th>Layer</th><th>View: PRM</th><th>TRM</th><th>GRM</th><th>GRM example</th><th>GRM example</th></tr></thead><tbody><tr><td>1st</td><td>Strategic</td><td>Technical</td><td>Domain</td><td>Strategic</td><td>Technical</td></tr><tr><td>2nd</td><td>Measurement Area</td><td>Service Area</td><td>Layer</td><td>Architecture office</td><td>Integration</td></tr><tr><td>3rd</td><td>Measurement Category</td><td>Service Category</td><td>Category</td><td>Performance</td><td>Core Diagrams</td></tr><tr><td>4th</td><td>Measurement Grouping</td><td>Service Standards</td><td>Resource Type</td><td>Customer Results</td><td>Integration Overview</td></tr><tr><td>Instance</td><td>Measurement Indicator</td><td>Service Indicator</td><td>Resource Survey.doc</td><td>Client</td><td>Integration.doc</td></tr></tbody></table>

Because each business entity is a management entity, each has its own strategic domain. Therefore the name of the entity is the name of the only layer within the strategic domain. The author categorises each entity’s strategic information into the Description, Direction, Performance and Portfolio categories. This approach allows each business area on different hierarchy levels to follow the same hierarchy of classification:

<table><caption>**Table 2.** *Table 3: aligning FEA and GRM hierarchies*</caption><thead><tr><th>Layer</th><th>View: GRM</th><th>GRM</th><th>GRM</th><th>GRM</th></tr></thead><tbody><tr><td>1st</td><td>Strategic</td><td>Strategic</td><td>Strategic</td><td>Strategic</td></tr><tr><td>2nd</td><td>Health Dept.</td><td>Information Division</td><td>Strategy, Governance, Arch Services</td><td>Architecture Office</td></tr><tr><td>3rd</td><td>Performance</td><td>Performance</td><td>Performance</td><td>Performance</td></tr><tr><td>4th</td><td>Business, results</td><td>Business, results</td><td>Business, results</td><td>Business, results</td></tr><tr><td>Instance</td><td>Annual report.pdf</td><td>Quarterly Report.xls</td><td>Performance.doc</td><td>Project Results.doc</td></tr></tbody></table>

Whilst there is no definitive answer to the names of each layer within each domain, the author found the most suitable is *what the user feels is important, and what the specialist knows where to put*. The solution was likened to a bookshelf where users could name any shelf (the domain), any category in any domain, the 'type' of information required for that category, and the document, artefact or information that belongs there in context to the business area being described. The solution was named the 'Company Bookshelf'. Putting the enterprise profile into a web-based system gives a mechanism for every level of management reflection showing who controls what, and the management and decision structures (Bernus, 2011). This is meant to allow organisations to capture their business-as-usual processes to be verified, measured, refined and improved.

## 6 Practical Significance 2: Capture the Enterprise

This paper has so far described how the Bookshelf profiles a business entity, however the question of its suitability remains. To be suitable a solution has
to be useful, easy and to do its function. Unfortunately the connections of the concepts used within the solution are not easy to immediately understand but the author hopes that once understood it becomes simple; hopefully akin to learning how to drive. The key function of the approach is to let users define what is applicable and important for each domain and then to provide the evidence from each business area. This captures the current state of the enterprise. Although the solution may be capable of capturing the necessary components of an enterprise, doing so makes light of the fact that people in the organisation would have to be motivated and disciplined enough to achieve this monumental feat. It was tested in case studies one and three, and in other engagements that capturing the ideal state of accurate, complete, and up-to-date articulation of the enterprise is not a smooth exercise when self-directed. However the author found this exercise is easier completed when driven by projects or consultants. This is because the business analysts or consultants enter business areas and ask the *what do you do, why, what do you use, why, what do you report, why?* business and systems analysis questions in their current state analysis. This type of approach allows the governance and discipline for implementation of the Bookshelf to be addressed in a step-wise manner as the work, tasks and resources of each enterprise actor in each business area are added to their enterprise profile. When employees, including management and executives see their processes in their context, the processes are much easier to be followed and maintained. The author believes as the people working in each business entity maintain their part of the Bookshelf, it would allow an always-updated information schema of the organisation and the elements within it. This would answer the questions of how to capture the current state of the enterprise, and how to keep the information current. The solution is multi-user for all organisational levels and is designed to support people in the enterprise in a distributed manner. Unfortunately, the author feels this effort holds no convincing argument yet, as the layout of this paper describes a succession of directed case studies. Collectively, these detail how the failings of numerous versions resulted in an approach, method and system for an organisation to capture information that people think is important. The author believes the Bookshelf has matured to a level which supports the representation, analysis, exchange and beneficial manipulation of business and technical information by being the mechanism that provide the coherency between the information and the talking. This fine point is important as it's where the convincing argument lies.

## 7 Conclusion

The author does not purport to provide a solution to the problem of creating a complete and universally applicable reference model for all the architectural elements of an enterprise, as this (for the purposes of classification) has been respectively been collectively provided by the FEA, GERAM (Bernus et al 1997) and numerous other solutions (Uppington, 2011). Instead the author proposes a solution that captures the structure of most organisational forms and allows each to attach their preferred functional hierarchy, which is then added to a generic reference model. This creates the Enterprise Profile, against which each busi-
ness entity within that organisation is mapped. This results in a profile for each business entity on each level of the organisation, allowing MC and PS entities to be compared on the same plane or combined with others in business-model simulations. Each profile is editable by the actors of each entity, who can enter their own names, terms, documents and artefacts to describe their world in their way. This captures the information that its' people think is relevant for their organisational history, operations, planning, and decision making. The author feels the success of this research and its convincing argument will only be determined when the approach, method and system has been used and assessed within a number of organisations. The author hopes the approach and the solution described in this paper will help organise the complexity of enterprise architecture and will give insight for organisations to improve on what they already have. This insight would not only make a leaner system, but a much more efficient system where staff have a clearer picture of what their goals are, what they have to achieve, how they can achieve it and what tools they can use.

## References

1. Bernus, P. and Nemes, L. 1997 Requirements of the GERAM, in Annual Reviews in Control, Volume 21, 1997, Pages 125-136.

2. Bernus, P. 1999. www.cit.griffith.edu.au/ bernus/ims/gm21/tg4wp1/models/

3. Bernus, 2011: personal communication.

4. Clark, G.L., and Thrift, N. 2005, The Return Of Bureaucracy: Managing Dispersed Knowledge In Global Finance, in The Sociology of Financial Markets by Karin Knorr-Cetina, Alex Preda, pp 229-249

5. Kaplan, R.S., and Norton, D.P. 1996, The Balanced Scorecard: Translating Strategy into Action; Harvard Business School Press.

6. Kilpelinen, T., and Nurminen, M., 2007 in Applying Genre-Based Ontologies to Enterprise Architecture, in ACIS 2007 Proceedings, 2007.

7. Turner, P., Gtze, J., and Bernus, P. 2009 in Architecting the Firm Coherency and Consistency in Managing the Enterprise, in OTM 2009, Volume 5872/2009.

8. Uppington, G. 2011 www.companybookshelf.com EA Framework Inventory last viewed Aug 2011.

9. Williams and Li 1999 PERA and GERAM - enterprise reference architectures in enterprise integration, in DIISM 98