A Method to Define the Object Information Architecture

of an Information System

This paper presents an object-oriented method that is applicable when planning the information system of the business and lets us capture and specify the requirements of an information architecture that is easy to understand by both business users and IS professionals. It is a high level information architecture that favours the identification and integration of different types of applications. The use of the method is illustrated with a specific example drawn from the shipbuilding industry.

1. INTRODUCTION

Information System Planning (ISP) is the activity of producing a plan where we consider "Management Objects" at two levels – Organisation, and Information System (IS) – to build a global view of the IS and include the necessary components for its implementation (Amaral, 1995). One of the most important IS "Management Objects" is the Information Architecture, because it lets us identify opportunities for obtaining competitive advantages. It also lets us establish and maintain connections between the organisational objectives and the resources involved in the development project of its applications. Finally, it lets us define the business areas and development project boundaries, so that we can co-ordinate the development projects and derive the required technological and organisational infra-structures.

The difficulty of communicating and making understood the information architecture modelled using the Entity-Relationship Model (Earl, 1993; Goodhue et al. 1992; Kim and Everest 1994) and the growing impact of object orientation (OO), first in the field of programming, and more recently in the models for businesses and their supporting IS (Martin 1992, Jacobson 1994, Gale 1996), led us to develop an object-oriented method that is applicable when planning the information system of the business. This method lets us capture and specify the requirements of the Information Architecture in a way that is easily understood by business users and IS professionals, and gives us a high level architecture that favours the identification and integration of different types of applications.

2- MODELLING THE BUSINESS AND ITS INFORMATION SYSTEMS WITH OO

 Most enlightening examples of modelling the business and its Information System with OO are found in Martin's Information Engineering (Martin, 1992), used for planning, analysis, design and implementation of applications, Jacobson's Business Reengineering (Jacobson, 1994), which integrates business reengineering with processes and applications design, and Gale's Future Strategy Business Planning Methodology (Gale, 1996), that proposes an object oriented enterprise model to support the planning of the information system and its object oriented analysis, design and implementation.

Although the aims and steps of those methods vary, they all adopt object oriented approaches to model the business as well as its information system. They also try to grant that the objects identified for the representation of business information can be used to support requirements engineering for the different applications that result from the business model.

Martin's proposal is centred upon applications that can be fully represented in a computer. Applications are first identified in the strategy phase and, later, new systems are identified during the analysis of the individual business areas. The applications thus identified are only supported by objects of the individual business areas being analysed and not by objects of a global information architecture of the business. As a result, the global information architecture cannot be used as the key support for the identification of new applications whose role is clarified by the responsibilities of the objects of that architecture.

Jacobson does not define a global information architecture for the business, but only for the processes that are being subject to reengineering. The technique used to support the external model of the business (the "use-case" model) is not really successful in managing the complexity of the situation and the types of objects used for the internal model do not speak the language of the business.

Gale's proposal aims at modelling the enterprise considering it as a specialised organisation, a hierarchical multi-layered system with an information processing network configuration where the nodes are sub-systems of the general system. This method also defines an information architecture, modelled by entity objects, based on that model and on the structure that supports it. This differs from our proposal, in which the information architecture, modelled by activity, resource and product objects, is as independent as possible from the way in which business is carried out and organised.

The object-oriented method presented in this paper is aimed at capturing and specifying the requirements of the IS Information Architecture for the entire enterprise (which is, as much as possible independent from its structure), when planning its information system. This proposal differs from the others in: (1) objectives – it defines a high level information architecture of the enterprise (which is easy to understand by business users and IS professionals); (2) steps of the method – which lead to an information architecture modelled by activity, resource and product objects that speak the business language; and, finally, (3) techniques, which create dependency, scenario and business object diagrams as different types of matrices.

3 – THE APPROACH

After having identified how the various OO analysis and design methods identify the objects for system modelling, we developed an object oriented information architecture, for an enterprise of the ship industry (Shipyard of Viana do Castelo – Portugal), that is as independent as possible from the structure of the enterprise. This made possible the test and creation of a set of concepts, steps, and supporting techniques that illustrate and demonstrate the operational value of the method.

4 - THE METHOD

Before we present the concepts and steps of the method we first need to define some key terms:

- Information System (IS). In a close view, the IS is seen as an information sub-system supported by computers with the aim of recording and supporting management services and organisational operations.

