Jean-Paul Van Belle

Jean-paul.VanBelle@uct.ac.za

Question: "What do a blue square, a green diamond and a red circle have in common?"

Answer: "They are all projections (or 2-D views, surfaces) of one (of an infinite family of) appropriately constructed three-dimensional objects." It is in fact mathematically proven that you can construct a three-dimensional object whose projections will fit any finite number of two-dimensional surfaces.

Why this analogy? When faced with the wide variety of business information systems out in the market place, I cannot help but feeling they are very much like the two-dimensional projections of some deeper, underlying business model. This is not surprising: many systems are, in their faithful adherence to one or the other methodology version of the Systems Development Life Cycle concept, based on user requirements and specifications. Naturally, these requirements will reflect user-centric or functional information needs. Small wonder that the resultant information systems specifications (momentarily assuming that the analyst manages to obtain a 100% understanding of the requirements) will tend to display a functional bias and be department or organisation specific.

The longer term negative implications of this specific focus become apparent when user requirements change because new business processes, structures or management methods are implemented; the business or technical environment changes; applications are expanded to become intra- and/or inter-organisational systems; organisations merge; applications need to interface with off-the-shelf components/applications etc. The underlying business model of the application is often not generic enough to accommodate the new requirements.

The central argument of this paper is that it is appropriate to direct a research effort to standardise the semantic content of a very high-level organisational model. This standard would then form the basis of more industry- and organisation-specific business models, which could in turn be "customised" to fit particular functional information needs. For lack of a better word, and to avoid the semantic overload of existing terminology, the proposed semantic model will be termed an OB-ERA: Ontology-Based Enterprise Reference Architecture. Naturally, it is envisaged that a number of competing OB-ERAs should be developed and that the marketplace (either through a darwinistic or "Microsoftistic" process) or international standards body (e.g. IFIP) will determine the survivor. It is also posited that the scope of the OB-ERA should be sufficiently generic to apply to any organisation, not just for-profit business enterprises.

The remainder of this paper consists of a simple example to illustrate the level at which the envisaged modelling should be undertaken, suggested advantages and potential problems, current IS trends which are believed to support this trend and a research agenda to arrive at the suggested OB-ERA.

Consider the following business processes:

Conceptually all are instances of (almost) the same process: the (time) scheduling of the productive capacity of an organisational resource. In practice, the implementation of a manual or computerised system to perform the above processes is likely to differ dramatically from both a logical (architectural) as well as a practical perspective. The underlying data and process models of each application will probably show little resemblance despite the fact that a " naïve" conceptual view will readily identify many common characteristics.

An sufficiently high-level conceptual enterprise model (the proposed OB-ERA) would provide (or suggest) common business objects for, inter alia, time points and intervals, organisational (sub-)units, events, monetary values, enterprise resources, capacity, customers/clients (internal & external), services/products, the allocating/scheduling of resource capacity to events, costing of the use of a resource capacity etc. Applications would inherit most attributes and procedures from these objects so that it would be unnecessary to code e.g. the fact that a video (venue, seat, hotel room) can only be lent (booked, hired) out once for each period. Similarly, code (or methods) relating to "high priority" allocations, slack or dead time in between reservations/schedules and retooling times, recurring events, overtime, productivity, scheduling sequential to or dependent on other schedules, rescheduling, maintenance, block/group booking, costing, charging to user departments, etc. should already be inherited from the object classes.

Currently, object libraries exist for interfaces (e.g. forms, menus, graphics, communications, input/output, etc.) and algorithms (e.g. mathematical & financial functions, dates, security, encoding). Application-specific "business" objects for many industries are also being developed (refer OMG), but again typically from a "bottom up" perspective. There should be both a place and considerable interest in a library of high- level "generic business objects" (conforming to e.g. OMG/CORBA standards).

Although many of the suggested advantages will present the reader with a déjà-vu feeling they are also claimed benefits for other methodologies and approaches it is nevertheless necessary to briefly re-iterate the more important ones.

