October 2000              Issue: 16

Journal of Conceptual Modeling
www.inconcept.com/jcm

A Structured Modeling Approach to Object-Oriented Representation of Business Domains
By Dr. Kiran J. Fernandes and Dr. Vinesh H. Raja

Introduction

Today's business world is facing a plethora of managerial and technological changes beyond the capacity of any company to control and absorb them. Customer satisfaction, development of new products, and the introduction of new technologies are some well-known driving forces, but frequent modifications are making them unpredictable. To succeed in this competitive environment, it has been established that companies should employ Business Process Re-engineering (BPR) as a means to change their business processes and radically improve their business. Although there are a number of successful industrial cases to support this proposition, at present it is still used mainly in large companies. Small to medium sized companies may consider it as a risky and expensive activity. Information Technology (IT) is widely regarded as an enabler in most BPR initiatives, and the effectiveness of the IT infrastructure should be closely monitored. In addition, it should be flexible enough to incorporate legacy systems without large cost implications and to allow graceful evolution as part of an ongoing continuous improvement programme.

Within this overall context, this paper discusses a methodology for structured business process modelling and analysis using Object Technology (FR00a)(FR00b)(UF99). The aim of the methodology is to support rapid business process change and re-engineering incorporating legacy systems. The framework for AMORE (funded under the auspics of the EPSRC frunded grant, M02675) has been informed by a comprehensive review of the BPR literature [MKJ98], and is representative of current thinking on BPR from a business-oriented viewpoint. As will be explored in subsequent sections, this thinking is in tension with ideas developed about BPR from an IT perspective.

Motivation and Background for AMORE

An increasing number of companies are adopting the concepts and principles of BPR. This aims to radically alter many outdated procedures, to reduce costs, and to improve the companies' competitiveness. IT plays an important facilitating role but should not be regarded as the only key to achieving the expected results.

The keen interest in BPR can be attributed to the fact that most leading companies are likely to subscribe to one of the most popular and valuable management dogmas: to stay close to their customers. Recent literature shows that most well-managed and established companies are consistently ahead of their industrial rivals [Cer94]. Although BPR constitutes a well-known managerial approach for increasing business competitiveness, its diffusion is still slow and it mainly concerns large companies. This can be partly explained by poor attempts to gain a complete understanding of the business processes concerned and the subsequent deployment of inappropriate IT support. Researchers studying problems in the implementation of BPR [Jam96a] have pointed out that as many as 50% to 70% of projects have failed to achieve the dramatic results at which they aimed. The key to a successful BPR implementation is to strive to attain a better understanding of the underlying business process through a systematic approach so that a smooth transition from a business view into an Information System (IS) domain can be achieved.

Despite the need for a tight coupling between the BPR practice and the IT perspectives, co-ordinated actions involving BPR and IT practitioners are still rare. This is largely due to a sort of conceptual gap dividing the "world" of IT design and the "world" of BPR techniques. This gap is apparent not only in the frequent poor understanding of the business process view by IT experts, but also in the difficulties that BPR experts face when they try to systematically uncover the business process from the existing software system. In short, one can say that there is an inherent difficulty in transferring knowledge [FRM00] between people designing information systems required for a BPR implementation and their customer (viz., the company undergoing the BPR exercise), due to problems such as the difference in cultures, languages and problem perception. This distinction accounts for problems in modelling new processes and in controlling their implementation lead-time, costs, quality and completeness.

We argue that any methodology aimed at addressing these problems in order to reduce failure rates of BPR projects must take the organisational, managerial and technological factors into consideration. Our methodology, based on the concepts of object technology, originates from the AMORE project. The AMORE project aims to deliver a methodology which uses distributed computing and component-based development (CBD) to drive and support a flexible IT infrastructure for use in large and medium sized organisations. This will enable software systems and business processes to evolve rapidly, enabling congruence between organisational changes and business focuses. In satisfying this goal, the following objectives are identified:

• The creation of a methodology for structured business process modelling and analysis using object technology to support re-engineering, rapid business process change and the adoption of legacy systems.

• The proposal of a framework, based on the methodology for the integrated use of distributed systems, to support rapid evolution of re-engineered processes.

The Conceptual Approach