- Information System Planning. It is the activity of producing a plan where we consider the " Management Objects" of the two levels – Organisation and Information System – to present a global view of the information system that includes the necessary components for its implementation. The management objects of the information system are the specification of the information architecture, the identification of applications and services to support the organisational processes, and the definition of "Application and Services Development".

Figure 1 – IS Information Architecture

4.1 – Definition of concepts

The first group of concepts presented support the definition of the functional business model and the second group supports the definition of the different types of business objects used to model the IS information architecture.

4.1.1 – Concepts used for functional business modelling

- The functional business model contains the key knowledge about the business and the information needed to conduct it. The functional business model expresses the nature of the business and offers a stable basis to define the information architecture. It captures the essence of the business nature in the definition (structure) of the functions, without considering those aspects of the business that are most dynamic or most susceptible to change such as:

- A functional area is a grouping of business functions that materially contributes to the margin or value of products or services of the enterprise according to Porter’s value chain.

- A function is any set of actions performed in the course of the business. This definition is only based on the actions performed, not in the way the enterprise is structured or conducted.

- An activity results from a functional decomposition, it is oriented to a single-action, executed repeatedly, and has an identifiable outcome.

- A dependency between activities shows how they are related to each other temporally and how they depend from each other.

- A scenario describes the procedure and the information needed to perform an activity.

- Events are external real-world happenings that require a given action.

- Business object

We define a Business Object as "a representation of a thing active in the business domain, including type, ISP attributes (characteristics related to use and value for the business strategy), name, definition, business attributes (characteristics of content related to the business purpose that it must fulfil), responsibilities, relationships". This is generally a natural or modelling language representation.

A business object relationship is defined as a physical or conceptual connection between business objects which are used as follows:

- Pattern(s) are repeated occurrences of types of business objects and associations that can be generalised. We use behavioural and structural patterns.

- IS Business object

We use the definition of the Business Object Management Special Interest Group (BOMSIG, 95): "representation of a thing active in the business domain, including at least its business name and definition, attributes, behaviour, relationships and constraints" . The representation may be in a natural, modelling or programming language.

4.2 - The steps of the method

The method must be preceded by a strategic analysis of the business that leads to the identification of alternative scenarios for the organisation and will be used to establish adequate strategies for the organisation. After having an organisational answer for these strategies, we suggest the following steps for the method:

Step 1 - Define the functional business model

The design of this functional business model is based on functional areas resulting from Porter’s value chain (Porter, 1985), which is recognised by various authors (Martin, 1992, Gale, 1996) as a valuable tool to identify the key information and applications as well as the ways in which systems integration can sustain competitive advantages or reduce disadvantages. Some activities of the functional business model for a shipbuilding enterprise are shown in Fig.2.

Figure 2 - Functions/Activities of the Functional Business Model for a shipbuilding enterprise

Step 2 - Define the dependency between activities

Considering that our aim is to define a business model and an information system model, so as to make possible the integration of activities, we now need to define dependencies for the activities. The dependency between activities detected in this step will be described by pre-requisite and post-requisite statements, or by dependency diagrams. This dependency will be described in information system development by behavioural rules that state the pre-conditions to trigger the activity and post-conditions to control its execution.

This dependency lets us identify which product of an activity, or which products of various activities, must be created to be used as resources in other activities. The knowledge of this dependency between all the activities (either of the primary functional area or of the support functional area) gives us a better understanding of interrelationships, favouring the integration of the applications that may be supporting some of these activities.

Step 3 - Identify business events

To define the business model we also consider a business event list as an alternative form to trigger activities.

The identification of business events recognised in this step lets us clarify which are the activities resulting from a business external event and which external actors trigger them. This list of events may be supported by the external value chain (in agreement with the type of industry to which the business belongs) and may refer to all kinds of interaction developed within the external environment of the organisation. Thus, we consider as events not only those that trigger activities but also those that are external to the business and may change the way in which the business is conducted.

Step 4 - Identify how the activities are performed

The functional business model needs to be complemented with details about the business:

The identification of the development details of activities performed in this step lets us capture the information and procedures used to execute the activities. They will, in turn, support the information requirements needed to analyse the activities that integrate the IS (supported by applications). The information requirements for the different activities is determined (acquired) by using questionnaires and open interviews. We do not use non-introspective methods as means of interaction analysis because we are in a planning activity (ISP) and some activities might not have been executed yet.

Step 5 - Define the business objects

The activities of the primary functional areas are related to the most important business events of the business, usually the customers' demands. They are our point of departure for the definition of the business objects. The subsequent scenarios are developed according to the activities that depend from the initial one in other primary or support functional areas of the business.