Just as modern methodologies promote the re-use of code with the promise of savings in the system design phase, re-use of high-level system analysis components holds a similar promise of long term analysis savings.

More flexible systems.

The underlying deep structure of the organisations systems should, given its universal character, prove more adaptable and flexible to changes in system requirements, even if these changes are of a radical nature (e.g. merger, BPR).

Inter-organisational system compatibility.

Systems from different organisations would share the same deep structure. This would offer substantial scope for inter-system migration and communication, similar to but on a much wider scale than EDI.

Increased IT staff mobility and lower training costs.

Business and system analysts would be able to slot more quickly into a new employer's organisation. The importance of this advantage is significant given the high mobility of IT staff. Where systems development is outsourced, similar benefits-of-scale would accrue to the IT provider.

There can be no universal OB-ERA because there is no underlying unique "real" business enterprise.

It may be argued, in particular by soft systems adherents [Fitzgerald, 1996] that there is no "unique" enterprise model to be captured: "the" organisation does not exist, except as an abstraction of many real-world instances, each with their own uniqueness. All that exists are the many individual views (subjective perceptions or interpretations) of the enterprise and therefore there is no "objective (enterprise) entity" to be modelled [Stamper, 1987]. This argument comes in two forms: the strong form ("the enterprise" is a "lowest common denominator" type abstraction concept but does not exist") and the weak form ("the enterprise" may exist but the user views are what really matters, and they are as manifold as there are users").

The weak form argument is, in my opinion, refuted through the existence of a common business language, which is actually used by both managers and business media, taught to students at universities and defined in various business dictionaries and lexicons. Saltor & Garcia-Solaco [1993] further develop the discussion on how different people have diverse views of the same reality in the context of semantic relativism in databases.

The premise of the strong form argument cannot be refuted: four or six millennia worth of philosophers have still not determined whether platonic concepts exist and this is really an article of faith or axiomatic premise. A more recent contribution to this debate, placed partly in the context of our discipline(s), is from Smith [1996].

There are no "universally" acceptable business concepts.

Argument: It is easy/possible to standardise technical specifications but difficult or impossible to standardise semantics.

Discussion: Although this argument can (again) result in a prolonged philosophical debate on the nature of language, pragmatic counter-arguments are again the existence of a common business terminology. It must also be recognised that, at very high levels of conceptualisation, both meta-language and language (meta-classes versus classes) will be have to be specified and may consequently blur the notion of where syntax ends and semantics begins. It is interesting to look at the IFIP [Bernus, 1996] or EDI specifications from this light. Similarly, it is an interesting exercise to apply the same argument to the accounting model, which has been around for many centuries and claims universal applicability.

Real-world systems are too messy.

Argument: There are too many legacy systems around for an OB-ERA to find acceptance.

Discussion: Underlying this pragmatic argument is the question whether enterprise architectures (EA) per se can prove useful as a long-term IS strategy. This issue has not yet been resolved yet within the IT community [Periasamy, 1993], but perhaps this is exactly because of the ad-hoc business-specific nature of current EAs. A good EA guides the way for the development of new systems, the porting of existing systems to new platforms and the re(verse)-engineering of legacy systems. Historically a trend towards standardisation has generally triumphed in the field of information systems. Admittedly, this does not imply that the theoretically optimal standard will prevail.

There is nothing new under the sun

Argument: Most systems providers/consultants rely on established system methodologies, usually supplemented with (upper-)CASE tools. Since they do not re-invent the wheel for every system they develop (for different clients), there are a number of de facto general sets of high-level business objects, which are customised at lower levels for individual client needs.

Discussion: Even where they exist (and re-use may well be less prevalent than some academics are optimistically apt to assume) these "accumulated methodology experiences" or libraries suffer from the same fundamental draw-back as individual systems: they lack universality due to their preoccupation with current business situations and technological consideration [Bernus, 1993]. Examples that demonstrate the kind of practical suggestions which can result from "taking a step back" from immediate user needs into ontological theories and paradigms are given elsewhere [Van Belle, 1996; see also the literature on software patterns]