A successful implementation of a structured business model requires a comprehensive set of tools for formal representation and thus enabling analysis, a method for embedding organisational and managerial aspects concerning strategic orientation and more importantly, the involvement of customers. Communications between the modellers, designers and the users are essential in reaching a platform of common understanding from which to resolve ambiguous or contentious issues.

Process modelling is the first step in formalising processes [UF96a, UF96b] and in creating a foundation to build on. In this paper, the term 'process' is defined as follows: "A process uses a defined input to produce a defined output and it consists of tasks which are performed by the organisational units. The information that is needed for the execution of a task is stated either explicitly or implicitly."
A process is composed of a set of tasks, together with the relationships between these tasks that define their possible orders of execution.

Process modelling by itself is not sufficient to define the whole business domain. Research has concentrated on representing processes by means of a structural architecture. Flow Diagrams, Activity Diagrams, IDEF diagrams are being used to represent processes and the relationships between them. A lot of work has also been done in the area of process translation. Projects such as PIF (Process Interchange Format) [LGJMTY97] and PSL (Process Specification Language) [Psl00] are designed to support the exchange of process descriptions among different process representations. Our belief is that any particular process description format is unlikely to suit the needs of all applications completely.

Software models are primarily used for performing static (Use Case Models) and dynamic process analysis (Process Interaction Models). The objective of software modelling is to represent parts of the real world and its behaviour. Since software models are based on business models, business and software modelling activities are tightly connected. The effective integration of software models with business models is a central objective in BPR; there is always a danger of building software models that do not reflect the real business conditions. This is mainly due to the conceptual differences between business strategies, the real processes, and the software systems that support them. Furthermore, it would be difficult to completely embed all the business knowledge into a software model because there are technological constraints [FRA00a].

Generic models are often used to describe the structure and the behaviour of a process unambiguously [CK092]. They refer to characteristics at a high level of abstraction that are common to companies having approximately the same size and operating in the same industry. Generic models provide building blocks that are efficient and easy to use but are inappropriate for detailed modelling. In order to meet the effectiveness requirements, more detailed models have to be made available and this may subsequently incur higher costs.

One approach to detailed modelling which is directed towards defining basic processes characterising different industries, is given by ARIS (ARchitecture of Integrated Information System) [Sch92]. The focus of ARIS is on the integration of processes by using event-controlled chains. In this architecture, processes are the basic units of analysis and can be tailored to different kinds of companies. Depending on the pursued objectives, ARIS allows the users to define various perspectives without losing the global view of a process. The system focuses on the analysis and modelling of business processes as well as on methods for describing the complexity of a corporate IS environment. In this stream, PROMAX [KR96] offers a more comprehensive set of functional and representational requirements, considering both production and administrative environments.

Another approach [Ner92] takes a different stance and its focus is on objects. The process is defined by the continuous interaction among these objects. This is a bottom-up approach, based on elements constituting the problem space, as opposed to the top-down definition of building blocks. It is flexible in managing highly volatile requirements and continuous paradigm shifts [Ner92], but it may have some limitations when trying to keep systems consistent.

Some researchers have concentrated on defining objects involved in the modelling [GF94]. Their aim is to provide a shared terminology that enterprises can use to define objects, the knowledge they contain and their mutual relationships. The researchers tried to define the meaning of each term in as precise and unambiguous manner as possible. For example, the TOVE (Toronto Virtual Enterprise) [GF94] semantic is implemented in a set of axioms that, by means of knowledge-based simulation, automatically deduces the answer to many common sense questions about the enterprise and defines a set of symbols for depicting terms, or the concepts constructed from terms, in a graphical context. This ensures a consistent representation of relations among entities, and facilitates better communication, coordination, and optimisation of enterprise decisions and processes to achieve higher levels of productivity, flexibility and quality.