For each scenario corresponding to an activity:

- we identify:

To illustrate this step, we present two business objects "Estimate_Labour" and "Block", for a shipyard, using Rational Rose 3.0 as the tool to build the diagrams. For the activity "Estimate labour" we present the scenario diagram (Fig.3), the business object diagram (Fig.4) and the definition of the object "Estimate_Labour" (Fig.5).

Figure 3 - Scenario diagram

Figure 4 - Business object diagram

Figure 5 - Definition of the internal inter-functional activity object "Estimate _Labour"

For the internal inter-functional resource object "Block" we utilise the same type of diagrams for all the activities used. Here, however, we only present its specification. Block is one of the parts of the ship hull that result from the building strategy. Here we do not present the scenario diagram and the object diagram for the different activities that use this object, but we declare in the definition of the object the characteristics and responsibilities it acquires as a result of its use by the activities "Define construction units", "Plan blocks installation", "Split blocks" of the Design Area, "Planning of cutting, pre-fabrication and installation of blocks" of the Planing Area, "Control Activity" and "Organise subcontracts" of the Production areas, as illustrated in the fig.6.

Step 6 - Define IS business objects

We must analyse how each business object is supported by the IS. So, in agreement with the responsibilities acquired by each activity object in step 5 we can identify the following situations:

- The activity object can be developed autonomously (being responsible for the control of the activity), with all the resources for the activity being created and tested. Then this activity object will be an IS object .

- The activity object cannot develop autonomously its control responsibilities, and is not, as a result, an IS object. However, the resources and product objects related to the activity object will be IS elements.

- Other activity objects (not entirely responsible for the control responsibilities of the activity) need that these activities be performed at the physical level (shop-floor, etc.) and that an external actor introduces the information resulting for that activity (dividing responsibilities with the user of the system). In this case, the activity object will be an IS object and the external actor must introduce the required information so as to develop the control responsibility sequence for the activity object.

We can conclude that the resource and product objects are elements of the IS information architecture and that the activity objects are not necessarily part of the IS.

This step is particularly important since it lets us identify the business objects that will be part of the IS information architecture, as the activity objects that are IS elements. It must be stressed that the responsibilities corresponding to behaviour rules that control the state transition of these objects will only be considered during the analysis phase of business applications development.

5 - EVALUATION OF THE IS INFORMATION ARCHITECTURE

An evaluation of the information architecture obtained with this method for a shipbuilding enterprise has been carried out with the business users and IS professionals of the firm, and has shown that the characteristics and responsibilities defined for the resources, products and activity objects facilitate the capture of the high level information that is important for the business and increase the mutual understanding and communication between stakeholders.

The evaluation of the object context (resource, product and activity objects) resulting from the application of the method has also shown that it was easy to identify the requirements in applications, due to the important set of characteristics and responsibilities that they helped identifying.

6 – CONCLUSIONS

The key concepts (specially the different types of business objects) and the steps used in the method let us obtain a high level information architecture modelled by activity, resource and product objects and let us create a context formed by those objects, which have acquired a set of characteristics and responsibilities that favour, during information systems planning, the identification and integration of the different types of applications.

REFERENCES

 Amaral, L. , PRAXIS – Um referencial para o Planeamento de Sistemas de Informação, Ph.D. Thesis, University of Minho, 1995.

BOMSIG, OMG Business Application Architecture - White Paper, 1995.

Earl, M.J., Experiences in strategic information systems planning. MIS Quarterly 17(1) 1-20, 1993.

Gale T. , Eldred J., Getting Results with Object-Oriented Enterprise Model, SIGS Books, 1996.

Goodhue, D.L., Quillard, J.ª,Wybo, M.D., Strategic data planning: lessons from the field, MIS Quartely 16 (1) 11-34, 1992.

Jacobson, I., The Object Advantage - Business Process reengineering with Object Technology, Addison-Wesley Publishing Company, 1994.

Kim, Y., Everest, G,C., Building and IS architecture: collective wisdom from the field, Information and Management 26,1-11, 1994.

Martin, J. , Odell, J., Object Oriented Analysis and Design, Prentice Hall, Englewood Cliffs, NJ, 1992.

Porter, M.E., Competitive Advantages: Creating and Sustaining Superior Performance, The Free Press, New York, 1985.

Taylor, D., Object-Oriented Information Systems, John Wiley & Sons, Inc, 1992.

Taylor, D., Business Engineering with Object Technology, John Wiley & Sons, Inc, 1995.