There are many current developments that support the motivation for an OB-ERA. All have a strong contribution to make to the above process. However, it should be noted that the following trends do not necessarily feature this papers focus explicitly.

Enterprise Reference Architectures and Data Warehousing

The existence of many separate legacy systems needing data or process integration prompted organisations to look at standardising their information models. Although enterprise architectures are still a research topic in the systems engineering and information systems community, the basic relevance, issues and methodology seem to have been settled [Periasamy, 1993], though their real-world success is perhaps less well documented.

The requirement to have a integrate data across the organisation to facilitate management decision making and enable effective management of an organisations data resource has also resulted in the need for a data warehousing approach, which in turn relies on standardisation of the semantics of enterprise data models [Inmon et al, 1997; Cook, 1996].

Business Objects

The adoption of object-orientation and the development of consistent object interfaces and architectural standards (OMG/CORBA, DCOM) have prompted a flurry of activity. The technology and the standards have matured sufficiently for business objects to become a real world technology [Tailor, 1995; Prins, 1996; Gale, 1996; Eeles, 1998]. Vendors are scrambling to develop libraries of business objects with universal appeal, and considerable work is also being done within e.g. OMG to stimulate this process. However, many vendors concentrate their efforts on developing business objects for a specific industry.

Frameworks & methodologies

As intimated above, IT solution providers and consultants employ (often proprietary) methodologies. Many times, these methodologies are supported by tools that contain a rich encyclopaedia/dictionary of high-level data structures of almost universal applicability [Bytheway, 1995]. These are then "specialised" or customised to fit the needs of individual clients or customers. The methodologies are typically supported by a specific structural view of the organisation and IT, as embodied in underlying more theoretical frameworks such as the Zachman framework [Zachman, 1987; Evernden, 1996].

Enterprise-wide information systems

The advent of enterprise-wide information systems such as SAP, BAAN and PeopleSoft has shown that a relative large portion of information systems needs can be met by generic systems. The user requirements are not used for the conceptual design but rather the final customisation of (the user view/implementation) of the generic IS. Although some enterprise-wide systems claim to be based on deep conceptual models of the enterprise, they occur to the author more as distillations of industry implementations from which higher-level business object models were developed through a somewhat iterative process [Curran, 1997]

Best SE practices, templates and software patterns

Practitioners have realised that there is substantial conceptual overlap between the models. This has been documented in publications that contain generic data models [Silverton, 1997] or best practices in systems engineering [Reingruber, 1994]. With the move towards object-orientation, some of the slightly higher-level principles have also been identified and a flourishing research area in software patterns has emerged [Gamma et al, 1995; Hay, 1996; Fowler, 1997]. A standard has in fact already been accepted for the petro-chemical industry [POSC, 1994].

Enterprise Ontologies

Ontologies are an emerging and exciting sub-discipline within enterprise modelling. Initially, the aim of enterprise ontologies was on capturing the semantic contents of a high-level enterprise model as formally as possible by means of first-order predicate calculus or similar formal mathematical languages [Gruber, 1993]. This level of formalisation allows deductive reasoning within artificial intelligence contexts (e.g. the Enterprise Integration Laboratory at the University of Toronto; Fox, 1993). Other ontology researchers, who do not require automated deduction, developed less formal ontologies (e.g. the Enterprise Ontology Project at AIAI in Edinburgh; Ushold, 1995), typically using higher-level tools such as those provided by the Knowledge Sharing Effort at Stanford.

Theoretically, any of the above approaches could be extended and used as the basis for the development of a standard OB-ERA. In all probability, they will all (continue to) gravitate closer towards a more universal, generic enterprise model.

It is hereby proposed that currently existing enterprise ontologies are expanded by means of a number of methods. (Unfortunately, space does not allow for full elaboration and motivation of this proposal.)

The validation of any proposed OB-ERA is an equally critical issue. Although a number of criteria have been proposed in the more generic literature, the issue remains relatively unresolved.

Jean-Paul Van Belle, 1998.