An approach that combines both process and object ingredients, is proposed by Jacobson [JEJ94]. It is called Object-oriented Business Engineering and is based on use cases. This approach utilises an external and internal model of business. The former is object-oriented and describes the company and its external environment (e.g. processes that satisfy customer's needs), whereas the latter describes business processes, different tasks (internal processes) they consist of, and the various types of resources that they exploit or produce. The processes are modelled through use cases, whereas the environment is modelled through actors. A use case is a sequence of transactions in a system whose purpose is to yield a result of measurable value. The use case model shows how the external environment interacts with the business, that is, how actors communicate with use cases within the business.

Although each of these approaches attempts to integrate different viewpoints and to support the reuse of components, they do not clearly distinguish between business modelling and software modelling and the constraints they impose. This may increase the risk of low adherence of the final models to the represented processes.

An Introduction to AMORE

Structured modelling tools such as ARIS and PROMAX which integrate business modelling and system design can provide substantial support for IS development. In general, these tools aim to provide an integrated "abstraction-to-reality" solution for business systems development. Historically, these tools have not lived up to expectations, partly for the following reasons:

1. They do not adequately address business requirements prior to the system design.

2. They do not consider the details of transforming business requirements to system components.

3. They provide no traceability between business requirements and system components.

4. They lack an enterprise-wide understanding of and perspective on what they are attempting to automate.

5. In the case of older tools, they generate code for outdated technology and are clumsy to use.

The "abstraction-to-reality" strategy is not currently implemented in any single toolset. AMORE, the methodology introduced in this paper, is aimed at realising the idea of "abstraction-to-reality". The outline of AMORE that follows comprises a brief overview of the method, and a brief description of the models and guidelines it involves.

The AMORE methodology is based upon two phases viz. the Business View Phase and the Software View Phase, as represented in Figure 1.

Figure 1: The AMORE overview

These two phases of AMORE are based on the object-oriented principles and are designed to support re-engineering and rapid business process change (adaptive organisation). AMORE involves the Models and Guidelines displayed in Table 1: 

Table 1: Items comprising AMORE

"Abstraction-to-reality" begins with a clear model of the business concepts and processes. The key management issues considered are the classic business issues of Who? What? When? Where? Why? and How? The answers to these questions will guide process improvements and system development. This is the essential focus of the Business Domain Model. The BDM will then be examined and validated by the customers. The customers will decide whether the organisation should carry out a Business Process Re-engineering exercise. This will lead us into the Business View Phase. The Business View Phase first considers the business concepts and dynamics before deriving and analysing the business domain model. The IBM is the representation of the business domain. This business model is translated into an OOIBM using guidelines. The final step is to translate the OOIBM into a RBM using similar guidelines. The RBM will generate software that aims to support the business domain.

At every modelling stage, there are supporting tools (e.g. to specify goal mapping, business interaction, workflow and organisation mapping) that can translate the models into deliverables such as printed documents, software prototypes and ready-to-run applications. These deliverables can then be discussed with and validated by the customers. As the customers are involved at every stage of the modelling, AMORE can be regarded as a customer-centric structured business model.

This design of AMORE aims to bridge the gap between the business and IT worlds, and to enable the IT and BPR practitioners to move from one view to another in a more effective and efficient way. The next three sections elaborate on the phases of AMORE. They respectively outline the modelling involved in the Business View phase, the modelling involved in the Software View phase, and the Guidelines.

Modelling in the Business View Phase

The Business View phase of AMORE involves three models: the Business Domain Model (BDM), the Ideal Business Model (IBM) and the Object-Oriented Ideal Business Model (OOIBM). Both the IBM and the OOIBM are process models, but the BDM is a richer model that incorporates domain knowledge that informs the business processes. The IBM that is used to initiate the Business View phase is derived from the BDM.

AMORE is based on the premise that the identification of the business processes and their implementation can be treated as separate concerns. This stance is reflected in the concept of Business View and Software View phases.

The Business View phase is initially framed by an exercise in business domain modelling that identifies the IBM. In general, this can be a long and iterative exercise that includes requirements analysis, customer interviews, protocol analysis, a procedural review and a contract review. The scope of the business domain modelling is determined by which process is targeted for re-engineering or re implementation. Depending on the customer requirements (for instance, whether an increase in productivity of the process is required) it may be necessary to re-engineer one or more processes in order to obtain the IBM. Where necessary, BPR is performed as part of the preliminary business domain modelling activity that precedes the Business View phase.

Where BPR is concerned, AMORE adopts the PAMS (Principles and Methodology Support for Re engineering the Product Introduction Process) system for re-engineering processes. The PAMS [PAMS] system has been developed as part of the EPSRC funded SPEDE project [MR98][SPEDE]. The PAMS system is:

• An easy-to-follow BPR methodology with the ability to access appropriate software when needed;

• Designed to reduce the learning time and increase the working time of newly formed BPR teams;

• Designed to support business process improvement teams with easily accessible information about principles, methodology and tools, and techniques for BPR.

Through PAMS, the computer can serve a useful role in the meta-level activities of BPR that are concerned with re-designing work and re-allocating responsibilities.

The focus for the business domain modelling exercise that establishes the IBM is the construction of the Business Domain Model (BDM). The target process that is the subject of the re-engineering activity determines the scale and scope of the BDM. Though the primary goal of the business domain modelling is to arrive at a process model for the IBM, the BDM is not merely a process model.

Traditional business models are typically framed in terms of abstract processes that are divorced from their situated context in the real business world. For example, commercial tools such as ProModel [Pro00], though they aim to represent and simulate a process, do not take the factors that influence the form and character of the process into consideration. Systems that are purely developed using such tools may fail because they take too little account of the real business world.

In AMORE, the BDM developed in the course of re-engineering a process aims to serve two functions: fulfilling the role of conventional state-of-the-art processing modelling tools, and enabling the factors that influence the design of business processes to be recorded. The latter function elevates AMORE from a "process-centric" to a "domain-centric" approach. The potential advantage of a domain-centric viewpoint is that it takes account of the way in which processes depend upon influencing factors, thereby offering a more realistic view of the business domain. For example, when interaction with an external organisation is involved in a business process, a change in that organisation will affect the underlying business domain. Dependency of this nature is not addressed in traditional process-centric approaches.

The architecture used in developing the BDM requires an extension of conventional representational systems for process modelling. IDEF3 (ICAM DEFinition language) has been the most widely used representational system for process modelling. One of the main drawbacks associated of using IDEF3 is that of translating process information. To create a common representational notation, the PSL (Process Specification Language) [Psl00] (ISO/TC184/SC4 & SC5 V1.0) project has framed the outline for a process specification language. We have developed a novel modified process representational technique termed IDEF** because it is an enhancement of the IDEF3. This novel methodology is CIMOSA-compliant, IDEF3-based and can be integrated into the functional requirements of PSL. It also allows dynamic analysis of aspects of the process such as task and customer interactions. More details of this representation technique can be found in [FR00c].

Figure 2: Business Domain Model

Constructing the BDM associated with a targeted process is intended to address a comprehensive range of relevant issues. The modeller must examine the whole process to identify its parts and to understand the interaction among the different subsystems. The BDM should supply an abstract, expressive and rigorous representation of the targeted process that can be used to enhance process comprehension, to validate its behaviour and to evaluate its performance. The business factors that influence the structure of the targeted process must also be recorded (see Figure 2). These include the goals of the processes (and their relationships to the goal of the company), the tasks, location, customers of the process, organisational units, governing protocols, procedural requirements, contract requirements and time constraints. We have developed an ontology for these influencing factors, in which their semantics, synonyms, interrelationship, attributes, and syntactic form are specified.

The rôle of influencing factors in AMORE is illustrated by our treatment of goals. One of the most important and fundamental drivers in a re-engineering enterprise is to understand the goals ("goal mapping") of the organisation. Typically, the goals of an organisation are derived from the "voices of the customers". We have developed a procedure by which goal mapping can be considered in the preliminary stages of business domain modelling [FRA00b]. A cost optimisation model for goal mapping, based on work practices of the Space Shuttle Testing Facility at the NASA SSC, has been used to demonstrate the concept of goal mapping and its importance to the BDM.

Modelling in the Business and Software View phases

The business model for a typical large, modern enterprise resides primarily in the minds of its employees and in its software applications. One of the most costly disparities in such an enterprise is that between the mental models of its employees (which reflect the real world they deal with) and the implementation of business processes in its software applications. The Business and Software Views phases in AMORE are aimed at integrating the mental models of employees with the models of the IT applications. The Business View Phase in AMORE involves the elaboration of the Ideal Business Model (IBM) to the Object-Oriented IBM (OOIBM). The Software View Phase then develops the Real Business Model (RBM), which captures the business domain from an IT perspective.

Developing enterprise-wide business and system models prior to software implementation provides a conceptual blueprint that ensures the business users and the software engineers have a common understanding of the new software systems. This is analogous to an aerospace or automotive engineer developing models, blueprints, and precise engineering diagrams before manufacturing complex and costly products.

The IBM, derived from the BDM as described above, describes the business processes as operating in what is seen from a business perspective as an ideal situation. The IBM is specified by a process model derived from the BDM, and is represented using IDEF**. The next step in AMORE is to translate the IBM into an OOIBM. The set of guidelines (IBM2OOIBM) that we are developing to achieve this will be discussed in the next section.

The choice of an Object-Oriented Ideal Business Model as the bridge to software specification is naturally suggested by current software practice as supported by modern techniques and tools. In the course of the last few years, the use of object-orientation has not only gained popularity in the software engineering arena for which it was first conceived, but has also been widely adopted in other areas [FR00b, UF99, UFD97]. AMORE uses the standard UML (Unified Modelling Language) concepts for representing the object-oriented view. The IBM is to be translated to the OOIBM using guidelines defined by AMORE. The OOIBM comprises two related models:

1. The business use case model, which shows the business system from the users' point of view. This is the white-box view.

2. The business object model, which is a detailed design of the internal structure of the business system. This is the black-box view.

The final step in AMORE is to translate the OOIBM to a Real Business Model (RBM). The set of guidelines (OOIBM2RBM) we are developing to achieve this will be discussed in the next section. The RBM is obtained by translating the business objects derived from the business object model and the use cases into an architecture of interconnected software objects. The end product of this translation is a set of software classes and objects, together with the set of dependencies between these classes (as defined by inheritance and association) and associated user interfaces.

AMORE uses IS use cases and IS logical view to represent the RBM. The RBM reflects the IBM from an IT perspective. The software generated from this model can be used directly to support the business domain. We are currently investigating how to translate this model to produce software that can be incorporated into commercial software such as Windchill [Win00].

Guidelines

Model translation is not trivial, and many approaches have been developed to tackle the problem. These approaches range from simple suggestions and heuristics to pure formal languages such as First-Order Calculus and formal grammar. The former are inadequate in exploiting formalism, whereas the latter are incapable of capturing the fuzziness and the imprecision intrinsic in process mapping. The AMORE approach aims to reconcile the two and to pursue an intermediate level of formalism, through a well-organised list of "how-to" related suggestions structured in a pattern-like form. The structure we use for the mapping guidelines is very similar to the canonical form of patterns due to Alexander [Ale98, Ale64]. It includes the following elements:

• Guideline Name

• Problem

• Context

• Forces

• Solution

• Rationale

• Resulting Context

• Related Guidelines

• Example

The set of guidelines used to map the IBM into OOIBM define the IBM2OOIBM language, whereas the set of guidelines used to map the OOIBM into RBM define the OOIBM2RBM language. The set of models can be treated as a state space. A state transition occurs whenever a guideline is applied to the model. A sequence of states can be regarded as the evolution of a solution. The solutions to a problem are those derived from the final states. The guidelines in AMORE are a means to guide IT practitioners towards a possible solution. It should be noted that it is difficult to formalise whether one state is more important than another as this is heavily dependent on personal judgement and the possession of domain-specific knowledge. For this reason, we propose to structure the guidelines in an ordered sequence so that the users can follow the guidelines in a systematic and logical fashion. To simplify the use of our languages, we will also provide entry-points for users so that the guidelines can be traversed in a particular order.

The transition from the IBM to OOIBM is achieved using the IBM2OOIBM language. This language is partitioned into three classes, associated with the paths depicted in Figure 3:

• IBM to Business Use Case Model Path (IBM2E)

• IBM to Object Model path (IBM2I)

• Business Use case Model to Business Object Model path (I2E)

Figure 3: IBM2OOIBM mapping

The mapping guidelines are classified according to the three paths depicted in Figure 3, viz.:

IBM2E
The path from the IBM to an external and object-oriented representation of the business (Business Use Case)

IBM2I
The path from the IBM to an internal and object-oriented representation of the business (Business Object Model)

I2E
The path inside the OOIBM indicates the development of the Business Object Model based on the Business Use Case Model. This is done via an iterative and incremental process and is aimed at refining the object-oriented classes and their relationships. Steps purely representing refinement are outside the scope of this path. Since the guidelines are kept strictly for the purpose of process mapping, there will not be a comprehensive set of guidelines for developing the complete Business Object Model except where the mapping from the Business Use Case Model to the Business Object Model is concerned. A complete set of guidelines for the IBM2OOIBM mapping will be developed. A sample guideline for translating the location to business area is given in Table 2. 

Table 2: Sample Guideline

The OOIBM2RBM language is concerned with the transition from the business perspective towards the underlying IS. As depicted in Figure 4, the guidelines in the language are classified according to four main paths that can be described as follows.

• Business Use Case Model to Information System Use Case Model (BU2IU)

• Business Object Model to Information System Use Case Model (BO2IU)

• Business Object Model to Information System Logical Model (BO2LM)

• Information System Use Case Model to Information System Logical Model (IU2LM)

Figure 4: OOIBM2RBM mapping

The guidelines resemble those in the IBM2OOIBM language and are defined by a pattern-like syntax.

Conclusion

This paper has outlined a methodology for object-oriented re-engineering of enterprises. It is clear that, in the present state of maturity of software engineering, there is no plausible alternative to the object-oriented paradigm for practical industrial application of BPR. AMORE and the OPM school identify a similar weakness in object-oriented methodologies that have been proposed from an IT perspective. Their emphasis on design-for-change focuses too much attention on the flexibility of the mechanisms that support the business processes, and gives too little to the origin and character of the processes themselves. Methodologies such as OPM and [WPS00] try to address this by taking a process-centred approach. AMORE advocates a domain-centred approach, in which the goals and constraints that define the business domain model have a prominent and primary role.

There are certain business domains, such as that of manufacturing systems, where the presence of powerful toolkits (such as Windchill) suggest good prospects for successful application of AMORE. There are also reasons to be sceptical about AMORE as a general and comprehensive framework for BPR. As business information systems evolve from classical enterprise models that were effectively implemented with relational database technologies, they acquire the characteristics of reactive systems that have proved to be a major challenge for software engineering [Bro95, Bro97]. As approaches such as OPM acknowledge, software development for such systems is an activity in which change plays an essential and integral part. This motivates active models within a design-in change paradigm, where there is scope for the conception of abstract processes to be influenced by their proposed implementation. Whilst AMORE aspires to take greater account of the business domain than the process-centred design-in change paradigm of OPM.

Acknolwedgements

We are indebted to British Aerospace Systems, Sun Microsystems, Parametric Technology Corporation and the Engineering and Physical Science Research Council (M02675) for supporting the AMORE project. We would also like to thank Maurig Benyon and Steve Russ from the Empirical Modeling Laboratory at the University of Warwick for their invaluable contribution towards writing this paper.

References

Ale64 Alexander, C. Notes on The Synthesis of Form. Harvard University Press, 1964.
Ale98 Alexander, C. The Nature of Order. New York, Oxford University Press, 1998.
Bro95 Brooks, F. The Mythical Man-Month Revisited: Essays on Software Engineering. Addison-Wesley, 1995.
Bro97 Brooks, F. No Silver Bullet: Essence and Accidents of Software Engineering, Computer, Vol.20, No.4, pp.10-19, 1987.
Cer94 Cerpedes, F.V. Industrial Marketing: Managing New Requirements. Sloan Management Review, Vol. 35, pp. 45-60, Spring 1994.
CKO92 Curtis, B., Kelner, M.I. and Over, J. Process Modeling. Communications of the ACM., Vol. 35, No. 9, pp. 75-90, 1992.
FR00a Fernandes, K.J., and Raja, V. Business and Software Phase Synergy in a Re-engineering Environment. Proceedings of the 9th Annual Industrial Engineering Research Conference, Cleveland, Ohio, May 21-23, 2000.
FR00b Fernandes, K.J., and Raja, V. Incorporated Tool Selection System using Object Technology. International Journal of Machine Tools and Manufacture., Vol. 40, No. 11, pp. 1547-1555, 2000.
FRA00a Fernandes, K., Raja, V., and Antony, J. Knowledge Transfer using Publish Subscribe Technology. Proceedings of the Knowledge Management Beyond the Hype Conference, Aston University, July 2000.
FRA00b Fernandes, K., Raja, V., and Antony, J. Optimum Level of Goal Mapping in a Re-engineering Environment. Submitted for possible publication on 06/07/00.
FRM00 Fernandes, K.J., Raja, V.H., and McKinney, L. Knowledge Transfer in a Cross-Functional Environment. Proceedings of the Knowledge Management: Concepts and Controversies conference, University of Warwick, pp. 67, February 2000.
GF94 Gruninger, M. and Fox, M.S. The role of competency questions in enterprise engineering. Proceedings of the IFIP WG5.7 Workshop on Benchmarking - Theory and Practice, pp. 212-221, 1994.
Jam96a James, G. Intranets rescue re-engineering. Datamation, Vol. 42, pp. 37-45, Dec. 1996.
JEJ94 Jacobson, I., Ericsson, M., and Jacobson, A. The Object Advantage. Reading, MA: Addison-Wesley, 1994.
KR96 Kratz, N., and Rose, T. Modelling and analysing processes in production and administration. Computer-Assisted Management and Control in Manufacturing Systems, pp. 122-147, S.G Tzafeta, Ed. Berlin, Germany: Springer-Verlag, 1996.
LGJMTY97 Lee, J., Gruninger, M., Jin, Y., Malone, T., Tate, A., and Yost, G. PIF: The Process Interchange Format v.1.2. Technical Report, MIT Centre for Coordination Science, 1997.
MKJ98 Motwani, J., Kumar, A., and Jiang, J. Business Process Re-engineering: A Theoratical Framework and an Integrated Model. International Journal of Operations & Production Management, Vol. 18, No. 9/10, pp. 964-977, © MCB University Press, 0144-3577, 1998.
MR98 McKay, A., and Radnor, Z. A characterization of a business process. International Journal on Operations and Production Management., Vol. 18, pp. 924-936, 1998.
Ner92 Nerson, J.M. Applying Object-Oriented Analysis and Design. Communications of the ACM., Vol. 35, No. 9, pp. 63-74, 1992.
Pro00 ProModel, website address http://www.promodel.com.
Psl00 The Process Specification Language (PSL): Overview and Version 1.0 Specification" NIST Internal Report (NISTIR) 6459.
Sch92 Scheer, A.W. Architecture of Integrated Information systems: Foundations of Enterprise Modelling. Heidelberg, Germany: Springer-Verlag, 1992.
SPEDE SPEDE, website address http://www.spede.co.uk
UF96a Usher, J.M., and Fernandes, K.J. Dynamic Process Planning - The Static Phase. Journal of Materials Processing Technology, Vol. 61, pp. 53-58, 1996.
UF96b Usher, J.M., and Fernandes, K. A Two-Phased Approach to Dynamic Process Planning. Computers and Industrial Engineering, Vol. 31, No. 1&2, pp.173-176, 1996.
UF99 Usher, J.M., and Fernandes, J. An Object-Oriented Application of Tool Selection in Dynamic Process Planning. International Journal of Production Research, Vol. 37, No. 3, pp. 2879-2894, 1999.
Win00 WindChill. Website address, http://www.ptc.com/products/windchill/index.htm.
WPS00 Weber, H., and Padberg, J. and Sunbul, A. Evolutionary Development of Business Process Centred Architecture Using Component Technologies. Proceedings of the Fifth World Conference on Integrated Design & Process Technology, The Society for Design & Process Science, Texas, 2000.

Dr. Kiran Jude Fernandes is a Senior Research Fellow in the Warwick Manufacturing Group at the University of Warwick. He is an alumunus of the Walchand Institute of Technology, Mississippi State University and the Massachusetts Institute of Technology. After working for the National Aeronautics and Space Administration at Stennis Space Centre he moved to join the WMG to work in the area of Information Systems and Modeling.

Dr. Vinesh Raja is a Principal Research Fellow and the Head of the Information Technology Group at the University of Warwick. Vinesh is also incharge of the Object Technology Centre, the Sun European Manufacturing Centre of Excellence and the Collaborative Product Commernce Centres. He has been an active academic in the field of manufacturing information technology for over 18 years.

© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement.
ISSN: 1533-3825