A Dynamic Business Object Architecture for Supporting Strategic Management Planning

Kitty Shuk-Yee Hung

E-mail : k.hung@dcs.shef.ac.uk

URL : http://www.dcs.shef.ac.uk/~kitty

A dissertation submitted in fulfilment of the requirements for the University of Sheffield for the Degree of

Doctor of Philosophy

March 1999

Department of Computer Science

The University of Sheffield

~ Dedicated to my mother and to the memory of my late father ~

ABSTRACT

Business organisations are constantly facing competition. There is a growing awareness amongst many organisations that a strategic approach has to be adopted to retain competitiveness. Nowadays, information technology (IT) underpins the implementation of most business strategies. However, IT solutions frequently fail to deliver business benefits. One of the main causes of failure is the communication gap that exists between the business management and IT professionals. Whilst this problem continues to be the subject of extensive inter-disciplinary research, a reliable, generally applicable, low cost, low risk and an easy to implement solution, is yet to be found. The aim of this study is to examine the potential contribution how some new and emerging technologies may offer to bridging, or at least reducing this gap. To achieve this aim, a novel conceptual model, called Dynamic Business Object Architecture (DBOA), has been developed starting from the well known and already established concept of Strategic Management Planning (SMP). The SMP implementation is based on the combination of Object-Orientation (OO), Business Objects (BOs), the Business Object Architecture (BOA) and the Dynamic Systems Development Method (DSDM). An analysis of the reliability and applicability to business environment of DBOA was conducted it was then evaluated through an extensive case study carried out in the credit insurance sector.

The principal findings of the case study clearly demonstrated the capability of DBOA to reduce the communication gap significantly by ensuring the IT professionals retain their business focus throughout the development lifecycle. In addition, the DBOA minimised the risk of omitting any of the essential stages of the implementation process. Moreover, the DBOA provided a review mechanism for ‘continuous improvement’ of business performance, thus further enhancing the reliability of this approach. The case study provided an early indication that DBOA may also be generally applicable as its implementation required only a few relatively minor sector specific modifications. This particular finding supports the claim that DBOA can be expected to provide a low cost and an easy to implement solution to the communication gap problem. However, the case study also highlighted several difficulties encountered during the implementation of DBOA. The scepticism that often accompanies the introduction of new paradigms into organisations and the shifts in the organisational culture required for successful management of change are examples of areas that need to be addressed before the impact of DBOA could be maximised. Finally, the development of toolkit for automating the DBOA is identified as an area of possible research in the more immediate future and is aimed at further increasing its effectiveness.

LIST OF PUBLICATIONS

The following is a list of publications by the author of this thesis together with her academic and industrial supervisors during the tenure of her research study.

Hung, K and Linecar, P (1997). “Experiences in developing a small application using a DSDM Approach” in the Proceedings for The British Computer Society Software Quality Management 1997 Conference, 24^th-26^th March 1997, Bath, UK. Mechanical Engineering Publications Ltd., London. ISBN 1-86058-110-2, pp 165-178.

Hung K (1997). “Mind The Gap Please : The Semantic Gap Between Business and Software” in The British Computer Society Object-Oriented Programming and Systems Special Interest Group Journal. Issue 29, March 1997. British Computer Society, Swindon, UK, pp 8-11.

Hung K (1997). “Is There Life After Death?”: The Rejuvenation of Life Cycle in a Dynamic Business Object Architecture” in the Proceedings of The European Conference on Object-Oriented Programming (ECOOP 1997) PhDOOS Workshop, Jyvaskyla, Finland, 9^th-12^th June 1997. Springer, Berlin. ISBN 3-540-64039-8, pp 391-399.

Hung K, Sun Y and Rose T (1997). “A Dynamic Business Object Architecture for an Insurance Industrial Project” in the Proceedings of The Object-Oriented Information Systems (OOIS 1997) Conference, 10^th-12^th November 1997, Brisbane, Australia. Springer, London. ISBN 3-540-76170-5, pp 145-156.

Hung K (1997). “Modelling Business Information Management Systems with a Dynamic Business Object Architecture: An Approach and Implementation” in The 7^th Annual Business Information Technology Conference, 5^th-6^th November 1997, Manchester Metropolitan University, Manchester, UK.

Hung K and Patel D (1997). “Modelling Domain Specific Application Frameworks with a Dynamic Business Object Architecture (DBOA): An Approach and Implementation” in the Proceedings of The Object-Oriented Programming Systems Languages and Applications (OOPSLA) 1997 Conference Business Object Design and Implementation III Workshop, Atlanta, Georgia, USA, 5^th-9^th October 1997. Springer, London, ISBN 1-85233-108-9, pp 167-177.

Hung K, Simons A and Rose T (1998). “Can You Have It All? : Managing the time and budget against quality issue in a Dynamic Business Object Architecture Development” in the Proceedings of The British Computer Society Software Quality Management 1998 Conference, 6^th-9^th April 1998, Vrije Universiteit, Amsterdam, The Netherlands. Springer, London. ISBN 1-85233-021, pp 121-134.

Hung K (1998). “A Reusable Business Object Architecture Developed in a Dynamic Systems Development Method Life Cycle for Financial / Insurance Industries” in The British Computer Society Object-Oriented Programming Systems Special Interest Group Scholarship for the Advancement of Object Technology in the United Kingdom. (Source : http://oopsnl.ukc.ac.uk/oopsnl34. (Source : http://oopsnl.ukc.ac.uk/oopsnl username: oopsnl34 password: component).

Hung K, Simons A and Rose T (1998). “The Truth Is Out There?: A Survey of Business Objects” in the Proceedings of The 5^th International Conference on Object-Oriented Information Systems (OOIS) 1998, 9^th-11^th September 1998 at the University of La Sorbonne, Paris, France. Springer, London. ISBN 1-85233-04605, pp 183-200.

Hung K, Simons A, Cvetkovic S (1998). “A Dynamic Business Object Architecture For Supporting Strategic Management Planning” in The Object-Oriented Programming Systems Languages and Applications (OOPSLA) 1998 Conference Business Object Design and Implementation Workshop IV, 18^th-22^nd October 1998, Vancouver, Canada (Source : http://www.jeffsutherland.org/oopsla98/oopsla98_hung.html ).

Hung K (1998). “A Dynamic Business Object Architecture For Supporting Strategic Management Planning” at The Object-Oriented Programming Systems Languages and Applications (OOPSLA) 1998 Conference Doctoral Symposium, 18^th-22^nd October 1998, Vancouver, Canada (Source : http://cs.clemson.edu/~johnmc/oopsla/papers.html ).

Hung K, Simons A, Cvetkovic S (1998). “Implementing Business Strategies with a Dynamic Business Object Architecture: A Hot Issue Tackled by a Cool Approach” at The Institute of Electronic Engineers (IEE) Colloquium, 23^rd February 1999, Savoy Place, London, UK.

Hung K (1999). “A Dynamic Business Object Architecture For Supporting Strategic Management Planning” submitted to the Object Technology (OT) 1999 Conference Workshop, 29^th-31^st March 1999, Oxford, UK.

Hung K, Kraner, M and Cvetkovic S (1999). “A Dynamic Business Object Architecture For Bridging the Communication Gap Between Business Management and IT Professionals ” in the 2^nd International Conference on Managing enterprises, 18^th-20^th November 1999, Newcastle, Australia.

ACKNOWLEDGEMENTS

The past few years have been a ‘period of intensive discovery’ for me. Firstly, I would like to express my gratitude to my supervisors Dr. Tony Simons and Dr. Srba Cvetkovic at the Department of Computer Science, the University of Sheffield for supervising me in my third year of research study.

I also want to thank my former supervisors Dr. Dilip Patel and Dr. Yuan Sun at the School of Computing Information Systems and Mathematics, South Bank University for supervising me during the first and second years of my research, especially Dr. Patel for inspiring me in the research of Business Objects.

My heartfelt thanks to my industrial supervisor Mr. Tony Rose at CAD Consultants Ltd. (BTR plc group) who has given me enormous opportunities in participating in various IT projects at the company. Without their guidance and support, I wouldn’t have been able to fulfil my research goal.

This research would never have been possible without the scholarship funded by the BTR plc group generously extended to me during the past three years. Thanks to all the management team and the IT department staff at CAD Consultants Ltd. for their assistance in my case studies.

I am indebted to Mr. Graham Barrett for his valuable time and effort in contributing his ideas in the organisational strategies. I am greatly influenced by Dr. Srba Cvetkovic for his ‘clear thinking’. His ongoing motivation kept me never stop learning. Thanks to Mr. Antony Frey for his meticulous proof-reading of my thesis. Also thanks to all my research colleagues at the Research Lab 1 and the technical support staff at the Department of Computer Science for their tremendous help when I first transferred from South Bank to Sheffield.

Finally, I want to thank my mother and my sister Helena for their financial support and free accommodation during my stay in the UK. I also want to thank my brother Kenneth and my sister Fidelia for their endless love and encouragement throughout the tenure of my study.

DECLARATION

I hereby declare that no portion of the work referred to in this thesis has been submitted in support of an application for another degree or qualification of this or any other university or other institution of learning.

……………………………………………….

Kitty Shuk-Yee Hung

TABLE OF CONTENTS

List of Figures ……………………………………………………………………… 10

List of Tables ……………………………………………………………….……… 12

Key of Acronyms …………………………………………………………..…….… 13

CHAPTER ONE ; INTRODUCTION …………………………………………… 14

Background ………………………………………………………………… 14
Business Problems vs. Software Solutions ………………………………… 15
Bridging the Communication Gap ………………………………..………… 16
Motivation of the Investigation ……………………………………………… 16
Proposed Approach ………………………………………………………… 17
Scope of the Research ……………………………………………………… 18
Related Work ……………………………………….……………………… 18
- Usage Centric Approach …………………………………………… 18
- Business Process Reengineering …………………………………… 18
- Requirements Engineering …………………………….……..…..… 19
- Incremental Delivery ……………………………..…………..…..… 19
- Dynamic Systems Development Method ……………………..…..… 20
Drawback of the existing approaches ………………….……………..….… 20
Structure of this thesis ……………………………………………..…….… 20
Closing Remarks …………………………………………………..…….… 21

CHAPTER TWO : LITERATURE REVIEW ……………………………….… 22

Introduction …………………………………….………………….…….… 22
Strategic Management Planning ………………………….………..…….… 22
- Definition ……………………………………………….…….….… 22
- Driving force behind the SMP ……………………..…………….… 23
- Three levels of SMP …………………………….…………….….… 23
- Competitive advantage of SMP ………………………………….… 24
- SMP models and techniques ………………………….………….… 24
  - SWOT Analysis ………….…………………………….……… 25
  - PEST Analysis ……………………………..………….……… 25
  - Porter’s Five Forces Model ……………………….…….…… 26
  - Porter’s Generic Strategies …………………………….….… 26
  - Relationship Marketing ………………………………….…… 27
  - Porter’s Value Chain Analysis …………….…………….….… 28
  - Brand Strategy ………….……………………………….…… 30
  - Stakeholder Analysis ………….……………………….….… 30
- Summary of Information Content from the SMP

Models and techniques ………………………………………….… 30

Critique of SMP …………………………………………………… 31

Object-Oriented Analysis and Design Methodologies ……………….…… 31
- History of OOAD Development ………………………….………… 31
- Critique of OOAD Methodologies ………………………………..… 33
- UML Standard Notation …………………………………..……..… 33
Business Objects …………………………………………………………… 42

2.4.1 OMG’s definition …………………………………..……………… 43

Individual developers’ definitions ……………………….………… 44
Confusion of definitions ……………………………….…………… 45
A survey of Business Objects ……………………………….……… 46
- Introduction ……………………………………….….…….… 46
- Expectation ……………………….………….……….…….… 46
- Motivation ………………………………………………..…… 47
- Survey method ………………………………………………… 48
- Survey findings ………………..………………………….…… 49
- Survey evaluation ……………………………………………… 49
- Current status and future development ………………….…… 50
- Conclusion and further survey ………………………….…… 50
Business Object publications …………….………..…….………… 50

2.5 Business Object Architecture ……………………………………………… 53

The concept behind the construct …………………….……..…..… 53
Complexity management ….…………………………………..…… 53
Architecture reuse …………………………………………….…… 54

Critique of Business Objects and Business Object Architecture …..….…… 55
Dynamic Systems Development Method …………………………..….…… 56
- DSDM development environment ………………….………….…… 56
- DSDM project life cycle ……………………………………….…… 58
- Project management using DSDM …………………………….…… 58
- Experience gained from using DSDM ……………..…………….… 59
- Critique of DSDM ………………………………………………..… 60
Conclusion of Literature Review ……………..………………………….… 61
Closing Remarks ……………………………………………………….…… 62

CHAPTER THREE : DYNAMIC BUSINESS OBJECT

ARCHITECTURE DEVELOPMENT …………….….… 63

Introduction ………………………………………………………….…..… 63
Formation of a Business Object …………………………….……………… 63
- Business Strategic Level …………………………………………… 64
  - SMP Questionnaire ………………………………..……..… 64
  - SMP Interviews …………………………………………..… 67
  - Structure of an SMP ………………………………………… 68
    - Corporate Level – Low Cost Strategy ……………………..… 70
    - Competitive Level – Product Differentiation Strategy ……..… 71
    - Competitive Level – Product Efficiency Strategy ………….… 71
    - Competitive Level – Insurance Market Competitiveness Strategy 71
    - Operational Level – Customer Services Strategy …………..… 72
    - Operational Level – Human Resources Strategy ………….… 72
    - Operational Level – Information Systems Effectiveness Strategy. 72
  - SMP strategic factors and definitions …………………….….. 73
  - SMP Checklist Manual Assessment …………………………… 73

3.2.2 Business Process Level …………………………………………..… 75

ISO9000 Quality Manual Specification ………………..…..… 75
ISO9000 Standard Operating Procedure form filling instruction 76
ISO9000 Standard Operating Procedure objectives ……….… 78
ISO9000 Standard Operating Procedure criteria ………….… 78
Graphical representation of ISO9000 Standard

Operating Procedure ………………………………………… 79

Criteria for decomposing procedure ……………………….… 81
Change of procedure …………………………………..…..… 81

3.2.3 Object-Oriented Modelling Level ………………………………..… 81

3.2.4 Database Management System Level ……………………………… 82

3.3 Business Object Model …………………………………………………..… 83

3.4 Business Object Architecture …………………………………………….… 84

3.5 Dynamic Systems Development Method ………………………………..… 87

3.6 Integration of BOA and DSDM ………………………………………….… 87

3.7 Reuse Strategy ……………………………………………………………… 91

3.8 Closing Remarks …………………………………………………………… 93

CHAPTER FOUR : ANALYSIS OF THE DBOA APPROACH ……………..… 94

4.1 Introduction ……………………………………………………….………… 94

4.2 PEST Analysis …………………………………………………………….… 94

4.3 Moulding SMP Checklists to PEST Analysis ……….……………..……..… 97

4.4 Conclusions of Analysis …………………………….……….…………..… 98

4.5 Closing Remarks ……………………………………………………..…..… 99

CHAPTER FIVE : IMPLEMENTATION OF DBOA THROUGH

A CASE STUDY PROJECT …………………………..… 100

5.1 Introduction ……………………………………………………….………… 100

5.2 Project Initiation ………………………………………………………….… 100

5.3 Project Plan ………………………………………………………..……..… 102

5.4 Prototyping Strategy ……………………………………………………..… 104

5.5 DBOA Development Life Cycle Building Blocks …………………..…..… 104

5.6 Time-boxing ……………………………………………………………..… 106

5.6.1 Time-box 1 : Feasibility Study …………………………………..… 107

5.6.1.1 Joint Requirement / Joint Application Development …..…..… 107

5.6.1.2 SMP ‘Open-ended’ question’ Interviews .. …………………… 107

5.6.1.3 SMP ‘Closed’ question Checklist Manual Assessment …….… 113

5.6.1.4 Business Objectives …………………………..…………….… 114

5.6.1.5 Purpose and Scope ………………………………………….… 117

5.6.1.6 Project Requirements ……………………………………….… 119

5.6.1.7 Project Tools Selection …………………………..…………… 119

5.6.1.8 Project Estimation using Function Points ………………….… 120

5.6.2 Time-box 2 : Business Study ……………………………………..… 124

5.6.2.1 ISO9000 Procedure for ‘OCLAVI’ project …….…………….. 130

5.6.2.2 OO Modelling for ‘OCLAVI’ project ………………………… 147

5.6.3 Time-box 3 : Functional Prototype ………………………………… 147

5.6.3.1 Outcome from the Functional Prototype Session ……….…… 148

5.6.4 Time-box 4 : Design Prototype ………………………………….… 149

5.6.5 Time-box 5 : Implementation …………………………………….… 149

5.7 Post-Project Review ………………………………………………………… 150

5.7.1. Outcome from Post-Project SMP Checklist Manual Assessment ….. 150

5.7.2 Refined Function Points …………………………………………… 151

5.8 Evaluation of the Case Study ……………………………………….……… 152

5.8.1 From business strategies to implemented software ……………..… 154

5.8.2 Selection of project team members ………………………………… 156

5.8.3 Communication gap between business management

and IT professionals ……………………………………………..… 156

5.8.4 Joint Requirement Planning / Joint Application Development …… 157

5.8.5 Iterative prototyping …………………………………………….… 157

5.8.6 Business management involvement ………………………………… 158

5.9 Closing Remarks …………………………………………………………… 158

CHAPTER SIX : CONCLUSIONS ……………………………………………..… 160

6.1 Introduction ………………………………………………….……………… 160

6.2 Review of the research ……………………………………………………… 161

6.3 Review of DBOA approach ………………………………………………… 162

6.3.1 ‘S.M.A.R.T.’ evaluation criteria ……………………………..……… 162

6.3.1.1 ‘S’calable .. …………………………………………………… 162

6.3.1.2 ‘M’easurable . …………………………………………..….… 162

6.3.1.3 ‘A’chieveable …………………………………………..……… 162

6.3.1.4 ‘R’eusable …………………………………………………..… 163

6.3.1.5 ‘T’ime-manageable ………………………………….……..… 163

6.3.2 Difference from other Business Object models ………………….… 163

6.4 Limitations of DBOA …………………………………..……..…………..… 164

6.4.1 Pride versus honesty ……………………………………….…….… 164

6.4.2 Friction between business management and IT professionals …….. 165

6.4.3 Short- to medium- to long-term return on investment …………….… 166

6.4.4 Time-boxing syndrome ……………………………………….…..… 166

6.4.5 Work pattern and paradigm shifts to both business and IT ………… 167

6.5 Research Progress …………………………………………………………… 167

6.6 Further Research …………………………………………………………..… 168

6.6.1 Cultural shifts within organisation ………………………………… 168

6.6.1.1 Cultural Web Analysis ………………………………………… 169

6.6.1.2 Forcefield Analysis ………………………………………….… 170

6.6.1.3 Desired Cultural Web ………………………………………….. 170

6.6.2 Continuous Improvement …………………………………………… 172

6.6.3 Validation of SMP Checklists …………………………………….… 172

6.6.4 Customisation of SMP Checklists ……………………………….… 173

6.6.5 Automated tool to support DBOA ………………………………….. 173

6.7 Closing Remarks …………………………………………………………… 174

REFERENCES ………………………………………………………..…………… 175

Appendix A : Bibliography ………………………………………………..……… 187

Appendix B : A Survey of Business Objects Questionnaire ……….…………… 190

Appendix C : Results of the Survey of Business Objects …………………..…… 193

Appendix D : Invitation for SMP Interview ……………………………………… 205

Appendix E : Results of the SMP Interviews …………………………………..… 207

Appendix F : SMP Context Table with Definitions ……………………………… 225

Appendix G : SMP Checklist Manual Assessment Form …………….……….… 237

Appendix H : Results of the Pre-Project SMP Checklist

Manual Assessment ………………………………..……………… 250

Appendix I : Project Tools Selection Table ………………………………..…..… 263

Appendix J : User Interface Prototypes for ‘OCLAVI’ project ……………..… 267

Appendix K : Transcript of the Users New Requirements

from the Prototyping Session ………………..…………………… 272

Appendix L : Results of the Post-Project SMP Checklist

Manual Assessment ……………………………………………… 274

LIST OF FIGURES

Figure 2-1 Three Levels of an SMP …………………………………..……..… 24

Figure 2-2 Five Forces Model ………………………………………….….…… 26

Figure 2-3 Generic Strategies Model ………………………………….…….… 27

Figure 2-4 Relationship Market – Six Markets Model ………………………… 27

Figure 2-5 Value Chain Analysis Model ……………………………………..… 29

Figure 2-6 Summary of Information Content from the SMP

Models and Techniques …………………………………………..… 30

Figure 2-7 Example of a Use Case Diagram ……………………….…………… 34

Figure 2-8 Example of an Activity Diagram ………………………………….… 36

Figure 2-9 Example of a State Diagram ……………………………………….… 36

Figure 2-10 Example of a Class Diagram ………………………………………… 37

Figure 2-11 Example of an Object ……………………………………………..… 37

Figure 2-12 Example of a Sequence Diagram …………………………………… 39

Figure 2-13 Example of a Collaboration Diagram ……………………………..… 40

Figure 2-14 Example of a Component Diagram ……………………….….…..… 41

Figure 2-15 Example of a Deployment Diagram ………………………………… 42

Figure 3-1 Four Levels of a Business Object ……………………………..….… 64

Figure 3-2 The Three Levels of SMP ……………………………………..…… 68

Figure 3-3 Flowchart Representing ISO9000 Standard Operating

Procedure for Business Processes ………………………………..… 80

Figure 3-4 Business Object Model ……………………………………………… 83

Figure 3-5 Business Object Architecture ……………………………………..… 86

Figure 3-6 Dynamic Business Object Architecture …………………………..… 89

Figure 3-7 Reuse Library ……………………………………………………..… 92

Figure 4-1 Impact/Probability issues in Political Environment ……………….… 95

Figure 4-2 Impact/Probability issues in Economic Environment ……….……..… 96

Figure 4-3 Impact/Probability issues in Social Environment …………..……..… 96

Figure 4-4 Impact/Probability issues in Technological Environment …………… 97

Figure 5-1 DBOA Development Life Cycle Building Blocks ……………….… 105

Figure 5-2 Time-boxing ………………………………………………….…..… 106

Figure 5-3 Structure of CAD’s E-Commerce Project Conceptual

Model ……………………………………………………………..… 120

Figure 5-4 Flowchart for ‘OCLAVI’ project (Part A: For CAD’s customer) ..… 129

Figure 5-5 Flowchart for ‘OCLAVI’ project (Part B: For CAD’s staff) ……..… 130

Figure 5-6 Use Cases and Actors Diagram for ‘OCLAVI’ project ….……….… 132

Figure 5-7 Use Cases and Objects Diagram for ‘OCLAVI’ project …………… 133

Figure 5-8 Complete Use Cases Model for ‘OCLAVI’ project ……..……….… 134

Figure 5-9 Business Use Cases and Business Objects for ‘OCLAVI’ project ..… 135

Figure 5-10 Activity Diagram for ‘OCLAVI’ project …………………………… 137

Figure 5-11 State Diagram for ‘OCLAVI’ project ……………………………..… 138

Figure 5-12 Class Hierarchy Diagram for ‘OCLAVI’ project ……………………. 141

Figure 5-13 Sequence Diagram for ‘OCLAVI’ project …………………………. 144

Figure 5-14 Collaboration Diagram for ‘OCLAVI’ project …………..……..….. 146

Figure 6-1 Cultural Web Analysis for CAD ………………………….………… 169

Figure 6-2 Forcefield Analysis based on CAD’s Cultural Web ………….…..… 170

Figure 6-3 Desired Cultural Web for CAD …………………………………..… 171

LIST OF TABLES

Table 3-1 Strategic Management Planning ‘Open-ended’

Questions Form ……………………………………….……….…… 67

Table 3-2 SMP Checklist Manual Assessment ‘Closed’

Question Form ……………………………………………………… 74

Table 3-3 ISO9000 Standard Operating Procedure Form

(with instructions) …………………………………………………… 78

Table 5-1 DBOA Project Plan ………………………………………………… 103

Table 5-2 Strengths and weakness of organisation ………………………….… 108

Table 5-3 Long- and short-term challenges ……………………………….…… 109

Table 5-4 Organisational aims and objectives ……………………………….… 109

Table 5-5 Factors to improve products/services …………………………..…… 110

Table 5-6 Factors to maintain market position ……………………..……..…… 110

Table 5-7 Competitions and competitors ……………………………………… 110

Table 5-8 Relationship with customers …………………………..…….……… 111

Table 5-9 Human resources ……………………………………………….…… 112

Table 5-10 Technology’s roles and changes ………………………………….… 113

Table 5-11 Function Points ……………………………………………..….…… 123

Table 5-12 ISO9000 Procedure for ‘OCLAVI’ project ……………….…….…. 128

Table 5-13 Comparison results between Pre-project and Post-project

SMP Checklist Manual Assessment ……………………………..… 151

Table 5-14 Refined Function Points ……………………………..…………..… 153

KEY TO ACRONYMS

ADE Application Development Environment

BO Business Object

BOA Business Object Architecture

BOMA Business Object Management Architecture

BODTF Business Object Domain Task Force

CAD CAD Consultants Ltd.

CASE Computer Aided Software Engineering

CORBA Common Object Request Broker Architecture

COTS Commercial Package Off The Shelf

DBMS Database Management Systems

DBOA Dynamic Business Object Architecture

DSDM Dynamic Systems Development Method

EDI Electronic Data Interchange

FAQ Frequent Asked Questions

HTML Hypertext Modelling Language

HTTP Hypertext Transfer Protocol

IS Information Systems

ISO International Standard Organisation

IT Information Technology

JAD Joint Application Development

JPG Joint Photographic Expert Group

JRP Joint Requirement Planning

MOSES Modelling Object-Oriented Software Engineering System

MVC Model View Controller

NCM Nederlandsche Credietverzekoring Maatschappij NV

OCLAVI Online Credit Limit Application Via the Internet/Intranet

OMG Object Management Group

OML OPEN Modelling Language

OO Object-Orientation

OOAD Object-Oriented Analysis and Design

OOPSLA Object-Oriented Programming Systems Languages and Applications

OPEN Object-Oriented Process Environment and Notation

PEST Political Economic Social Technological

RAD Rapid Application Development

REA Resource Enterprise Application

ROI Return on investment

SMP Strategic Management Planning

SNA System Network Architecture

SOMA Semantic Object-Oriented Modelling Approach

SWOT Strengths Weaknesses Opportunities Threats

UML Unified Modelling Language

URL Uniform Resource Locator

VCA Value Chain Analysis

WWW World-Wide-Web

~ Being beaten is often a temporary condition, giving up is what makes it permanent ~

(Marilyn Vos Savant)

CHAPTER ONE : INTRODUCTION

This chapter will introduce the areas selected for research. Research questions of how business organisations find it difficult to justify their investment in the information technology (IT) against their business benefit will first be identified. This will be followed by an analysis of the contrast and incompatibility between business problems and software solutions. The communication gap between business management and IT professionals has attributed significantly to this problem. An investigation into possible ways of bridging this gap will be discussed. A solution is then proposed to address the communication problem. The scope of the research work will be presented, and other related research work will be compared and evaluated.

1.1 Background

In the ever changing and competitive world of business, organisations are facing increasing challenges both internally such as staff skill shortages, and externally such as marketing competitiveness. Organisations compete to survive, or to position themselves as leaders in their particular sectors. To achieve this, various steps and measures are being taken by organisations which involve changes, at different degrees, in the structures and/or people in organisations. There is a growing awareness amongst many organisations that a strategic approach has to be adopted to retain competitiveness. Many organisations have admitted that to achieve results, it is their primary task to take strategic approaches to determine their business directions and to take proper steps to effect changes. It is an experience of many organisations that business strategies can help them handle changes and achieve their business goals more successfully.

Although the principles of business strategies may look straightforward, achieving them is extremely difficult. Once they are applied to the actual day-to-day business operations, their complexity prevents many organisations from implementing them successfully and highly skilled staff to monitor the transition are required. However, according to Ovum’s Management Report [source : http://www.ovum.com ], there is currently a shortage of management cum operations professionals who possess the skills to monitor the smooth transformation from business strategies to business operations and to ensure the business operations can support the business strategies.

1.2 Business Problems vs. Software Solutions

Recognising the fast pace of advancement of information technology (IT), an increasing number of organisations have started adopting IT to assist them in implementing their business strategies. IT is also seen by some organisations as a means of alleviating the skill shortage problems experienced in terms of human expertise. Many companies have therefore increased their investment in IT. IT thus underpins the implementation of most business strategies.

However, to the disappointment of many organisations in the user communities, current IT practices are still emphasising software performance. Most IT professionals focus on software analysis and design methods, programming and user interface techniques rather than on the business situation. As a result, they are delivering ‘software products’ rather than delivering ‘business solutions’. Hence the expectations from the business remain severely neglected. Consequently, ‘IT solutions’ frequently fail to deliver business benefit. There are many reasons causing software systems or projects’ failure. To name a few; wrong analysis, bad design, programming bugs, lack of testing before system goes live, over-budget causing companies to abandon the projects, poor project management in terms of human resources allocation or time management, misunderstanding between business users and IT developers. This research focuses on the communication gap between business management and IT professionals. Brown [Brown et al 1996] suggests that since IT professionals are still very much focused on software products, they may not be able to understand the real business problems, and thus may fail to deliver business solutions. Whilst this communication problem continuous to be the subject of extensive interdisciplinary research, a reliable, generally applicable, low cost, low risk and an easy to implement solution, is yet to be found.

Nowadays, IT is commonly used in data collection in the statistics on marketing research about customers, suppliers and competitors. The maximum strength IT can show is playing a decision-support role only. Such effort cannot alone harness the achievement of business objectives. When organisations embark on using IT in planning their business strategies, they face difficulties and usually fail to gain the benefit they might have expected. As a result, organisations have found it difficult to justify their investment in IT against their business benefit. Identification of the business areas where IT can contribute to is strategically important for organisations as organisations can use this way to justify their investment in IT against business benefits. However, the integration of business and IT strategies is the most difficult problem faced by many organisations.

1.3 Bridging the Communication Gap

The underlying problem of the communication gap as described in Section 1.2 may be improved by a control mechanism that has the ability to:

encourage business management and IT professionals to have mutual understanding and mutual consultation with each other;
effectively link the business strategies directly to the day-to-day business operations;
reflect the way that the day-to-day business operations match the business strategies;
ensure that the day-to-day business operations are properly defined in the software applications;
review the effectiveness of the software against the business performance;
review the business performance against business objectives.

1.4 Motivation of the Investigation

The control mechanism, as discussed in Section 1.3, has motivated the author to study how it can contribute to the bridging of communication gap between business management and IT professionals. Next, the techniques that could be used to support this control mechanism are investigated. This research is aimed at exploiting some new and emerging technologies that are neither mature nor established, to examine their novelty so as to see whether they could tackle this fundamental but well known problem, that has traditionally plagued various business sectors.

This research is greatly inspired by Object-Oriented (OO) technology in the way it handles the multitudinous aspects of software development. However, the current OO approach is still predominantly software-driven to the exclusion of tackling the business issues. Hence this research has also investigated Business Objects (BOs) and Business Object Architecture (BOA) which have been elevated from a software-driven level to a business abstraction level [OMG 1995]. Dynamic Systems Development Method (DSDM), a project management technique, has also been examined to see how it could be used to improve the interaction between business management and IT professionals.

Equally, the structure and clarity of business strategies are regarded as vitally important when interpreted and explained by business management to IT professionals. This ‘raison d’être’ has prompted an investigation into the study of organisational Strategic Management Planning (SMP).

1.5 Proposed Approach

A Dynamic Business Object Architecture (DBOA) is proposed in this thesis. DBOA, integrating BOs, BOA and DSDM, is a novel conceptual model which is presented as a tool for supporting organisational SMP. The techniques it provides seek to bridge the communication gap between business management and IT professionals. The key linking abstraction in the DBOA approach is a new, coarser-grained and semantically richer notion of BOs together with associated management processes, an iterative prototyping life cycle and substantial business management involvement.

The unifying concept of a BO contains four levels of activities. The first level is the Business Strategy Level where the organisational business situation is captured, business performance is measured and business strategies are identified. The second level is the Business Process Level where business processes are annotated to support specific strategies through the process improvement technique using the International Standard Organisation (ISO) 9000 Standard Operating Procedure. The third level is the Object-Oriented (OO) Modelling Level to model the business processes into software development using the Unified Modelling Language (UML) standard Notation. The fourth level is the Database Management System (DBMS) Level – a substrate of the existing database systems to be interfaced with the OO layer. Business strategies and business processes are specified in a top-down fashion, while the related object components are simultaneously specified from bottom-up.

Business Object Architecture (BOA) is a framework within which individual BOs are related according to their common strategies, processes, objects and databases as a whole, stored in their respective repositories, thereby promoting the reuse of BOs. BOA also contains patterns which advise on how to combine basic components which are used to model the business problems and build the system within a business domain.

Dynamic Systems Development Method (DSDM), a project management technique based on the rapid application development (RAD) approach, is used to run DBOA project. DSDM provides an iterative prototyping life cycle with substantial business users’ involvement.

It is anticipated that the contribution of DBOA would be to provide a tool for IT professionals, notably inexperienced consultants and developers, to use the DBOA to practise their profession more proficiently in a relatively short period of time. This may help combat the skill shortage of human experts as discussed in Section 1.1.

1.6 Scope of the Research

The scope of the research is to provide an approach to:

build a framework to implement organisational business strategies;
define business processes underpinning the business strategies;
model these business processes into data manipulated object components using the OO technique;
review the effectiveness of the software development against the business performance;
enhance the potential of object reuse in terms of the benefits of improving maintainability, cost reduction and time saving.

1.7 Related Work

In recent years a number of new research areas have emerged concerning the improvement in business performance that can be achieved by bringing closer together business users and software developers. Those attempts have focused on making software more ‘user’ oriented. Business users are invited to participate actively in software development activities. The objective is to ensure that software delivered meets the business requirements. The literature abounds in more or less the interaction between the business users and software developers, but they have quite different motivations from the approach proposed in this thesis. The following sub-sections will cite some of this work and evaluate its effectiveness if used for implementing business strategies.

Usage Centric Approach

The Usage Centric Approach [Constantine 1996] emphasises the user’s needs but only addresses the improvement of Human Computer Interface (HCI) by better eliciting user interaction requirements; and does not address how software can better support business strategies.

1.7.2 Business Process Reengineering

Business Process Reengineering (BPR) is defined by Hammer and Taylor [Hammer et al 1995] as the fundamental rethinking and radical redesign of business processes to achieve improvements of business performance in regards to costs, service and speed. However most of the time, business processes do not accurately reflect business strategies. Due to the absence of linkage between these two levels, it may be

difficult to ensure that reengineered business processes would meet business goals. Jacobson [Jacobson et al 1994] sees BPR as a way to take a comprehensive view of the entire existing operations and redesign it in a way that uses a new technology to serve the said purpose. However if the existing operations do not match the business objective, business goals may not be achieved no matter what new technology is used. This is the limitation of BPR. BPR lacks a clear link with business strategies and hence may fail to highlight the key strategic factors which may contribute to the achievement of business objectives.

1.7.3 Requirements Engineering

Requirements Engineering (RE) is the elicitation, definition, modelling, analysis, specification and validation of what is needed from a computer system. It is a process which draws on techniques from software engineering, knowledge acquisition, cognitive science and social science to improve software engineering practice [Thome 1993].

Rolland [1996] proposes a framework to identify the business and its requirements. This architectural framework contains models of business structure, organisational information, system life cycle and different dimensions of business processes. RE framework is designed to encourage software developers to appreciate business needs. However such an approach only concentrates on the operational level rather than the business strategic level. If business strategies are not clearly reflected by business operations, business objectives may not be achieved.

1.7.4 Incremental Delivery

Hsia [Hsia et al 1996] proposes an Incremental Delivery (ID) technique to effectively divide a software system into partial, but individually operational components which can be delivered to customers on an incremental basis.

The ID decomposition philosophy is a technique of partitioning a software system from the utility point of view (i.e., the external view). The external view allows a system to be grouped into usable subsystems (called increments). The incremental delivery philosophy would significantly modify software development (requirement analysis, system partitioning and system integration), giving it a user-centred perspective, thus encouraging user involvement. Although the communication gap between IT professionals and business users may improve through the incremental process, it is still on ‘application-specific’ rather than ‘enterprise-wide’ approach. IT professionals may still have difficulties in identifying the overall business objectives which the software should be designed to help in achieving.

1.7.5 Dynamic Systems Development Method

The Dynamic Systems Development Method (DSDM) is a management philosophy for the Rapid Application Development (RAD) [Martin 1991]. It claims: “…To be suitable for urgent business needs in a rapidly changing world…” “…System that delivers business advantage rapidly and adaptively…” [DSDM 1995] [DSDM 1997]. DSDM emphasises that user involvement is imperative, and that satisfying business requirements is more important than the quality of system operational characteristics. In DSDM, all changes are reversible and estimates should be tight from the outset with frequent deliverables through the iterative prototyping life cycle. However the above two techniques (frequent deliverables and iterative prototyping) only provide a project management approach. Neither of them takes into account enterprise-wide business goals. Likewise, DSDM lacks actual software development techniques.

1.8 Drawback of the existing approaches

Despite the fact that the User Centric Approach, Requirements Engineering, Business Process Reengineering, Incremental Delivery and Dynamic Systems Development Method all emphasise business users’ involvement, no model is used to implement business strategies. Reaching the business strategic level is crucial given that business management have an opportunity to describe their business situation and business goals to IT professionals. Software would more likely be able to support the business goals. The difference between DBOA and the other approaches as mentioned in Section 1.7 is that DBOA uses a software modelling technique coupling with project management technique to implement business strategies. Software applications developed in this way therefore would become more realistic as business solutions.

Structure of this thesis

The rest of the thesis is organised as follows: Chapter two gives a critique of the literature reviews relevant to the research, in which the adaptation of the described technologies to the present study is examined and analysed. Chapter three proposes a Dynamic Business Object Architecture (DBOA) combining the techniques discussed in Chapter two. Chapter four presents a case study applying DBOA in a business environment. Chapter five summarises the preceding chapters, presents the conclusions and recommends areas as possible fields for further research.

1.10 Closing Remarks

This chapter has described how business organisations cope with competitions, and challenges they face constantly. It has also addressed how organisations adopt strategic approaches to help them become competitive. The complexity of business strategies has prompted some organisations to adopt information technology (IT) to support their Strategic Management Planning (SMP).

However the communication gap between business management and IT professionals has failed to enable software development to effectively support organisational SMP. A mechanism to bridge this gap is required. This mechanism must enable IT professionals to focus on business issues such as organisational aims and objectives and their business strategies. Hence IT professionals would be able to develop software more effectively to support the business goals.

Various researches have attempted to address this problem but a reliable, generally applicable, low cost, low risk and an easy to implement solution, is yet to be found. One of the reasons for this failure is that the ‘application-wide’ approach from the existing research is obviously insufficient to support the ‘enterprise-wide’ SMP. A DBOA integrating the techniques of BOs, BOA and DSDM, is proposed in an attempt to bridge this communication gap by ensuring IT professionals’ focus on business problems rather than solely on software performance. DBOA also provides a review mechanism to evaluate the resulting software against business performance.

The next chapter will present a literature review covering SMP, OO Analysis and Design, BOs, BOA and DSDM. A critique of literature review will also be presented.

~ You do what you can for as long as you can, and when you finally can’t, you do the next best thing. You back up but you do not give up ~

(Charles Yeager)

CHAPTER TWO : LITERATURE REVIEW

2.1 Introduction

This chapter will present a critical analysis of the work conducted by other researchers / authors as it relates to this research. It will cover the history and background of Strategic Management Planning (SMP). An account of various Object-Oriented (OO) Analysis and Design Methods will be given. The current development and future prospect of Business Objects (BOs) and Business Object Architecture (BOA) will be investigated. A project management approach called the Dynamic Systems Development Method (DSDM) will be examined and discussed. In summarising the literature review findings, the incompleteness of individual technology to support the goal of this research are revealed; therein lies the necessity of combining these technologies together to offer a complete solution to meet the research goal.

2.2 Strategic Management Planning

2.2.1 Definition

Hemal [1997] defines ‘strategy’ as a management tool which could assist organisations to accomplish certain goals to become more competitive and successful.

Johnson [Johnson et al 1997] particularly points to the fact that organisations make strategic decisions and that ‘Strategic Management Planning’ (SMP) should occur at different levels. Johnson suggests that strategic decisions should be concerned with the scope of an organisation’s activities, environment, resources, values, goals, expectations, directions and implications for change. It also reckons that the complexity of SMP will, to a certain extent, hinder this progress. Taylor [1995] notes that as SMP is increasingly adopted, the complexity of managing the planning process will foster an increased reliance on software systems.

Nowadays, computer-based information system support in a business environment is concentrated mainly in the areas of database management, information retrieval and documentation. There are many software tools which have been developed for decision-support. Even so, there is no direct linkage between these decision-support tools and the actual application development environment (ADE).

2.2.2 Driving force behind the SMP

In this section, various methods and models for SMP will be examined. The purpose of this is to construct an SMP framework to be used by IT professionals to understand organisational business situations, measure business performance and identify business strategies. Hence IT professionals would be encouraged to direct their focus onto business issues first when developing software applications to support the business.

SMP originates in the work on strategic information systems invoked by Porter and Millar in the eighties [Porter 1980] [Porter et al 1985]. Porter’s models have since been widely adopted and have been extended by other strategists throughout the nineties from [Earl 1989] and [Knights et al 1991] to more recently [Rockart et al 1996] and [Pepard et al 1996]. Many organisations have been persuaded that there is a need to change their existing operations in order to either achieve competitive advantages, or (in the worst scenario) to survive [Edward et al 1997]. The driving force behind SMP is to sustain an organisation both in terms of competitiveness and profitability so that it can avoid being forced out of business or losing out in the market place.

2.2.3 Three levels of SMP

Faulkner [Faulkner et al 1995] has observed that most organisations plan their strategies at three levels namely:

(i) Corporate Strategy Level : decisions are made regarding the overall business objectives based on the kind of business and characteristics of the organisation as a whole. Corporate Strategy is largely concerned with the logic and rationale of the corporation.

(ii) Competitive Strategy Level : decisions are made which affect the competitive position of the organisation. Competitive Strategy is essentially concerned with the competition of products and services in the marketplace, leadership and management and, local and global presence. This strategy focuses on external environment.

(iii) Operational Strategy Level : decisions are made corresponding to the above two levels, but with more influence on day-to-day business operations. Operational

Strategy is concerned with interpreting the role of a functional sector or a department in delivering the Competitive Strategy. This strategy focuses on internal activities such as sales and marketing, research and development, finance and accounts, recruitment and training.

Figure 2-1, adopted from [Faulkner et al 1995] shows how different concepts of SMP take place at three levels.

Figure 2-1 : Three Levels of SMP [Faulkner et al 1995]

2.2.4 Competitive Advantage of SMP

Competitive advantage in either cost or differentiation of products and services is a function of a company’s Value Chain. Porter [1985] defines the Value Chain is the name given to a sequence of process steps, each of which requires a set of resources, has a duration, and adds a value to the chain in order to satisfy an organisational goal. In order to maximise the utilisation of resources, VCA specifies reasons for a particular activity to be undertaken. A company’s cost position reflects the collective cost of performing all its value activities relative to its rivals. Each value activity has cost drivers that determine the potential sources of cost advantage. Over and above cost, many of a company’s activities, not just its products and/or services, contribute to differentiation. As an example, customers’ needs, depend not only on the impact of company’s services but also on company’s other activities such as quality assurance and customer relationship.

2.2.5 SMP models and techniques

Authors of various publications on SMP have used a wide range of models and techniques to assist readers in navigating through the complexity of understanding the organisational environment in which they find themselves. These models and techniques have provided organisations with the frameworks they need to understand the challenges faced by them when setting their business goals. The following sub-sections will explain in detail eight of the most commonly used techniques.

2.2.5.1 SWOT Analysis

SWOT stands for ‘Strengths’, ‘Weaknesses’, ‘Opportunities’ and ‘Threats’. These four factors contribute to an organisation’s self-examination of its business scenarios. Strengths and weaknesses usually apply internally within an organisation. Opportunities and threats usually relate to elements and events outside the organisation which have an impact on its business.

2.2.5.2 PEST Analysis

PEST stands for ‘Political’, ‘Economic’, ‘Social’ and ‘Technological’ forces. PEST Analysis is used to identify the major macro environmental forces.

The processes are listed as follows:

Political Environment

This environment comprises of laws, government agencies and pressure groups that can influence and/or limit an organisation concerned.

Economic Environment

The profitability of an organisation largely depends on its types of business and sales volume. The available purchasing/consumption power from the customers also depends on individual income, prices charged, savings, debts and credit availability. For this reason, a company must pay attention to major economic trends, especially in the business environment in relation to the field of individual spending patterns.

Social Environment

The society in which people live tend to grow shapes of their beliefs, values and norms. People vary in the relative emphasis they place on self-gratification. Organisations should develop their strength and edge in accordance with the social changes.

(iv) Technological Environment

In the present climate of rapid technological advancement, many organisations are adopting information technology as a solution to business problems. Often organisations feel that they will be left behind if they do not adopt the latest technology, even if only, in many cases, for psychological reasons.

2.2.5.3 Porter’s Five Forces Model

Porter’s Five Forces Model [Porter 1980] is based on five competitive forces which collectively determine industry profitability namely: (1) power of buyers; (2) power of suppliers; (3) threat of new entrants; (4) threat of substitute products; and (5) rivalry amongst existing competitors.

Figure 2-2 : The Five Forces Analysis Model [Porter 1980]

As illustrated in Figure 2-2, these five forces can assist decision-makers in deciding whether it is profitable to enter or leave an industry. The main force comes from competitive rivalry. Other forces come from suppliers (suppliers’ pricing), buyers (buyers’ bargaining power), potential entrants (slicing off market shares) and substitutes (reducing market size). The strength of the forces determines the overall profitability of the company. The key issues in every business organisation’s mandate as suggested by Porter [1980] should contain profitability, survival, growth and success. Through this mechanism, organisations can appreciate the ways in which competition affects strategy and strategy affects competition.

2.2.5.4 Porter’s Generic Strategies

The Generic Strategies Model, as illustrated in Figure 2-3, consists of :

Cost Leadership

To perceive leadership in cost effectiveness;

Differentiator

To differentiate area of work from the organisation’s competitors in the market;

Focus

To focus on products/services offered and also on targeting customers.

Figure 2-3 : Generic Strategies Model [Porter 1985]

2.2.5.5 Relationship Marketing

Relationship Marketing is a strategy to establish a good relationship not only with customers but also with the whole array of stakeholder groups such as shareholders, government bureaucracies and employees, to achieve profit maximisation. These stakeholder groups all have a direct influence on organisations [Payne 1995]. As illustrated in Figure 2-4, there are six elements of Relationship Marketing:

Figure 2-4 : Relationship Marketing – Six Markets Model [Payne 1995]

Customer Marketing: direct contact with customers;
Referral Marketing: establish a network of associates, acquaintances and even customers;
Supplier Marketing: maintain a good relationship with suppliers in order to obtain competitive purchase price;

Recruitment Marketing: attract good candidates to join the organisation to improve quality of staff;
Influence Marketing: influence the government, industrial regulators or general public;
Internal Marketing: retain both customers and employees. Customers bring income to organisation. Employees generate income for organisations. Good quality and experienced staff are valuable to organisations and difficult to replace. A high percentage of staff turnover is not a good sign.

2.2.5.6 Porter’s Value Chain Analysis

The Value Chain Analysis (VCA) can be used to explain where value is being added for both internal users and customers of the organisation in terms of: (1) area; (2) quantity; (3) cost; and (4) outcome. As illustrated in Figure 2-5, a credit insurance company’s organisational structure is used as an example to depict the VCA. The VCA is a method of relocating resources to maximise their utilisation. The VCA can be used to model the apparent attractiveness of an organisation to its customers and suppliers. This is based on its public performances. For example, how customers have reacted historically to the services provided or how suppliers’ attitudes have changed in the business relationship. In particular, the VCA is strong in dividing an organisation’s main activities, thus making it easier for people to prioritise tasks, especially in information processing (capture, manipulate and channel data) which is dominant and critical for the effective performance of activities within an organisation.

VCA has unbundled an organisation’s structure into three main areas of concern and five major activities. The three main areas are: (1) Human Resources Management; (2) Technology Development; (3) Procurement. The five major activities are: (1) Inbound Logistics; (2) Operations; (3) Outbound Logistics; (4) Marketing and Sales; and (5) Services. These three areas and five activities intersect with each other in a matrix table format to produce different attributes. The matrix table illustrates at a glance what elements are involved in a particular activity within a particular area. For instance, the attributes of the Inbound Logistics activity in the area of Technology Development would be electronic based quotation and application form. For this, the value chain will link to those software/hardware suppliers providing the required services/equipment. In the area of procurement in the activity of operations, there is no element involved because operations refer to organisational internal activities.

Figure 2-5 : Value Chain Analysis Model

Brand Strategy

Brand Strategy is a technique used to highlight the value of customer perception and the loyalty this can bring once a brand image or goodwill has been established.

Stakeholder Analysis

Stakeholder Analysis is a technique to encourage the user to consider the impact that can be exerted on the organisation by all those ‘stakeholders’ who have influence on the organisation’s success. Its power lies in providing a framework to identify those unusual influences that are likely to be ignored under other circumstances.

Summary of Information Content from the SMP Models and Techniques

Figure 2-6 summarises the information content generated from various SMP models and techniques.

Figure 2-6 : Summary of Information Content from the SMP Models and Techniques

There are four targeting points namely: (1) Product; (2) Customer; (3) External; (4) Internal and eight strategies namely: (1) SWOT Analysis; (2) PEST Analysis; (3) Five Forces Model; (4) Generic Strategies; (5) Relationship Marketing; (6) Value Chain Analysis; (7) Brand Strategy; (8) Stakeholder Analysis. Different strategies cater for different targeting points. For instance, Relationship Marketing, Value Chain Analysis and Generic Strategies are considered to be suitable for using in the Product targeting point. Brand Strategies and Stakeholder Analysis are ideal for the Customer targeting point. Five Forces Model and PEST Analysis would be suitable for the External targeting point. SWOT Analysis would be suitable for the Internal targeting point.

2.2.7 Critique of SMP

In an increasingly competitive business world, SMP is considered to be of vital importance to many organisations as it can help them adapt to changes. Generally speaking, whilst many organisations believe SMP can help them become more competitive and successful, as it stands, it is based solely on theoretical principles. For example, such terms as ‘understanding customers’, ‘awareness of new entrants’, ‘knowing competitors’, ‘determining marketing’ and ‘estimating outcome’ are very vague. The complexity of SMP has posed some difficulties when it comes to its application in a practical way to business operations. There is still no direct linkage between business strategies and business operations, let alone the linkage between business strategies and the actual software applications. Although some organisations have employed IT to help them set their SMP, IT has so far only provided support at the level of assisting in conducting marketing surveys, data manipulation and information retrieval. IT still cannot directly support business management to implement their SMP. Business management can only use these resources as references in their decision making. Eventually they still have to use their own effort to determine the actual directions.

The following section will investigate software development issues in the area of Object-Oriented technology to see whether this technology can provide the requisite link with the business issues.

2.3 Object-Oriented Analysis and Design Methodologies

2.3.1 History of OOAD development

In recent years, Object-Orientation (OO) has become one of the most popular approaches in the development of business applications. Many software developers regard OO to be more effective than the conventional Structured Methodologies [Graham 1994], [Booch 1994], [Henderson-Sellers et al 1996]. Taking into account the distinct features of OO (such as reusability, portability, maintainability, encapsulation, inheritance and polymorphism), it is generally accepted within the software community that it can assist developers in modelling a more versatile framework that can handle complex systems [Fowler 1997], [Gamma et al 1995].

From the early eighties people started applying engineering disciplines to software system development, calling this software engineering [Somerville 1989]. In software engineering, it is a discipline that planning and methodology should be used before programming. OO provides methods in analysis, design and programming to enhance the potential of reuse not only at the source code level but also at the design level. OO modelling design methods and OO programming languages are also considered to make a software application easier to maintain than structured methodologies and procedural programming languages.

Since the late eighties, some of the most popular methodologies used within the OO community include: OO analysis and design (OOAD) [Booch 1994], the Object-Oriented Modelling Technique (OMT) [Rumbaugh et al 1991], the Object-Oriented Software Engineering (OOSE) [Jacobson et al 1994], Shlaer/Mellor Object-Oriented Analysis (S/M OOA) [Shlaer et al 1988], Coad/Yourdon Object-Oriented Analysis (C/Y OOA) [Coad et al 1991] and OORam [Reenskaug 1996].

In the late nineties the trend has been towards the ‘unification’ of different methodologies into one single method. The Unified Modelling Language (UML) [Booch et al 1998] [Rumbaugh 1996] is the integration of Booch, OMT and OOSE.

Object-Oriented Process, Environment and Notation (OPEN) and the OPEN Modelling Language (OML) [Henderson-Sellers et al 1997], [Firesmith et al 1997], [Henderson-Sellers et al 1998] represent the integration of the Semantic Object-Oriented Modelling Approach (SOMA) [Graham 1994], Modelling Object-Oriented Software Engineering System (MOSES) [Henderson-Sellers 1993] and the Firesmith approach [Firesmith 1993].

Both ‘unified’ methodologies have competed to become a standard OO methodology. Both have claimed to contain ‘rich ingredients’ of design notation in their methodologies as well as programming language independence (early methodologies tended to support a particular language better than the others. For example, Booch’s methodology was developed based on the Ada programming language).

2.3.2 Critique of OOAD Methodologies

Different OOAD methodologies have their own characteristics in terms of Notation, processes, pragmatics, supporting software engineering and adherence to OO principles. However there is no absolute any right or wrong, nor is there any good or bad single method, merely a greater or lesser suitability for application to different problem domains [Fowler 1996].

Some methodologies are very rich and explicit like UML, OPEN, OMT and SOMA but the price to pay is that their graphical notation is very complex and the learning curves are steep. Alternatively, methods like Coad/Yourdon and Shlaer/Mellor are relatively simple to use and easy to learn but might not be sufficient to model large and complex systems. Fowler [1996] comments that developers should not stick to one single methodology. They should use their judgement to select the right tools from different methodologies and apply them as appropriate.

2.3.3 UML Standard Notation

In November 1997, the Object Management Group (OMG) – a non-profit-making organisation formed by a group of OO enthusiasts in 1989 to promote OO and which has since become an industrial standard monitoring body within the OO community – formally adopted UML as an OOAD standard Notation [Rational 1997].

However this is the standard for notation only. A complete OO methodology should contain: (1) Notation; (2) Processes; and (3) Techniques. Even though OPEN had lost the competition to UML in the notation standard, OPEN was ahead of UML towards the standardisation of processes. At the time of submitting this thesis, OPEN was likely to be recognised by the OMG as the standard for processes [Source : http://www.csse.swin.edu.au/cotar/OPEN/OPEN.html] although it has not been officially announced yet.

Other OOAD methodologies such as SOMA and MOSES have included project development life cycle as part of their methodologies. Both methodologies advocate Rapid Application Development (RAD) [Martin 1991].

The nine most common types of notation in UML have been selected for discussion below. UML will also be investigated to see whether or not this ‘standard’ notation could model the software application to deliver not just ‘software products’ but also ‘business solutions’.

(i) Use Case Diagram

A Use Case Diagram is used for modelling business processes at a high-level of business abstraction. Figure 2-7 shows an example of a Use Case Diagram. Use Case is a model created to represent system functionality as depicted by the interactions the user has with the system. Each interaction is described as a single Use Case. The user, represented by an actor, can interact with the system in one or more ways. Each Use Case is described by free text which can later be represented by a Sequence Diagram [Henderson-Seller et al 1998]. For instance, in an Insurance Claims system, Customer, Account Executive and Insurance Underwriter are all Actors. The Use Cases represent different tasks inside the system. A Customer submits an insurance claim and gets a claim payment. An Account Executive processes the insurance claim and forwards it to the Insurance Underwriter. The Insurance Underwriter pays the insurance claim.

Figure 2-7 : An example of Use Case Diagram

(ii) Activity Diagram

An Activity Diagram is used for modelling the behaviour of the Use Cases. Figure 2-8 shows an example of an Activity Diagram. An Activity Diagram shows the flow from activity to activity. Activities, usually run in sequence, and ultimately result in some actions. Actions may also call another operation. Graphically, an Activity Diagram is a collection of vertices and arcs [Booch et al 1998]. An Activity Diagram is a kind of State Diagram where the states correspond to major system processes that are activated when reached. Therefore the Activity Diagram may somewhat look like a Flowchart.

Their notation (the diamond shape symbol represents decision in both the Activity Diagram and the Flowchart Diagram) and semantics (the direction of flow is from top-down for both of them) are very similar, except insofar the Activity Diagram treats each activity as an object in order to pave the way for the conversion of tasks into Object and Class Diagrams.

In addition, the Activity Diagram makes a very clear distinction between one task and another. If there is more than one task which needs to be carried out in parallel, these will be represented at the same level. The flow will not move on to the next level until all tasks at the earlier level are completed. Their exit arrows will meet at the synchronising transition bar. This notation is borrowed from Petri Nets [Reisig 1982] to show asynchronous branching and resynchronisation. Execution will only continue if every flow to a synchronising transition is completed. For instance, the activities involved in processing a Credit Insurance Claim include the creation of a new claim record, the transfer from the debt file to the claim file and the submission of a claim application to the Insurance Underwriter. After the claim payment is obtained from the Insurance Underwriter, it is then forwarded to the customer.

Another strength of the Activity Diagram is that there is always a statement clearly describing the outcome of the decision next to each decision symbol. The Activity diagram is still regarded as a high-level diagram, since at this stage it simply defines the business logic. As mentioned above, since it treats each task as an object, it paves the way for the future Object and Class Diagram modelling.

(iii) State Diagram

A State Diagram is used for modelling the behaviour of Objects in the system. Figure 2-9 shows an example of a State Diagram. Objects have states. Each state is represented by the current values of all attributes, associations and aggregations. Changes of state occur when a message, acting as a trigger, is received and one of these values is altered as a result. Any change of state thus engendered is a transition. A transition is regarded as instantaneous, whereas an object remains in a specific state for some duration [Henderson et al 1998]. Objects’ behaviours may change as a result of a change in state.

Figure 2-8 : Example of an Activity Diagram

Figure 2-9 : Example of a State Diagram

(iv) Class Diagram

A Class Diagram is used for modelling the static structure of classes in the system. A class is a description of a set of Objects that share the same attributes, operations, behaviours, relationships, and semantics through inheritance. A Class implements one or more interfaces. A Class Diagram is used to model the state design view of a system [Booch et al 1998]. The Class Diagram in Figure 2-10 is an example which illustrates how the notion of a Customer is composed of a block of regional information, and successively classified into major Subclasses i.e., BTR Unit and Non-BTR Unit. The regional component of both these Subclasses may take the value of a Domestic or Overseas Region.

Figure 2-10 : Example of a Class Diagram

(v) Object

An Object is used for modelling the structure of Objects in the system. An Object is an instance of things. All the Object’s attributes, operations, relationships, and semantics are defined by Classes. An Object is used to model a static design view or a static process view of a system [Booch et al 1998]. Figure 2-11 is an example of an Object. BTR Industry is an object derived from the Customer Class inheriting its attributes, operations and behaviours.

Figure 2-11 : Example of an Object

(vi) Sequence Diagram

A Sequence Diagram is used for modelling the dynamic aspects of a system by defining the messages passing between Objects. Figure 2-12 shows an example of a Sequence Diagram. It is an interaction diagram that emphasises the time ordering of messages. A Sequence Diagram is also important in the construction of executable systems through forward and reverse engineering [Booch et al 1998].

For instance, the sequence for an insurance claim system starts with the obtaining of an outstanding debt collection (legal) file. A claim file is then created. This is followed by the transfer of the legal debt file to the claim file. The next step is to separate all legal bills and third party costs from other correspondence in the insurance claim file. The claim file, legal bills and third party costs are submitted to the Insurance Underwriter. When the claim payment is received from the Insurance Underwriter, it will be forwarded to the customer.

(vii) Collaboration Diagram

A Collaboration Diagram is used for modelling object interactions. Figure 2-13 shows an example of Collaboration Diagram. A Collaboration Diagram is an interaction diagram that emphasises the structural organisation of the Objects that send and receive messages [Booch et al 1998]. For instance, a Collaboration Diagram is formed by first placing the Objects as the vertices in the diagram.

In Figure 2-13, the Objects include Insurance Claim Application, File Separator, New Account Creator, File Transferor, Insurance Underwriter, Insurance Claim, Legal Debt and Legal Fees/3^rd party Costs. The next step is to add the static links to connect these Objects – those are rendered as the arcs of the diagram. Finally, the messages that Objects sent and received are added as arrows annotating the static links. This gives a clear visual cue to the flow of control in the context of a structural organisation of Objects that collaborate.

Figure 2-12 : Example of a Sequence Diagram

Figure 2-13 : Example of a Collaboration Diagram

(viii) Component Diagram

A Component Diagram is used to model the static implementation view of a system. Figure 2-14 shows an example of a Component Diagram. This involves modelling the physical objects that reside on a node, such as executables, libraries, tables, files, and documents. Component Diagrams are essentially Class Diagrams that focus on a system’s components. It can be visualised through the Customer Class along with the static aspect of these physical components, such as the types of files, and their relationships. The Component Diagram is used to specify their details for construction.

In Figure 2-14, a Customer Class can be specified in different parameters such as Hypertext Modelling Language (HTML), Java and Joint Photographic Expert Group (JPG). In the context of the World-Wide-Web (WWW), HTML is a modelling language used for programming document files posting on the Uniform Resource Locator (URL) through the hypertext transfer protocol (HTTP) servers which return a document from the file system in response to the URL. Java programming language is getting more popular in web page programming it can handle more complex files such as interactive multimedia. For imaging files, JPG is the most commonly used format for this purpose.

Figure 2-14 : Example of a Component Diagram

(xi) Deployment Diagram

A Deployment Diagram is used for modelling the distribution of a system. Figure 2-15 shows an example of a Deployment Diagram. The purpose of a Deployment Diagram is to deploy the components that have been developed or reused as part of a software-intensive system, to some set of hardware to be executed. For instance, both the local servers and the internet servers contain software-intensive systems. The local servers need the local network protocol to connect to the internet servers. The internet servers need the Transmission Control Protocol / Internet Protocol (TCP/IP) to connect to the Internet. Each of the server has a node and different nodes connect to each other by a

link. A link is a pair composed of two nodes, respectively called source and destination. All the links are bi-directional notion of link that is, two-way traffic between the local servers and the internet servers.

Figure 2-15 : Example of a Deployment Diagram

Based on the literature review covered above, it has been found that although UML has unified the three methods of Booch, OMT and OOSE, UML still does not represent the best of these three methodologies. There are some good techniques amongst these three methodologies that have been excluded from UML (e.g., OOSE’s Complete Use Case Diagram, Use Case and Test Case Diagram, Use Case Object and Business Object Diagram; OMT’s Event Diagram). On the semantic level, UML Notation are complicated and the learning curve is steep. In spite of that, UML does provide a richer and more complete set of notation vis-à-vis other OOAD methodologies such as Coad/Yourdon, Shlaer/Mellor or SOMA.

The question remains: “Is UML sufficient to build applications to support business strategies?” In the author’s opinion, UML is still considered to be application driven that is, it is still relatively more fine-grained and low-level for mapping the requirements into programming code in respect to software performance. The following section will investigate the concept of Business Objects which are regarded as business-driven, have more coarse-grained and high-level for capturing the business essence.

2.4 Business Objects

Despite the growing popularity of Object technology, it still represents a compromise as regards supporting organisational SMP. The fundamental inadequacy of current OO approaches is that they are predominantly software-driven rather than tackling real business issues. In the software community it is still the norm to view business activities from the software point of view. Instead of considering how business tasks are carried out, software developers normally consider only the functions that software can perform which they think may be useful to the business. On many occasions, these functions may not be useful to the business.

Business Objects (BOs) are developed with a view to elevate the object level from being software-driven to being business-driven. BOs aim at transforming business knowledge into software components [OMG 1995]. Given the BOs, software adopted would be seen to give potential benefit to the business. Jacobson [1994] notes that BO technology has been developed to capture the user’s business and information processing requirements. Software objects are more concerned with the performance of the computer system but they do not necessarily mean that the software is performing the appropriate business tasks.

The main differences between BOs and conventional Software Objects are that, apart from describing the attributes, behaviours and operations (which reflect the capabilities of the software performance), BOs firstly capture the business factors related to the business domain. Those factors include the nature of an organisation, the type of business it is engaging and the products and/or services it provides. In view of this, BOs contain the modelling of object properties required to perform these tasks. BOs also contain software development processes together with the ability to define business structures and business operations [Sutherland 1995 (a)].

A BO is said to be a high-level object abstraction which encapsulates a typical, generic business task, adapted for a particular business domain. Casanave [1995] and Hertha [Hertha et al 1995] assert how BOs have brought the level of Object from software-driven to enterprise-driven. Various aspects of BOs are addressed in the following sub-sections.

OMG’s Definition

Representing a majority of developers within the OO community, the Object Management Group (OMG) defines BO as:

“… A representation of a thing active in the business domain including at least its business attributes, behaviour, relationships and constraints. A Business Object may represent, for example, a person, place, event, business process, or concept. Typical examples of Business Objects are: employee, product, invoice and payment. The representation may be in a natural language, a modelling language, or a programming language….” [Shelton et al 1996].

The above definition only emphasises the importance of a one-to-one correspondence between the natural business concepts encountered in practice and the OO modelling concepts. It does not address the substance(s) a BO should possess.

2.4.2 Individual developers’ definitions

Some prominent OO professionals have also interpreted their understanding of BOs. There are different schools of thought. Different people use the term of BOs to describe different things. To name a few:

(1) “…a Business Object is simply an entity relationship model, but with business rules and processes attached to it – a life history with operations and constraints allocated to event-effects…” [Ramackers 1996];

“…a Business Object is an entity that has a significant life history – perhaps an entity that experiences state changes other than insert and delete…” [Graham 1994];
“…a Business Object is a partial view of the class model that includes all the entities affected by an event – a kind of ‘half-baked’ event model…” [Berrisford et al 1994];

(4) “…a Business Object is the data structure gathered by an event or enquiry from several objects for display at the user interface – the response – a kind of database view…” [Jacobson 1996];

(5) “…a Business Object is a presentation layer thing – often a block of data displayed on a screen that users see as one coherent thing (e.g., a composite of an Order with all its Order Lines and a description of the Stock ordered on each Order Line)…” [Jacobson 1996];

(6) “…a Business Object is a generalisation from which application classes can inherit – say transaction rather than credit or debit, or farm animal rather than cow or pig…” [Partridge 1996].

As can be seen from the above definitions, Ramackers [1996]’s view is the combination of entity relationship and business processes. Graham [1994] puts a life cycle to reflect the change of state of an object. Barrisford [Barrisford et al 1994] does not see any difference between the software object and Business Object as Barrisford looks to the BO as only a class model. Jacobson [1996] perceives BO as the database viewed on the user interface. Partridge [1996] puts a generic view of BO as a collection of individual objects. However, none of the above definitions gives a precise definition

of the term ‘Business Object’. Some developers still cannot distinguish the difference between a BO and software object.

The definition from Sutherland [1995 (b)] reflects a more distinct view of BO. Sutherland defines them as follows: “… Business Objects encapsulate traditional lower-level objects that implement a business process (i.e., they are a collection of lower-level objects that behave as single, reusable units)…”

Ramackers [Ramackers et al 1995] claims that: “… The current use of objects is primarily restricted to a small-town, technology oriented perspective. Reuse of low-level components such as ‘windows’, ‘widgets’, ‘queries’ and ‘sets’ is possible, but these are clearly not the elements that the users and enterprises expect. To make object technology work for large industrial IS environments, we need greater business orientation and the ability to genuinely involve users…”

The above remarks support the idea of the business level of object abstraction. Object abstraction corresponds directly to certain natural business concepts, in contrast with the finer-grained system-level software components. The author’s research investigation has revealed that there are not many OO professionals focusing on the same perspective as Sutherland and Ramackers .

For example, according to Graham [1994]: “…A Business Object is an entity that has a significant life history – perhaps an entity that experiences state changes other than insert and delete…” This puts the emphasis on complexity of interactions between objects at different stages. Jacobson [1996] identifies BOs with the coherent block of data presented to a user as a result of a query: “…A Business Object is the data structure gathered by an event or enquiry from several objects for display at the user interface – the response – a kind of database view. It is a representation layer thing – often a block of data displayed on a screen that users see as one coherent thing…” Both the above views are still software-driven rather than business-driven.

Some OO professionals have used the term BO synonymously with the ‘Domain Object’ where they mean an object concept that maps onto a primary noun in the domain of discourse. In the last sense, BOs correspond simply to what Smalltalk [Par 1990] would call a model object in the MVC paradigm – an object which manages the primary data, routines and on-screen icons of the application concerned.

2.4.3 Confusion of definitions

In the above section, while the latter definitions are not incompatible with the earlier focus on business essence, the differences in the definitions indicate that some

confusion may still exist in the OO community at large regarding the meaning of the term ‘Business Object’(BO). The visualisation of BO is still unclear.

Although the opinions voiced above may appear to be different, a common conceptualisation identified by those OO professionals is that they still look at the BO from a software development perspective. In the software community, the direction to look at the business activities from the business point of view is still not widely appreciated. Most OO professionals still hold a common view that BO extracts and encapsulates business activities and simulates them to software components in the belief that consequently, software components will be able to successfully express the business sense. Unfortunately, their views are not quite the same from the business angle as an effective way to successfully express the business sense is still yet to be found. Until there is a method or technique to help IT professionals capture business objectives, the rift between business and IT will continue to exist. It will remain difficult to deliver software products as solutions for business.

2.4.4 A Survey of Business Objects

2.4.4.1 Introduction

The confusion of BOs’ definitions has prompted the author to conduct a survey of BOs. Over the last four years since the coining of the term ‘Business Objects’, BOs indeed have attracted attention from some OO professionals. There has been an increasingly widely held belief that the goal of ‘delivering software’ in line with ‘delivering business solutions’ could be addressed by adopting BOs for information system (IS) development. Under the influence from BOs, academic researchers and industrial developers have now started focusing their attention on a more business-driven approach to software development.

2.4.4.2 Expectation

The goal of the Business Object Domain Task Force (BODTF) in the Object Management Group (OMG) is to bridge the gap between software system models and business models. The method employed is to raise the level of abstraction at which the information systems are described, through the medium of BOs. The expectation is that BOs will somehow provide a common framework within which both business and IT professionals may communicate. A ‘Business Object Model’ is, then, a representation of the client’s business, in terms of the business strategies, business processes and operational procedure followed. The anticipated consequence is that the analysis of business systems will proceed more effectively, since the business clients and the IT developers will use the same representational framework. A longer-term goal of OMG’s BODTF is to establish standardised ‘Business Object’ templates that are applicable across individual business domains, and eventually across different types of industries [Casanave 1995 and 1997].

2.4.4.3 Motivation

Much has been claimed about the impact of BOs on IS development. Publications such as: [Sutherland 1995 (a)] [Digre 1996], industrial reports [IBM 1997] [Data Access et al 1997] [IBM/Oracle 1997] [TRC 1997] [EDS 1997] [SSA 1997] [NIIP 1997] [Genesis/Visigenic 1997] and even software products, have advocated BOs. However so far there appears to be little tangible evidence to demonstrate whether BOs have influenced the development of business applications in any positive way. Whilst BOs have been developed and adopted by some IT professionals, their number is still low. Furthermore, business management still remain to be convinced that BOs are adequate, cost-effective, or that they can provide assurances of system quality or increase the success rate of completed projects.

This raises the question: “Can BOs deliver on their promises?” A major survey was therefore conducted at the Object-Oriented Programming Systems Languages and Applications (OOPSLA) Conference in October 1997 in Atlanta, USA. The results were published and presented in the 5^th International Object-Oriented Information Systems (OOIS) Conference in September 1998 in Paris, France [Hung et al 1998(a)].

Approximately 1,500 survey forms were distributed to the conference attendees with 201 forms returned to the author. This feedback of only 13% seems quite low and one might question the extent to which this fraction of the conference delegates ‘represents’ the OO community at large. The reason for this is quite understandable. The survey was not part of the OOPSLA Conference’s formal technical programmes and it was neither a compulsory exercise nor there was any monetary reward. Delegates participated in the survey of their own accord and out of their own good will.

The purpose of this survey was to investigate how IT professionals world-wide view BOs from their personal point of view or from that of the organisations to which they are attached. The investigation attempted to establish an understanding of the appreciation and deployment of BOs in regards to their perceived maturity, the role they currently play in system development and their likely future prospects.

There is a growing concern about the hype surrounding BOs, a suspicion that this may be a case of “The Emperor’s New Clothes” [Spottiwoode 1996], that is, BOs may simply turn out to be the conventional software objects dressed up in new packaging. Rather than debate these issues, this survey sought to assess the attitude within the IT community towards BOs and to determine their current usefulness and future prospects.

The results suggested that although the general notion of BOs is familiar to most of the respondents from the survey, the exact nature of BOs remains rather ill-defined. For this reason, a relatively small number of organisations have adopted their development strategies based upon BOs.

The findings from this survey are revealing. They have provided many useful pointers for advocates of BOs, showing what direction this trend must take if the drive to higher business abstraction is really to take off. As far as the author is aware, this was the first ever survey of attitude to, and deployment of, Business Objects.

2.4.4.4 Survey Method

The survey was conducted in the OOPSLA 1997 Conference. The choice of the venue was based on the fact that OOPSLA is the world’s largest OO conference – attracting up to three thousand delegates each year since it began in 1986. Delegates range from industrial practitioners to academic researchers, from technical developers to business end-users, from students to corporate executives – all with a common interest in OO. The variety of delegate portfolio has made it easier for the author to target OO professionals from different sectors.

The survey method used in this conference was based on the survey technique used by the Gartner Group Company Inc (http://www.gartner.com). The Gartner Group is a well-known research company specialising in IT. The company regularly publishes its survey reports in leading computer and IT journals. In August 1995, the Gartner Group published a survey report in BYTE Magazine. The survey was called ‘OO Methodologies Adoption Study’. The company conducted a survey of 260 selected IT professionals where developers, senior corporate executives, IT managers, system analysts, programmers and researchers made up the bulk of the survey pool.

The survey framework used by the Gartner Group first identifies the target survey group through their sources. The sources carry information on their occupations and the sizes of their organisations, as measured by the number of employees and sales turnover. Having formed an understanding of their background, appropriate candidates are then selected and invited to participate in the survey. The questionnaire structure starts by examining their knowledge and understanding of the subject matter, history of adoption, views and experiences on using the product / tool / methodology and comments on future prospects. The responses to questions are mainly expressed as a percentage of the total number of respondents. However over and above the numerical representation, some additional comments from the surveyed candidates have equally brought a significant impact to the findings of the survey.

The survey conducted by the author has followed the questionnaire structure from the Gartner Group. However there is a slight difference in the selection of candidates. Due to the limited resources, the author was unable to identify prospective candidates on an individual basis. The OOPSLA Conference has provided an attractive alternative as it is the world’s biggest OO conference making it an ideal rendezvous for OO professionals.

Although no survey can provide a complete picture, at least it voices the opinions of a fair proportion of people within the community. As mentioned above, the OOPSLA conference generates a good sample of people covering a broad spectrum from academic researchers to industrial technologists in attendance.

2.4.4.5 Survey Findings

Due to the extensive volume of the survey documentation, the survey form is listed in Appendix B and the results are listed in Appendix C of this thesis. Of the 201 respondents, more than half have provided their email addresses for follow-up contact and have agreed to assist the author in conducting further surveys in the future.

2.4.4.6 Survey Evaluation

The BO survey has uncovered both positive and negative views on BOs. In general, respondents are not sceptical about the principle of BOs and most of them appreciate the benefit that may be brought by BOs. Thus, their usefulness is not in doubt. Most respondents believe strongly that BOs can bridge the communication gap between business users and IT developers. They also believe that the software systems produced out of BOs will reflect the real business concerns of their user community better than the traditional software objects – something contributing to the quality of the resultant system changes. However most respondents found the definition of BOs very vague. Many respondents explained that the reason why they still have not adopted such technology is largely due to the lack of knowledge of what BOs really are and how to use them.

In summary, respondents generally believed that BOs have a great deal of potential to become a more promising technology. The immaturity of the technology itself, a shortage of skilled professionals and the lack of industrial standards have hindered the potential of BO development.

2.4.4.7 Current status and future development

The immaturity of BOs, noted by the respondents to the survey, is due mainly to there still being some ambiguity between the higher-level abstraction of BOs and the lower-level of software objects. OO methodologists and researchers are still trying to achieve full traceability from business to software [Barrisford 1996].

A large number of respondents from the survey expressed interest to see the future development of BOs. The author has conveyed the findings from this BO survey to OMG’s BODTF for their consideration in their future development of BOs.

2.4.4.8 Conclusion and further survey

In view of the survey findings and evaluation, one important question remains: “What should we do about it?” It seems that effort could be invested most productively in the definition and standardisation of BOs as there is still a distinct lack of standard regarding the BOs quality and governing. Standardisation would ensure their wider adoption throughout the software community and help with integration and reuse aspects. More training should be provided to overcome the skill shortage and to help IT professionals profit from this resource.

In conclusion, the concept of BO is recognised and accepted by many OO professionals. However due to its technological immaturity, it is yet to be widely adopted. The current survey has obtained the opinions from the respondents on their acquaintance with, and attitudes towards BOs. The next stage will be to follow up many of the issues raised from this survey. The author anticipates conducting a follow-up survey at a future OOPSLA conference which will investigate how attitudes have changed in the intervening period.

2.4.5 Business Object publications

Since the concept of BO first arose during the deliberations of OMG in 1994, BOs have in recent years, despite their potential, been discussed by only a small proportion of people in the OO community. Most BO papers have only appeared in the OOPSLA conference Business Object Design and Implementation Workshops.

The first BO workshop was held in the OOPSLA 1995 conference where twelve position papers were presented. The workshop largely covered the application of Object-

Oriented Analysis and Design (OOAD) methods within the business environment. Casanave [1995] proposes to integrate the Common Object Request Broker Architecture (CORBA) with BOs to form a middle layer architecture as a standard for vertical industries such as healthcare, manufacturing, finance, insurance and telecommunication applications. Casanave’s view is supported by Poirier [Poirier et al 1995], where Poirier proposes a telecommunication architecture BO model. Hertha [Hertha et al 1995] proposes a 3-model / 4-tier framework for business applications. Kossman [1995] proposes a model to support real-time OO systems. Digre [1995] proposes a component-based architecture for client/server distributed applications. Ramackers [Ramackers et al 1995] proposes a Computer Aided Software Engineering (CASE) tool environment to integrate OO modelling, Business Process Reengineering (BPR) with Workflow Management. Grothehen [Grothehen et al 1995] proposes a mechanism to interface with legacy database systems. McCarthy [McCarthy et al 1995] suggests a Resource-Event-Agent (REA) for value-added processes of a business enterprise. Schwaber [1995] uses the rugby metaphor by adding a ‘SCRUM’ Management technique in OO projects to handle complexity of development process and uncertainty of project outcome.

The OOPSLA 1996 BO workshop was a sequel to the previous one and continued to discuss the outstanding issues together with some new ideas. Fowler [1996] proposes the use of analysis patterns in the BO development. His view is shared by Evitts [1996], who applies the business patterns to BOs. Johnson [Johnson et al 1996] uses the BO models for an accounting system project. Schulze [Schulze et al 1996] and Baker [1996] suggest the adoption of Workflow Management to BO development. Again, more people have contributed more new ideas in bringing the BO to a broader spectrum of issues.

In the OOPSLA 1997 BO workshop, there were two streams of discussion. The first stream focused on the domain specific application framework with the direction pointing towards the standardisation of BO for vertical industry applications proposed previously by Casanave [1995]. The second stream focused on the adoption of Workflow Management in BO development. Choudhury [Choudhury et al 1997] proposes a Customer Service BO model for telecommunication industry as a contribution towards the standardisation of BO in vertical industry application. Guido [Guido et al 1997] and Haugen [1997] continue the work on REA with a more detailed and mature model. Schulze [1997], Paul [Paul et al 1997], Beedle [1997] and le Comte [1997] present different approaches in adopting the Workflow Management in BO development. Hung (the author) [Hung et al 1997] proposes the DBOA with a view to assisting IT professionals in the understanding of business strategies and organisational goals. Marshall’s Business Object Management Architecture (BOMA) [1997] has a similar attempt to DBOA but it is an altogether different methodology. BOMA also targets organisational business visions, missions, goals and objectives. However it does not provide the technique to capture organisational aims and objectives and to measure business performance like the DBOA does. BOMA would only be suitable for those organisations which already have their aims, objectives and strategic plan well in place.

In the OOPSLA 1998 BO workshop, the Workflow Management continued to be explored and discussed by Hruby [1998], Kuechler [Kuechler et all 1998], Schhmidt [1998] and Hordijk [Hordijk et al 1998] together with the REA in accounting systems by Nakamura [Nakamura et al 1998] and Haugen [1998]. Papers on Business Object Architecture (BOA) were presented by Schmid [Schmid et al 1998 (a)], Spottiwoode [1998] and Hung (the author) [Hung et al 1998(b)]. The theme in 1998 was Complex Adaptive system (CAS). Papers on CAS were presented by Rostal [1998], Sutherland [1998] and Marshall [1998]. The areas of Business Components in Distributed Environment were discussed by Herzum [Herzum et al 1998] and Schmid [Schmid et al 1998]. Estrin [1998] discusses the transitioning process from legacy software systems to open systems using BOs.

In conclusion, the scope of discussion over these four workshops has indicated that BOs are spreading wider amongst the OO practitioners and researchers. The workshop participants feel generally optimistic that the potential of BOs will continue to be explored further in the future, as the technology becomes more mature.

2.5 Business Object Architecture

Christopher Alexander, an inspiring professor of architecture well known for his influential work on design patterns, suggests that: “…Architectural design and modelling are indeed the most sophisticated abstract thinking…” [Alexander 1996].

Cory Casanave – Chairman of OMG’s BODTF defines ‘architecture’ as: “… To represent the components that are used to ‘model’ the business problems and to build the system…” [Casanave 1995].

The Concise Oxford Dictionary defines ‘architecture’ as: “…The style and method of design of structures…”.

The investigation of BOA in this research is to find out the value and usefulness of the architectural concept in the development BOs and how BOA can enhance the reuse of BOs.

2.5.1 The concept behind the construct

Although most (if not all) IT professionals know what the software model is, there remains much to be understood regarding the concept of how to use the software modelling technique to model the business. More importantly, many IT professionals have yet to know the reasons why it needs to be done. Smith [Smith 1998] says: “… By itself, IT is useless…”. Smith criticises most IT professionals’ lack of insight in the adoption of technological progression to the real world (or the business world) citing their lack of knowledge of business.

In order to understand how to model business software development, an architectural approach, as defined in Section 2.5, should be adopted [Shaw et al 1993] [Best 1995]. With this architectural concept, BOA would help to encompass many notions of how to model business in an uncontroversial way. This is: “… to define an architecture allowing BOs to be represented inside a structured framework in a systematic and sequential fashion…”. It is an attempt in this research to evaluate how this concept of modelling is likely to support SMP.

Daniel [1996] stresses that one of the important factors of architecture is to transform the essence of some muddled and contextual ‘real-world’ situation into a well-defined, logical and graphical business map. BOA is a reconfigurable framework for handling the communications amongst BOs within the business domain. This framework should contain models of the business structures, policies, decisions, processes, functions, rules, actors, objects and the like.

2.5.2 Complexity management

Another function of BOA is the management of the complexity in BOs. Ramackers [Ramackers et al 1995]’s approach in handling complexity management is to define BOA as the aggregate of BOs where different BOs form the underlying architecture describing the information concepts essential to the business in question. When people are involved in business processes, their particular views of that underlying information are modelled through the BOA. This suggests that the formation of a BOA should be through the process passing (e.g., workflow architecture) amongst different BOs within the business domain. Ramackers suggests that a BOA should be constructed from bottom up in order to allow the system to be scaled up. Such an approach would also augment the BOA from simple to complex and from smaller to larger size.

Digre [1996]’s approach is to establish a Meta-model at a higher state of development. This Meta-model first shows the interoperability between the BOs and other objects in the Common Object Request Broker Architecture (CORBA) before invoking the Business Object Instance Manager (BOIM) to define the components inside each BO. In contrast to Ramackers, Digre constructs the architecture in a top-down manner by first building large units, then truncating them into different simple units.

Both Ramackers and Digre have their different viewpoints. The advantage of starting from the bottom up is that we can build small systems and scale up later. However this approach tends to lose the ‘full picture’ of the business domain as only a ‘snap shot’ of a particular area in the business domain is captured at any one time. By starting from the top down, by contrast, a ‘full picture’ of the business domain would be formed from the beginning. This ‘full picture’ would provide a basis on which developers could work out and plan strategies accordingly. However the trade-off is that it might not be cost- and time-effective as heavy investment would be required at the beginning and the development time would be longer than with the bottom-up approach. In terms of cost-effectiveness, business management would consider heavy investment at the beginning as a high risk. In terms of time-effectiveness, business management always look at short- to-medium term return on investment (ROI) and they lose patience to wait for long-term ROI.

The DBOA proposed in this thesis integrates both top-down and bottom-up approaches. A strategic model will firstly be defined from the top-down but without going into any unnecessary gory details. This will avoid any unattractively heavy investment at the outset. Then, the business processes and object components for the relevant business transaction(s) will be specified from the bottom up. Both ends will then meet in the middle-level where the business transactions take place. Different BOs will represent different business transactions.

2.5.3 Architecture Reuse

The concept of software reuse is not new. It dates back to the assembler language of the sixties where computer programmers were able to reuse the source code from redundant projects. However the results were not particularly favourable resulting in error prompts on many occasions. The reasons for that may be identified as firstly, programmers found it very difficult to identify the appropriate code for reuse. Secondly, it was difficult to integrate the old and new source code. Programmers would end up spending more time in fixing the problems than it would take them to write the code from scratch. The reuse of source code is only useful if it can match the new system. However this is rarely the case without extra costs in time and resources incurred.

It was gradually recognised that any effective method of software reuse must start from the high-level of abstraction where the actual business requirements, modelling concepts and system logic are defined. At this level of abstraction, it is believed that the developers are better able to capture the semantic level of system requirements and hence are able to identify more accurately the appropriate components for future reuse [McGregor et al 1996].

Software architecture is a framework which embraces the software components, ranging from the high-level conceptual model to the low-level code implementation. It shows the correspondence between system requirements and the constructed system elements. Architecture also provides a better control mechanism for the communication between components at different levels. It also addresses system level properties such as capacity, throughput, consistency and compatibility [Shaw et al 1993]. In order to achieve effective reuse, the interaction and the relationship between the components and the distinction between different levels of abstraction must be addressed clearly. Other areas of concern include the linkage between different parts, the matching of documentation, model and coding, coupling and de-coupling of different parts within the architecture.

Various studies have been conducted in recent years to tackle the above issues. McGregor [1996] proposes the Design Pattern to form a link between the high-level business logic components and the code level software components. This link could effectively track down the appropriate source code. White [White et al 1996] suggests a Domain Specific Language Generator, a software tool which can automatically generate the Domain Specific Languages based on the Domain Specific Software Architecture. In other words, this automated tool can assist the developers in reusing the design models from previous projects and let the tool generate the code automatically in the new systems/applications.

2.6 Critique of Business Objects and Business Object Architecture

Although there are various publications addressing the benefits of BOs and BOA, those benefits are still predominantly in the areas of improving software performance. These benefits are not sufficient to deliver business solutions. The reasons for this are that most IT professionals still see business only through their pair of ‘tinted spectacles’, that is:

(1) IT professionals see the business from their own perspective;

business users are denied access to this pair of “tinted spectacles” and are, thus, neither informed of, nor participate in the development.

Business management should be the best providers of business knowledge and system testing. The current attempts, made by other researchers and developers of BO and BOA, do emphasise the importance of building business systems as opposed to software systems. Even then, they still lack a communication mechanism between business management and IT professionals. This communication mechanism is a solely human factor. For this reason, a suitable environment is required to monitor this communication mechanism.

In the next section, the Dynamic Systems Development Method (DSDM), a project management approach with substantial business users’ involvement, will be investigated and reviewed.

2.7 Dynamic Systems Development Method

In order to examine the effectiveness of software applications, a review mechanism is needed to check whether or not the software applications can achieve business objectives. The Dynamic Systems Development Method (DSDM) has been chosen for investigation on its ability to provide such a mechanism.

DSDM is a public domain of the Rapid Application Development (RAD) [Angoss1996] that has been developed through capturing the experience of a large consortium of vendor and user organisations together with universities and academic research communities – the DSDM Consortium [Source: http://www.dsdm.org ]. DSDM is now regarded to be the UK’s de-facto standard of RAD [DSDM 1995] [DSDM 1997].

2.7.1 DSDM development environment

As far as the development environment is concerned, DSDM belongs to the systems thinking paradigm. The method views a system from a holistic perspective and integrates with all aspects of change including processes, organisations, people and technology. The interaction between business users and IT developers is more frequent than in the conventional waterfall project management approach where business users are not usually members of the project development team.

The iterative prototyping in DSDM is people-oriented. It provides an environment which enables business users to participate actively in project development and to improve their communication with IT professionals. It is intended, with this two-way echo, to produce software that is better able to support the business. In DSDM, all changes are reversible and backtracking is an accepted practice hence it might be able support the review mechanism as proposed in this thesis. The configuration control of DSDM is an essential component of the application development environment (ADE). Since change control is an essential discipline in DSDM, an ADE that facilitates it is highly desirable.

This is suggested in the DSDM Manual Version 3.0 [DSDM 1997] which says: “…The project development team must be empowered to make decisions about the functionality on both business and software…”. The emphasis is on delivering the optimum business solutions. Given this, decisions and trade-offs have to be made regarding any new functionalities elicited through the iterative prototyping process. Any less important functionalities may be excluded due to time constraints. Iterative development within a time scale is an effective way to develop at least an acceptable best-fit business solution rapidly.

With regards to business functionalities, such minimally acceptable business solutions might be detrimental to system engineering development. However it is suggested that system engineering should take second place as it is more important to build the right system in the first place (based on the requirements set by the business users) before it is engineered (optimised) for software performance.

DSDM testing is not a separate activity as in the case of the waterfall approach. It is integrated, incremented and undertaken by a project development team comprising the developers and the business users alike. This is referred to as ‘user acceptance testing’, and a successful user acceptance testing is one which elicits information about, or a better understanding of, the business domain.

Although the DSDM philosophy requires a high degree of business focus, it also takes technical aspects, such as the estimation basis on the logical business functions into account. In DSDM, the time scale should be tight. If a deadline is protracted, the development team would be at a risk of losing the business focus and diverting their attention to less important technical issues. Therefore, the risk of a DSDM project is measured according to its ability to deliver business benefit rather than in the view of its technical context. According to Butler Group’s Strategies and Technologies Management Guide [Butler 1995], a DSDM team should:

(1) be managed by business objectives;

(2) focus on team contribution;

(3) co-operate with each other;

(4) deliver the best business solution;

(5) work alongside business users;

(6) exclude doubtful business functions;

(7) take steps to prevent emergencies;

(8) improve quality;

(9) measure software performance against business benefit.

2.7.2 DSDM project life cycle

DSDM consists of five recursive phases represented by five time-boxes:

(1) Time-box one: Feasibility Study;

(2) Time-box two: Business Study;

(3) Time-box three: Functional Model Iteration;

(4) Time-box four: Design and Build Iteration;

(5) Time-box five: Implementation.

DSDM development lift cycle is based on the following nine principles:

Active user involvement imperative;

(2) DSDM team must be empowered to make decisions;

The focus on frequent delivery of products by time-boxing;
Fitness for business purpose is an essential criterion for the acceptance of deliverables;
Iterative and incremental development is necessary to converge on accurate business solutions;

(6) All changes during development are reversible;

(7) Requirements are baselined at a high-level;

Testing is integrated with software development throughout the life cycle;
A collaborative and co-operative approach between all stakeholders is essential.

2.7.3 Project management using DSDM

There are two distinct features of DSDM based project management namely: (1) Joint Requirement Planning (JRP) and (2) Joint Application Development (JAD). These two features are, as suggested in the DSDM manual, essential for the rapid progress of the

project insofar as: “…The right people are assembled at the right time, and given the right facilities to enable them to make the required project management and design decisions…”.

The DSDM manual also suggests that: “… Design recommendations are not good enough. Empowered decision makers are essential…”. In a DSDM project, there is no longer a vendor/purchaser relationship. It is a partnership between business users and IT developers. Both parties should work together to achieve the desired goals.

2.7.4 Experience gained from using DSDM

Since the official UK launch of DSDM in February 1995, this method has been widely adopted within the software community. Large organisations such as British Airways [Rapley 1996] and British Telecom [Taylor 1995] [Shortland et al 1997] are enthusiastically adopting DSDM for their software development projects. Software vendors such as Oracle Corporation [Clegg 1996] are also integrating DSDM into their OO and BPR projects.

From the experiences of these users, it was generally regarded that the contributions of DSDM are:

(1) “A Higher-level of user involvement” [Longman 1995], [Sloman 1995], [Thomson 1996];

“An increase in the level of customer satisfaction” [Blackman 1995], [Northmore et al 1996], [Doughty et al 1996], [O’Neill 1997], [Shortland et al 1997];
“A timely delivery of the project” [Blackman 1996], [Herzlick 1995], [Taylor 1995], [Parnell et al 1996], [Northmore et al 1996], [Ford 1996], [Thomson 1996], [Dunn 1997], [Butler et al 1997];
“A better quality of software” [Blackmore 1995], [Sloman 1995], [Dunn 1997];
“An increased productivity from both the business users, as a result of the improvement of software quality; and from the IT developers due to the project being delivered on time and within budget” [Taylor 1995], [Clegg 1996], [Parnell et al 1996], [Dunn 1997];

(6) “A project delivered fit for business purposes” [Herzlick 1995], [Taylor 1995], [Clegg 1996], [Rapley 1996], [Butler et al 1997];

“Communication between the business users and the IT developers has improved due to their frequent and regular contacts” [Herzlick 1995], [Taylor 1995], [Ford 1996], [O’Neill 1997], [Brown et al 1997];

(8) “A higher team spirit” [Herzlich 1995], [Thomson 1996], [Dunn 1997], [O’Neill 1997], [Elliot 1997], [McCarthy et al 1997];

(9) “A gain in commitment from the business management” [Herzlich 1995], [Sloman 1995], [Thomson 1996];

(10) “The advent of a new work practice in IT projects, through business users’ participation” [Doughty et al 1996], [Brown et al 1997];

“An elimination of bureaucracy through the empowerment of decision makers and the delegation of tasks” [Taylor 1995], [McCarthy et al 1997];

(12) “A possible earlier return on investment, since the delay in project delivery has been minimised” [Herzlick 1995], [Ford 1996].

However adopters have also encountered the problems of:

“DSDM not being a ‘Silver Bullet’ (DSDM cannot be used for all projects. It is suitable for projects with real users but not for those projects with no real end-users)” [Butler et al 1997];
“A steep learning curve for IT developers, particularly with regards to communication with business users; the meeting of numerous delivery deadlines imposed by time-boxing; the management of a project team comprising people from both the IT and business sides; and the rapid production of different versions of prototypes” [Herzlick 1995], [Taylor 1995], [Rapley 1996], [Dunn 1997], [Barrett et al 1997];
“Team elitism problems in how to select the right people, assembled at the right time, to provide right facilities in the project team” [Taylor 1995], [Dunn 1997], [Elliot 1997];

(4) “Tight time-boxing which has added pressure to the development team” [Taylor 1995], [McCarthy et al 1997], [Dunn 1997];

(5) “A conflict of project ownership when defining the distribution of project responsibility” [Taylor 1995], [Thomson 1996], [Doughty et al 1996], [Dunn 1997].

2.7.5 Critique of DSDM

From the outset, the DSDM Consortium state that their methodology is based upon the RAD approach with additional techniques included to improve project management. After studying the DSDM Manual Version 3.0 [DSDM 1997] and the

DSDM – Method in Practice [Stapleton 1997] and having used the DSDM in four different projects during the past two years, the author has identified some weaknesses in the method. These weaknesses are the selection and empowerment of right people to make decisions; the time-boxing syndrome; the culture gap between business users and IT professionals; and work pattern/paradigm shifts in software development. However when the author approached the Consortium, they were only interested in promoting the benefits of the method rather than discussing its disadvantages. The author was merely informed by the Consortium, during a number of telephone conversations, that the DSDM technical taskforce was working on the improvement of the method from time to time and that any such improvement will be published in future versions of the DSDM manual.

The author was denied permission to make contact with any members of the DSDM technical taskforce as only people holding full membership with the consortium are allowed to do so. Although one should appreciate the effort made by the DSDM Consortium in integrating the RAD approach with project management method, if the resulting method itself is not yet mature, it might not be the ‘Holy Grail’ that some would like to think it is! From the author’s point of view, it would be more constructive, if the DSDM Consortium aims at improving the method, for them to be more opened to the general public to discuss ideas and suggestions with people from different sectors.

2.8 Conclusion of Literature Review

The literature review has covered three main areas of research investigation namely: (1) Strategic Management Planning (SMP); (2) Business Objects (BOs) and Business Object Architecture (BOA); and (3) Dynamic Systems Development Method (DSDM). Various SMP models have been examined and analysed. The underlying logic and structure of organisational SMP have been studied. The theoretical principles and complexity of SMP have made it difficult to implement in day-to-day business operations. Some organisations have adopted IT in the hope that it would assist them in this respect. However there is an absence of mechanisms which can enable IT professionals and the business management to communicate with each other. For this reason, in some cases, IT has failed to provide a means for business management to effectively implement their business strategies.

BOs and BOA, two of the new and emerging technologies emphasising the elevation of software development to the business level, were investigated to see whether they can bridge the communication gap. From the viewpoint of some software developers, there is a great deal of potential in BOs and BOA to model business abstraction. However the results drawn from the BO survey have unearthed that most IT professionals still find the definition of BOs unclear and inconsistent. Various BO publications have also shown the BOs are still software-driven due to the absence of control mechanisms to enable effective interactions between business management and IT professionals. This has led to the investigation into the Dynamic Systems Development Method (DSDM) which is a new technology in project management approach. The experience of its users is encouraging, although there remain some reservations in view of the immaturity of the method.

2.9 Closing Remarks

The findings of the literature review have shown that OO, BO, BOA and DSDM have the potential to bridge the communication gap between business management and IT professionals. However the findings have also revealed the incompleteness of any one individual technology to support the goal of this research. Therefore, the next chapter will describe the proposed DBOA development integrating the above-mentioned technologies to achieve the research goals.

~ I do not know anyone who has got to the top without hard work. That is the recipe. It will not always get you to the top, but should get you pretty near ~

(Margaret Thatcher)

CHAPTER THREE: DYNAMIC BUSINESS OBJECT ARCHITECTURE DEVELOPMENT

3.1 Introduction

This chapter aims at mapping the development of a theoretical framework for the study having regard to the conceptual base of the literature review in Chapter 2. It will describe the development of a Dynamic Business Object Architecture (DBOA) to support organisational Strategic Management Planning (SMP). DBOA is made up of a Business Object Architecture (BOA) incorporating a project management approach – Dynamic Systems Development Method (DSDM). BOA manages different Business Objects (BOs) within a business domain. Each BO consists of four levels of development processes namely: Business Strategy Level, Business Process Level, Object-Oriented (OO) Modelling Level and Database Management System (DBMS) level. The reuse strategy for DBOA will also be discussed towards the end of this chapter.

3.2 Formation of a Business Object

This thesis presents the first BO model for supporting organisational Strategic Management Planning (SMP). A BO integrates business and IT domains together and draws the IT professionals’ attention to the impact of business strategies on software application development. As illustrated in Figure 3-1, a four-level BO is presented. The Business Strategy Level is at the top of the model. It contains the elements of how to understand the organisational business situation, measure business performance and identify business strategies. The second level is the Business Process Level at which the procedures for handling business operations are defined in response to the business strategies. The third level is the Object-Oriented (OO) Modelling Level at which business processes are modelled through OO analysis and design techniques. The fourth level is the Database Management System (DBMS) Level at which any newly-developed applications should interface with the existing legacy or non-legacy database systems.

Figure 3-1 : Four Levels of a Business Object

As discussed in Section 2.4.5, BOs have been used in modelling a sizeable range of software applications but those BOs are not used to implement the business strategies as proposed here. The following sub-sections will describe the contents at each level.

3.2.1 Business Strategy Level

3.2.1.1 SMP Questionnaire

The first step to be taken at the Business Strategy Level is knowledge acquisition from the business management. The SMP questionnaire (Table 3-1) is designed, following an ‘Open-ended’ question format, to allow respondents to give unrestricted answers and to deliberately open the way to make the questions intentionally simple and easy to complete. It is envisaged that the data elicited through these simple ‘Open-ended’ questions will both encompass and be richer than that which would be collected using the multiple choice style favourable / unfavourable incident questions. Such an approach is felt to be justified for the following reasons:

People would tend to express their feeling more sincerely;
Since the questions are asked in a ‘Non-jargon’ way, people would understand these questions better and hence their answers would be more accurate and reliable;
No restriction is placed on the length of the answers. Interviewees are free to provide as much information as they would like to. As a result, more useful and relevant information is likely to be obtained.

Strategic Management Planning Questionnaire

Interviewee : ___________

Position : ___________

Length of service : ________

PART A : GENERAL

A1. What do you think the main strengths and weaknesses of your organisation?

Strengths: __________________________________________________________

___________________________________________________________________

Weaknesses: ________________________________________________________

___________________________________________________________________

A2. From your organisation’s point of view, what long- and short-term challenges are you facing?

Short-term challenges: ________________________________________________

___________________________________________________________________

Long-term challenges: ________________________________________________

___________________________________________________________________

A3. What are your organisation’s aims and objectives?

Aims: ______________________________________________________________

___________________________________________________________________

Objectives: __________________________________________________________

___________________________________________________________________

PART B: SERVICES / PRODUCTS

B1. What factors do you take into consideration when improving your products / services?______________________________________________________

___________________________________________________________________

PART C : COMPETITIVENESS

C1. What do you consider to be the most important factor(s) in maintaining your market position?

___________________________________________________________________

C2. What kind of competition is your organisation facing?

___________________________________________________________________

C3. Who are your competitors? Where are they? What are their sizes?

Name of your competitors: _____________________________________________

___________________________________________________________________

Where are your competitors: ___________________________________________

___________________________________________________________________

What are their sizes: __________________________________________________

___________________________________________________________________

PART D: CUSTOMERS

D1. What is your perception of the relationship between your organisation and its customers?

___________________________________________________________________

PART E: HUMAN RESOURCES

E1. What is your personal experience in working of your organisation?

___________________________________________________________________

PART F: TECHNOLOGY

F1. What role do you think the technology plays within your organisation? And what do you suggest to change? And what are your reasons for change?

Technology role: _____________________________________________________

___________________________________________________________________

Suggestions to change: ________________________________________________

___________________________________________________________________

Reasons to change: ___________________________________________________

___________________________________________________________________

Table 3-1 : Strategic Management Planning ‘Open-ended’ Questionnaire

3.2.1.2 SMP Interviews

The SMP Questionnaire as shown in Table 3-1 is used to interview the business management. To enable consistency and accuracy, all questionnaires should be completed by the interviewer who is either the IT Manager within the company or an IS Consultant appointed from outside. Each interview should be held with each interviewee on an individual basis.

The interviews should open with an outline of organisation’s strengths and weaknesses. Then, opportunities and threats should be discussed. In view of the threats, it is necessary to ask the business management what are their long- and short-term challenges. The interview should also review the issues surrounding the standard and quality of products and services. Information about the competitors such as their sizes and their locations is important so as to keep aware of the competition. Customers are the main stakeholders. An organisation’s success or failure relies on the business brought from customers. Given this, customer services are the key which determines the survival of an organisation. Employees provide customer services so human resources issues have a direct impact on the standard and quality of customer services. Information systems play a crucial role in organisations. Efficient information systems can no doubt assist organisations in improving their business performance. Software technology has been widely adopted to speed up processing time, to increase storage capacity and to improve accuracy and reliability. For this reason, the effectiveness of the current information systems in the organisation must be known.

3.2.1.3 Structure of an SMP

Having understood the organisation’s present position and business objectives, the SMP technique (as discussed in Section 2.2.3) is used to identify organisational business strategies or to assist organisation to establish business strategies. Figure 3-2 illustrates the structure of an SMP. There are three levels of strategies namely Corporate level, Competitive level and Operational level. The Corporate level contains Low Cost Strategy. The Competitive level contains Product Differentiation Strategy, Product Efficiency Strategy and Insurance Market Competitiveness Strategy. The Operational level contains Customer Services Strategy, Human Resources Strategy and Information System Effectiveness Strategy.

Figure 3-2 : The Three Levels of SMP

The hierarchical structure of the SMP produced in this thesis is based on Faulkner’s [Faulkner et al 1995] model. These sever strategies should be sufficient to be used in the insurance industrial sector. It is anticipated that the SMP can be easily customised for other industrial sectors based on this study as they only require a few relatively minor sector specific modifications.

CAD Consultants Ltd. (CAD), a credit insurance company – the sponsor of the author’s research – is used as a case study example throughout this thesis.

At the top of the SMP structure is the Corporate Strategy Level representing the ultimate business objectives across the whole organisation. Low Cost Strategy is regarded by most organisations as a primary objective to run the business at a low cost or to minimise the risk of loss. The middle level of the SMP structure contains the Competitive Strategy Level. This strategy outlines how to achieve sustainable competitive advantage in the products/services provided, against other competitors. Product Differentiation, Product Efficiency and Insurance Market Competitiveness form the strategies at this level. Competition deals with products and services. Differentiation involves branding the products or services uniquely so as they stand out from the competition. Product Efficiency can enhance competitiveness. Insurance Market Competitiveness is to increase market observation. At the bottom of the SMP structure is the Operational Strategy Level. This strategy is disaggregated by operations of actual business tasks. Customer Services, Human Resources and Information Systems Effectiveness are the strategies at this level. Operations are performed on a day-to-day basis. Handling customers, managing staff and maintaining information systems are also day-to-day tasks.

The Porter’s Five Forces Model and Porter’s Value Chain Analysis are used to capture the factors related to the Low Cost Strategy and Product Differentiation Strategy. By allowing organisations to look at different forces coming from different areas, the Five Forces Model can help organisations to make the relevant cost adjustments. The Value Chain Analysis can direct organisations to relocate resources if they want to differentiate a particular product or service from others in terms of branding, design and marketing.

Porter [1985] suggests that in order to gain the competitive advantage, organisations should either adopt Low Cost Strategy or use the strategy to produce differentiated products. For Low Cost Strategy, customers are naturally attracted to the reduced price. On the other hand, for Product Differentiation Strategy, if organisations allow differentiation using customisation, and delivering products/services quickly and efficiently, some customers are willing to pay a premium price.

From the outset, it looks as the Low Cost Strategy and the Product Differentiation Strategy might contradict each other. Whilst one is about the minimisation of cost in order to attract customers, the other is about modifying the product or service, at the price of increasing cost, also to attract customers. A question may be raised: “Can these two strategies co-exist in the same SMP?” Paradoxically, based on the author’s research studies, there are many examples showing how these two strategies do in fact co-exist.

As an example, Georgio Armani is an expensive and exclusive fashion designer label for clothes targeting the niche market. In order to develop the mass market, the company launched the Armani Exchange which is the lower range of Georgio Armani at much more affordable prices. This indicates that the Low Cost Strategy and the Product Differentiation Strategy need not contradict one another because there are always different types of customers in a single organisation. Some customers can only afford the lower price, while others prefer uniqueness and are willing to pay the higher price.

Porter’s Generic Strategies are also used to identify the factors which bear upon the Low Cost Strategy, Product Differentiation Strategy and Product Efficiency Strategy. The Generic Strategies focus on the strategic targets of either on cost leadership or differentiation. The Generic Strategies also analyse the outcome from these two targets.

Relationship Marketing is used in relation to the Insurance Market Competitiveness Strategy and Customer Services Strategy. Relationship Marketing has demonstrated a particular strength in identifying both the external and internal factors needed to assess the competitiveness of an organisation.

The PEST Analysis is also used to identify the factors in relation to the Product Efficiency, Insurance Market Competitiveness and Information Systems Effectiveness Strategies. The PEST Analysis covers four segments in a business environment in terms of political, economic, social and technological issues. It also defines human relationships thereby helping to build the Human Resources Strategy. In addition, the technological issues in the PEST Analysis also help define the Information Systems Effectiveness Strategy. The following sub-sections will describe, at some length, the structures of these seven strategies as shown in Figure 3-2.

3.2.1.3.1 Corporate Level – Low Cost Strategy

The objective of Low Cost Strategy is to use internal revenue economically and to identify the lowest possible price from sources to:

increase sales volume;
lower sales price;
maximise profit margin;
attract more customers;

(e) beat competitors.

[Griffith 1997]

Amongst business organisations, Low Cost Strategy has proven to be a powerful competitive approach in price-sensitive markets. The aim is to open up a sustainable cost advantage over competitors and then use the company’s lower-cost edge as a basis for either under-pricing competitors and gaining market share at their expense or earning a higher profit margin selling at the going market price. Cost advantage can increase profitability unless it is used in aggressive price-cutting efforts to win sales from rivals. Achieving low-cost leadership typically means offering low cost relative to competitors.

It is not often wise, nevertheless, to subordinate an organisation’s entire business strategy to lowering costs – for the resultant product could end up being too spartan and frill-free to generate buyer appeal.

3.2.1.3.2 Competitive Level – Product Differentiation Strategy

Product Differentiation Strategy requires an organisation to undergo a progressive and developmental change resulting in a specialisation of form or function to enable its products / services to have features, in regards to price, market which it targets, design and functionality etc., to differentiate it from its potential substitutes.

Differentiation offers a buffer against the strategies of rivals when it results in enhancing buyer’s loyalty to a company’s brand or model and greater willingness to pay a higher price for it. In addition, successful differentiation would:

place entry barriers in the form of customer loyalty and uniqueness which newcomers would find hard to overcome;
limit buyers’ bargaining power since the products of alternative sellers are less attractive to them;
help an organisation to fend off threats from substitutes lacking comparable features or attributes.

3.2.1.3.3 Competitive Level : Product Efficiency Strategy

The aim of the Product Efficiency Strategy is to provide efficient products and/or services to customers in regards to price, value for money, usefulness, automation, flexibility and accuracy. In order to achieve these goals, surveys investigating the products and/or services demanded from customers must be conducted. Investment must be made in quality improvement.

3.2.1.3.4 Competitive Level – Insurance Market Competitiveness Strategy

The insurance industry in the UK has been somewhat in emerging from the recession, with some areas in the commercial sector only now beginning to refocus. Many companies have been further hit by the costs and problems associated with new government regulations. Some well-publicised problems with pension sales are still causing huge bills to be incurred by some of the large pensions companies.

Any insurance products developed reflect current social, economic, political, legal and regulatory climates. They respond to needs, and exploit opportunities arising from changes in social conditions. For instance, the changes in the UK social security policy have affected the public demand for private insurance. Recently there has been an increase in pensions and long-term care provision resulting from concern regarding future state provision. State withdrawal from mortgage interest payments has created opportunities in mortgage payment protection.

The increase in the number of litigation cases has produced a corresponding growth in liability and legal expenses insurance. The influence of demographic changes means that people are looking for a steadier lifetime income. This leads to borrowing and therefore an increased demand for credit insurance cover.

In view of the above opportunities, the insurance industry has become a lucrative business and the number of insurance or insurance-related companies is increasing rapidly. The increasing number of insurance companies has made the insurance business highly competitive. For this reason, in the Insurance Market Competitiveness Strategy, strong emphasis is laid on the retention of existing customers as poaching customers from competitors is a norm in the insurance market.

3.2.1.3.5 Operational Level – Customer Services Strategy

Customers are generally regarded as those who pay to receive goods or services. They are usually seen as direct consumers. Customers have a direct impact on a company’s profitability. Customers may also be seen as stakeholders if they have direct shares or interests in an enterprise. A reasonable return to different stakeholders on their investment does make sense.

Therefore, the Customer Services Strategy aims at improving services to the customer, firstly to get them their money’s worth, secondly to retain existing customers and thirdly to attract new customers.

3.2.1.3.6 Operational Level – Human Resources Strategy

Human Resources Strategy aims at assisting an organisation’s management to improve their understanding of the factors influencing the performance and direction of its staff members. This improved understanding increases confidence in decision making and overall business operations. The Human Resources Strategy is particularly useful in identifying performance measures and areas for investment such as training, technology or resources. It can also improve staff quality and style of work approaches. It is equally seen as a way to improve the relationship between employers and employees.

3.2.1.3.7 Operational Level – Information Systems Effectiveness Strategy

Information Systems (IS) cover a wide scope of information circulating both internally within an organisation and externally amongst different organisations. IS play a crucial role in business organisations and have become assets to organisations. The IS Effectiveness Strategy is a concept at a high-level of abstraction in both the technical and business perspectives. It evaluates the overall IS effectiveness from both technical and business standards. The consideration of these two aspects of effectiveness allows for customisation of IS infrastructures which is of particular importance in certain organisations who have invested substantially in IT.

3.2.1.4 SMP Strategic Factors and Definitions

This thesis has produced seven business strategies, as described in Sections 3.2.1.3.1 to 3.2.1.3.7, for the SMP Checklist Manual Assessment exercise which will be explained in Section 3.2.1.5. To assist readers in understanding the context of the SMP Checklists, a set of tables containing strategic factors with detailed definitions for each strategy is presented in Appendix F.

The strategic factors related to different strategies are derived from various strategic models as described in Section 2.2.5. Some of them are extracted from Kardaras [1995]’s research work. Although Kardaras’ research is in different area (Integrated Qualitative Causal (IQC) Model using Fuzzy Logic as an IS Decision-support Tool), various Porter’s models have also been used to develop the IQC Model. The strategic factors in the IQC model are treated as ‘variables’ for weighing the business performance in an organisation. The result is used to develop recommendations to business management regarding decision making and strategic information systems planning. Some of these variables and their definitions from the IQC model are considered to be appropriate to this research in the development of the SMP Strategic Factors and Definitions tables. The management personnel at CAD Consultants Ltd. have also contributed their knowledge in their areas of expertise to assist the author in this respect.

3.2.1.5 SMP Checklist Manual Assessment

A set of Strategic Management Planning (SMP) Checklist Manual Assessment forms, with the seven business strategies, has been produced in this thesis. These forms are used in the SMP Checklist Manual Assessment exercise to be held after the SMP ‘Open-ended’ question interviews. These SMP Checklists are designed in a ‘Closed’ question format. The purpose of this exercise is to quantify the ‘Open-ended’ questions and to measure the business performance based on the results of the previous interviews. This exercise is a good indicator in helping the IT professionals identify the business aims and objectives and understand the business performance, and hence to implement the business strategies accordingly. Unlike the SMP ‘Open-ended’ question interview, here the IT Manager or the IS Consultant should assemble all the management team members who have been interviewed previously to sit down together to undertake this SMP Checklist Manual Assessment exercise. Different answers from different people should be incorporated together to come up with one single common answer as agreed by the majority. Business changes from time to time and DBOA exhibits flexibility and responsiveness to environmental changes. Therefore, the SMP Checklist Manual Assessment exercise is recommended in this thesis, to take place periodically between six and twelve months to review the level of improvement in business performance. A full set of SMP Checklist Manual Assessment forms with the seven business strategies described in Section 3.2.1.3 are listed in Appendix G. Table 3-2 below shows the design of the form.

(NAME OF THE STRATEGY)
Assessment Date :
Concept	Context Level			Action Required?		Objective Achieved ?			Score
Concept	High	Med	Low	Yes	No	Yes 1	Partial 0.5	No 0	Score
(Name of strategic factor)



*Total no. of factors : __________* *Total no. of objectives met: __________* *Percentage of objectives met: _______*%__

Table 3-2 : SMP Checklist Manual Assessment ‘Closed’ Question Form

The SMP Checklist starts from the left with the first column headed ‘Concept’ where the names of the strategic factors are situated. The next column headed the ‘Context Level’, contains three sub-columns for three levels of performance, namely: ‘high’, ‘medium’ or ‘low’. In the middle of the table, there is an ‘Action Required’ column, with ‘Yes’ and ‘No’ sub-columns. Towards the right is the ‘Objective Achieved?’ column with ‘Yes’, ‘Partial’ or ‘No’ sub-columns. Different scores are used to represent the different levels of ‘Objectives Achieved’, namely: 1 point for ‘Yes’, 0.5 point for ‘Partial’ and 0 point for ‘No’. At the right hand side of the table, there is a score board column recording the points from the ‘Objective Achieved’ column. At the bottom of each table, there is a breakdown of ‘Total number of strategic factors’, ‘Total number of objectives met’ and ‘Percentage of objectives met’. The unit of measurement is the percentage of the objectives achieved.

3.2.2 Business Process Level

3.2.2.1 ISO9000 Quality Manual Specification

The ISO9000 Standard Operating Quality Manual Specification [ISO 1995] is adopted as part of the BO development to document the business processes. It is used as a tool to elicit formal documents for business processes. The standard is monitored by the International Organisation for Standardisation (ISO) with headquarters based in Switzerland. The ISO9000 family of International Standard includes requirement for quality systems which can be used to achieve common interpretation, development, implementation and application of quality management and quality assurance.

In the case of the BO development, the ISO9000 procedure also provides a process improvement technique to identify and define clearly the tasks and actions needed to achieve the business goals set out as a result of the SMP Checklist Manual Assessment exercise. There are seven main sections in each procedure manual, namely:

Purposes : Quality manuals demonstrate compliance of the quality system with quality requirements in contractual situations. The quality manuals are useful for organisations in communicating policies, rules, regulations, procedures and requirements. They describe and implement an effective quality system and provide control of practices and facilitate quality assurance activities. The quality manuals serve auditing purposes. They are also used for training personnel in the quality system requirements and methods of compliance. The quality manuals should also state the organisation’s

objectives. This is where the organisation’s commitment to quality is presented and where the organisation’s objectives for quality are outlined. The quality manuals should describe how the quality policy is made known to, and understood by, all employees and how it is implemented and maintained at all levels. Specific quality policy statements may also be included under the system element concerned. Subsequent sections (or system elements) of the manuals may also be used to reflect implementation of and linkage to, the quality policy and objectives.

Scope : Each documented procedure should cover a logically separable part of the quality system, such as a complete quality system element or part thereof, or a sequence of interrelated activities connected with more than one quality system element. In terms of quantity, the volume of each documented procedure and the nature of its format and presentation is to be determined by the user of this International Standard. The format and presentation reflect the complexity of the facility, organisation and nature of business. Documented quality system procedures should not, as a rule, enter into purely technical details of the type normally documented in detailed work instructions.

(3) Responsibility: Once the management decision has been made to document a quality procedure, the actual process should begin with assignment of the co-ordination task to a management-delegated competent body. This delegated body may be an individual or a group of individuals from one or more functional departments. In this section of the manual, job title, responsibilities and duties of the persons concerned should be stated.

(4) Procedure : This section should provide a description in detail of the business processes underpinning the procedures. The contents should be listed step-by-step and in systematic order. References should be used if appropriate and should be kept in logical sequence. Any exceptions or specific areas of attention should be mentioned. Any diagrams, charts or figures which can assist the users in understanding the procedure should also be illustrated.

(5) Records : Any records/data generated as a result of using the procedures must be identified and/or retained as evidence of adherence to it.

(6) Documentation and references : Any referenced documents or forms associated with using the procedures or needed to prepare them must be specified here.

Notes : Any relevant additional information related to the procedures should be entered in this section.

3.2.2.2 ISO9000 Standard Operating Procedure form filling instructions

Table 3-3 shows an example of the form along with instructions which is to be used as a template for form filling. The IT Manager or the IS Consultant should be responsible for filling out this form in consultation with the business management personnel to define the purposes, processes and software development for supporting the business processes. As mentioned in Section 2.7.3, the JRP and JAD sessions in the DSDM project would provide an ideal environment for the form filling purpose.

(Company Name) – Quality Procedure		PROCEDURE NAME			(Procedure No) Q_ _ _ _
1. PURPOSE (Explain why and for what, e.g., this document gives the procedure for………. and state what the business objectives are to be met) 2. SCOPE (Give who and what areas covered and exclusions) [(1) Definitions] (optional) 3. RESPONSIBILITY (Give job title or name of dept/unit responsible for implementing the document and achieving the purpose) (1) (job title, responsibilities and duties) (2) …… 4. PROCEDURE [DETAIL OF POLICY] (List step by step, what needs to be done. Use references, if appropriate, keep in logical sequence. Mention any exceptions or specific areas of attention and illustrate whenever possible with a Flowchart) (1) (Subsection as required. Each subsection should relate the distinct step / stage / aspect of procedure) (a) (Sublist as required) (i) (Sub-sublist as required) (Figure / diagram should be provided if necessary in the attachment page) 5. RECORD (Identify which records/data are generated as a result of using the procedure and/or retained as evidence of adherence to it). 6. DOCUMENTATION AND REFERENCES (Identify which referenced documents or forms are associated with using the procedure or what may be needed to perform it. Use examples, if appropriate.) (1) (one subsection for each document) 7. NOTES 1. (Enter any foot notes here)
Issuing Department:	Approved by :		Date:	Revision:	Total pages
				1.0

Table 3-3 : ISO9000 Standard Operating Procedure for Business Form (with instructions)

3.2.2.3 ISO9000 Standard Operating Procedure objectives

The drafting of the ISO9000 document takes place at the meeting between the business management and the IT Manager or the IS Consultant. The purpose of the meeting is to define the business processes. All participants should contribute towards:

Defining the business strategies based on the results of the SMP Checklist Manual Assessment exercise;

(2) Identifying the context of business mission and project requirement statements;

(3) Describing business processes / procedures;

(4) Anticipating possible users / business benefit;

(5) Preparing any further actions for the participants.

3.2.2.4 ISO9000 Standard Operating Procedure criteria

As an extension of the ISO9000 standard, in addition to the normal form-filling procedures, this thesis has proposed four criteria for the project participants to meet when preparing the document:

Consistency : The consistency concept is intended to determine that items of data conform to a certain procedure format and are not internally contradictory. Each new procedure must be written using the same format as set out in the procedure template. If a company wishes to change the format of any procedures then it must clearly state the change and show the effect of that change on its procedure template. When the change of format is approved and implemented, all the procedures written in the old format must be updated.

(2) Completeness : All the parts and components related to a certain business process must be clearly described in the procedure. If, however, there are any other procedures related to that procedure, this should be clearly indicated by including pointers to these procedures.

(3) Modularization : The content / length of a procedure reflects the complexity and size of a certain business process or a set of business processes. Different sections in a procedure must be clearly distinguishable from each other to enable the reader/user to check if the same section heading appears in different procedures.

(4) Change Management Control : The key themes are to:

improve business performance, and, equally important;
analyse the synergistic impact on business effectiveness.

The procedure must support these two themes. Requests for changes are those requests (or escalating issues) that will affect the overall organisational business processes. Scope change requests, like issues, will have negative effect if not properly managed. Therefore, the Change Management Control should include the ability for:

Examining change requests to determine their necessity and/or importance;
Rejecting requests for changes in the procedures if considered to be inappropriate by management;
Prioritising changes in consultation with the management;
Monitoring the change progress;
Reporting change status to management as well as procedure users;
Tracking changes and updating procedure versions;
Providing the management with the facilities to track trends in change of business process activities after the change of procedure.

The above provisions are adopted by Oskarsson [Oskarsson et al 1996].

3.2.2.5 Graphical Representation of ISO9000 Standard Operating Procedure

Flowchart is used as a means of graphical representation of the ISO9000 Standard Operating Procedure. A Flowchart is a pictorial representation showing all steps of a process and is regarded to be a useful tool for examining how various steps in a process are related to each other. A Flowchart uses easily recognisable symbols to represent the type of processing performed [GOAL/QPC 1985]. The top-down functional analysis of business operational systems of any size leads to a multi-level Flowchart. Enterprise systems require a structure for managing the sheer size of models. The structuring mechanisms of a Flowchart provide a means of tackling the scale and complexity of different kinds of business operations. A Flowchart is based on functional decomposition. The response to an event depends on the state of the next event receiving it, and can include a change of state or the sending of a further event to the original event. This is referred to as an iterative process and that is the reason why we do not only see the flow going forward but sometimes also going backward. This points out to the user that if a certain event cannot be fulfilled or the result is anticipated to be unsuccessful, the user has to go back to the previous stage and proceed again. Figure 3-3 shows the most commonly used categories of symbols in a Flowchart.

Figure 3-3 : Flowchart representing ISO9000 Standard Operating Procedure

As illustrated in Figure 3-3, different shapes serve different purposes. Details of various functions are listed as follows [GOAL/QPC 1985]:

(1) Action refers to a change from one state to another through the performance of tasks/activities.

(2) Alternate process indicates that there are two different ways to do the same task.

Decision refers to the passing of judgement on an issue under consideration.
Input refers to a command transmitted from the user to the system.
Output refers to the data available to the user from the system.
Start refers to the beginning of process. Finish refers to the end of process.

(7) Director of flow refers to the movement from one process stage to the next one.

(8) Connector refers to at any stage of the business process when it is necessary to break down the main process into different sub-processes, the connector indicates the reference number of sub-process.

3.2.2.6 Criteria for decomposing procedure

The purpose of decomposing a procedure is to make a single procedure more comprehensible. This thesis suggests that under three situations, it would be necessary to decompose a single procedure into several sub-procedures. The breakdown of a procedure should be decided by the IT Manager or the IS Consultant in consultation with the management personnel. These three situations are:

(1) Long Procedure : In some situations when the business processes are too long and complicated, it is necessary to decompose them into different procedures. The main procedure will describe an overview of the main activities involved in the business processes and the sub-procedures will describe the sub-activities related to the main activities.

(2) Complexity of Flowchart : When there is excessive complexity to the Flowchart, for example, when the size of a Flowchart has exceeded an A4 sized paper with a 6-point font (the minimum font size applied to the text on the Flowchart), the Flowchart will have to be split. This also requires the procedure document to be broken down into different sub-procedures accordingly.

(3) Sharing of Tasks : If the same task is to be performed in different procedures, that task would become a common sub-procedure to support different main procedures. The common sub-procedure would be indicated in the relevant main procedures as the referring sub-procedure.

3.2.2.7 Change of procedure

To achieve the spirit of ‘continuous improvement’, the procedure should be flexible and responsive enough to allow for changes. Even if no particular changes are specified by the business, it is still suggested that the procedure should be reviewed by business management at least every six months.

3.2.3 Object-Oriented modelling level

As discussed in Section 1.4, Object-Orientation (OO) is capable of modelling complex software system and is regarded ideal to model business processes. Research has demonstrated that the resulting software for supporting business processes can be improved with OO technique as OO has a clear boundary of modularity and dependency [Jacobson et al 1994]. Objects can also handle business changes better and can simplify business modules. The graphical representation of OO makes it much easier to conduct analysis and design.

In the DBOA model, business processes are modelled by the Unified Modelling Language (UML) [Booch et al 1998]. As described in Section 2.3.2, UML is an OO analysis and design (OOAD) modelling notation accepted by OMG as an industrial standard. UML prescribes a standard notation for modelling OO systems with descriptions of the underlying semantics of the notation. There have, until recently, been various different OOAD methods. But there is now a single, standard set of notation for modellers to use. Being a standard notation, different designers modelling different systems are able to understand each other’s designs. UML also enhances the reuse of design models in other systems within the same business domain or in other business domains. As claimed by [Booch et al 1998], UML can be used to model both software and non-software systems. The versatility of UML is considered to be ideal to convert the Flowchart Diagram, predominately a business model, to a software model.

3.2.4 Database Management System Level

The fourth level is the Database Management System (DBMS) level, a substrate of legacy and/or non-legacy information systems which must interface with the OO layer in a BO. The historical data locked up in the legacy environment is too commercially valuable simply to ‘throw away and start again’. Through systems integration and configuration, a scalable and flexible architecture would enable the existing DBMS to be modernised, updated and integrated with a new generation of software. This involves complex programming and a sophisticated understanding of the ‘archaeology’ of the systems to enable a wide range of protocols and legacy programming languages to converge towards an open platform, such as distributed computer system, and more user-friendly interface such as a windows environment.

3.3 Business Object Model

Figure 3-4 illustrates the structure of a BO. The BO firstly captures the organisational business situation, measures business performance, determines business directions and identifies business strategies. Business strategies are defined by the business processes using the ISO9000 Standard Procedure. OOAD modelling techniques are used to model the business processes. The DBMS ensures the interfacing between newly-developed software applications and the existing legacy or non-legacy database system.

Figure 3-4 : Business Object Model

Although an individual BO might represent a particular business application, the BO built within a business domain can be reused in other applications either within the same organisation or other organisations. To enable an effective reuse of BOs, the next section will discuss the Business Object Architecture (BOA).

3.4 Business Object Architecture Framework

The current situation of software reuse is predominantly restricted to the code level. It is also the scope of this research, as stated in Section 1.6, to enable the reuse of software on a higher-level of object components with business abstraction, through the development of Business Object Architecture (BOA).

Both conceptual model repositories (i.e., the Business Strategy Repository, Business Process Repository and OO Model Repository) and logical repositories (i.e., the Application Source Code Repository and Database Management System Repository) are to be developed within the BOA. As depicted in Figure 3-5, there are two Repository Modules, namely: (1) Local Repository Module (a collection of four different repositories namely: Business Process Repository, Business Strategy Repository, OO Model Repository and DBMS Repository); and (2) Internet/Intranet Repository Module.

The user interface communicates with the local repositories through the BOs on two occasions. The first occasion is when the components in the repositories need to be retrieved for further manipulation or alterations or reuse in another project. The second occasion is when the users want to add new components to the repositories. There are two types of users: (1) Development users, such as the technical developers and programmers, who have access to all levels of the BOA and can manipulate the components in the Repository Modules; and (2) Application users, such as Business Managers, operations staff or customers, who only have limited access to the BOA at the application level only and cannot manipulate the Repository Modules.

The BOs will filter the information received from the user interfaces and pass it on to the appropriate repositories. When the users create/update/reuse a component through the user interfaces, two types of reference links will be created: (1) User interface reference links to each repository; and (2) Component reference links to each user interface. To allow remote access, the user interface must also be (hyper-)linked to the Internet/Intranet Repository Modules. This would enable both the customers and the staff to logon to the system through the Internet/Intranet in the same manner as the users from the local access. This would also enable remote users and local users to share a single component. When the Internet/Intranet users want to send the newly created or modified components back to the Local Repository Modules, the input route will be the same as the output route. The Internet/Intranet Repository Module is the physical area, where components created and manipulated by different Internet/Intranet users will be stored and transferred back to the local repository modules. The Internet/Intranet Repository Module is governed by the same storage rules that have been defined in the Local Repository Module. Both the remote and local repository modules mirror each other. Using search engine technology, users can also search the information online by targeting groups stored in the Local Repository Module, such as customers, buyers or Insurance Underwriters, by names, dates or numbers.

Figure 3-5 : Business Object Architecture

3.5 Dynamic Systems Development Method

The DBOA proposed in this thesis attempts to support organisational SMP. SMP is set by business executives or decision makers based on their business expertise. For this reason, business management involvement is crucial in software development. The critical success factor in software development is not just the technological advancement but also its suitability to the business.

An effective project management can provide a good control for monitoring the project process to ensure that projects can be delivered on time, within budget, and be useful to the business. The value of project management becomes apparent when it is examined more closely in the light of its bearing on the improvement of business performance. Good project management should:

give the best possible business benefit;
deliver the solution in the shortest time span;
be cost-effective in terms of material and human resources.

These three business objectives are used to form the basis of a modern understanding of software quality. The best business solution is pragmatic [Butler 1995]. According to this principle, an effective project management is most likely to achieve the critical success factors as set out in the SMP. This is a compelling reason in favour of the BOA development.

As discussed in Section 2.7, the Dynamic Systems Development Method (DSDM) is a project management approach where iterative prototyping life cycle is applied with substantial business users’ involvement in order to improve the communication between the people from both business and IT sides.

3.6 Integration of BOA and DSDM

On the one hand, many business organisations have observed that however truly ‘object-oriented’ it is in various OO methodologies they may aspire to be, many organisations are still very much tied to a relatively ‘waterfall’ view of the development process. In particular, such a process concentrates on the stages of analysis and design, assuming a traditional, large top-down progression from one stage to another – thereby ignoring the benefit of the bottom-up approach. As mentioned in Section 2.5, the top-down approach is relatively more costly than its bottom-up counterpart.

On the other hand, an OO approach is justified, to a greater or lesser extent, by the gains achievable through the ‘engineering of reusable components’. This suggests quite a different view of the development life cycle, possibly including such stages as:

the characterisation of the system in terms of goals and requirements;
the analysis of the application’s processing pattern and system type;
the identification of existing systems or frameworks which could provide reusable software components;
the design of software structures incorporating tailored pre-existing objects and newly-created ones;
the massaging of new objects into a suitable form for retaining in class libraries.

The above stages bear some connection to a prototyping approach, in which simple and generalised parts of the system are generated quickly and tailored later on to satisfy precise requirements. A prototyping approach tends to be informal, but has recently been linked with information engineering as well as to the Computer Aided Software Engineering (CASE) tools environment. Nevertheless, among the OO fraternity, informal evolutionary development, without formal analysis and design, is often practised. In some cases, the analysis/design and design/implementation boundaries become blurred as iteration takes place. Methodologies that adapt the development life cycle to take conscious consideration of reusability of class libraries are thus rare in current OO practice [Tagg et al 1992]. As discussed in Sections 2.7 and 3.5, the Dynamic Systems Development Method (DSDM) project development life cycle has provided a favourable environment for the BOA development to bring IT professionals and business management closer together. The integration of BOA and DSDM into the Dynamic Business Object Architecture (DBOA) attempts to provide organisations with a complete project development life cycle and a review mechanism to evaluate software development against business performance. A change in business performance would indicate to organisations a need to modify their business in terms of strategies, processes and software applications to achieve their ultimate business goals. DBOA also seeks to offer a thorough, systematic and coherent way of minimising risk at each stage of the development process which on some occasions might be omitted due to the negligence or incompetence of people who perform the processes. The graphical representation of DBOA proposed in this thesis is illustrated in Figure 3-6. BOA is situated at the centre surrounded by the DSDM life cycle. The white arrows between the BOA and the DSDM life cycle indicate that the BOA model can always be re-architectured at any stage of the life cycle. Among each life cycle, there is an incremental prototyping approach through a number of distinct phases moving clockwise from the top.

Figure 3-6 : Dynamic Business Object Architecture

The starting point is represented by a black dot. Each life cycle contains five time-boxes arranged in the following order:-

Time-box 1.1:- An SMP ‘Open-ended’ Questionnaire is used to conduct the SMP ‘Open-ended’ Question interviews with the business management to capture the organisational business situation and to identify business objectives.

– An SMP ‘Closed’ Questionnaire is used to conduct the SMP Checklist Manual Assessment exercise with the business management, to measure business performance and to identify business strategies – if they exist; or to establish the business strategies otherwise.

Time-box 1.2: – A Business Mission Statement is established to identify the business requirements based on the results of the SMP Checklist Manual Assessment exercise. A Function Points Table is used in the Project Requirements document to estimate project development time and resources required.

Time-box 2.1:- A set of ISO9000 Standard Operating Procedure forms are used to define the business processes in response to the Business Mission Statement and Project Requirement Statement.

Time-box 2.2:- The OO Modelling technique using UML Standard Notation is used to model the Business Processes.

Time-box 3 : – A Functional Prototype is produced for testing by the business users. Users’ comments and feedback are used to modify the functional prototype and to develop a Design Prototype.

Time-box 4 : – A Design Prototype is developed for further testing and modification. At this stage, non-functional requirements such as the integration of the newly-developed application and the existing legacy or non-legacy database system should be carried out. Pilot Testing also takes place at this stage.

Time-box 5 : – The system is implemented after the modification of the Design Prototype and the Pilot Testing are completed. User approval is sought and user training is conducted before the system goes live.

In every DBOA post-project phase, an SMP Checklist Manual Assessment exercise is conducted to review the business performance and to modify the business

processes, system modelling and application development accordingly. To fulfil the spirit of ‘continuous improvement’, the SMP Checklist Manual Assessment exercise should take place periodically. This thesis suggests a six to twelve month interim period as in most companies, Trading and Profit/Loss Account Statement and Financial Reports are usually produced either six months (half yearly) or twelve months (yearly). Financial figures reflect company’s profitability and they are useful as indicators in the improvement of business performance.

As depicted in Figure 3-6, the ‘continuous improvement’ spiral continues to move on cycle-after-cycle. This ‘spiral’ approach is adopted from Boehm [1986] where a ‘spiral’ model is used in software development and enhancement.

3.7 Reuse Strategy

One of the attractions of OO is that it enhances the reuse of software components. However this does not come for free. Reuse requires strategies and techniques. The implementation of reuse needs to be well planned. Lim [1998] points out that a successful adoption and institutionalisation of software reuse can be best achieved through a holistic and multidisciplinary approach that encompasses not only the technical, but also the managerial and organisational aspects of reuse. Such an approach would manage the adoption, economic, strategic, personnel, organisational, metric, legal, process, tools and marketing aspects of reuse as a business. Therefore, reuse must start at the conceptual modelling level and not at the code level.

Figure 3-7 is a conceptual model which shows how the BOs within the BOA can form a Reuse Library. The centre of the Reuse Library contains a pool of Common Objects. A single Object inside this pool can be reused by different BOs. For example, the ‘Customer Object’ can be reused by the BOs of ‘Credit Limit Application’, ‘Insurance Claims’ and ‘Bond Insurance’.

Outside the boundary of the Common Object layer, a pool of Common Processes is situated. Like the Common Objects, a process such as ‘Check Customer Details’, can be reused in different BOs such as ‘Credit Limit Application’, ‘Insurance Claims’ and ‘Bond Insurance’.

Outside the Common Process layer is a pool of Common Strategies. Each of these strategies can also be reused by different BOs. For instance, ‘Customer Services Strategy’ can be reused by the BOs of ‘Credit Limit Application’, ‘Insurance Claims’ and ‘Bond Insurance’.

Figure 3-7 : Reuse Library

3.8 Closing Remarks

This chapter has described the development of a DBOA. DBOA is an approach intended to bridge the communication gap between business management and IT professionals with the goal that software delivered would become ‘Business Solutions’ and not just ‘Software Products’. Organisations need Strategic Management Planning (SMP) to help them become more competitive and successful. And DBOA is intended to support the organisational SMP with software development.

Various well-established and mature technologies have already been used in trying to solve this fundamental and well-known problem with little success. For this reason, this research attempts to exploit the new and emerging technologies such as BOs, BOA and DSDM which may potentially deliver some new solutions to solve this old problem.

However, questions remain: How is the reliability of DBOA? And how is DBOA’s applicability to the business environment? The next chapter will present an analysis on the reliability and applicability of DBOA.

~ Success is never final and failure never fatal. It’s the courage that counts ~

(George Tilton)

CHAPTER FOUR : ANALYSIS OF THE DBOA APPROACH

4.1 Introduction

Before determining the reliability and applicability to different business environments of the DBOA, it is instructive to understand the intrinsic components of the DBOA in advance so that IT professionals would be able to use the DBOA to meet the business requirements at an optimal level. These issues have motivated the work presented in this chapter which investigates the reliability and applicability of the important characteristics when using the DBOA.

Both quantitative and qualitative measurements should be adopted. An analysis framework should be established. Firstly, factors contributing the business success should be studied. Then the issues raised behind these critical success factors should be identified. Next, well established analysis methodology(ies) related to this purpose should be more closely examined. Finally, the DBOA should be moulded into this analysis methodology.

4.2 PEST Analysis

As mentioned in Section 4.1, some of the factors contributing to the success of an organisation are: (1) profitability; (2) growth and (3) reputation. To achieve these, we need to look at the overall environment of the organisation both at the macro-level such as the global factors of political change, economic climate and social culture and micro-level such as the local factors of organisational behaviour and technological advancement.

A useful device to help with this process could be PEST Analysis. As discussed in Section 2.2.5.2, PEST is an acronym which stands for:

Political Environment;
Economic Environment
Social Environment; and
Technological Environment

Swords [Swords et al 1997] describes the original idea of PEST analysis is to assist organisations to collate as much relevant information as they can about their business environment. The trends and the issues are then clustered in the four most significant categories under the PEST headings, in the environment.

The next stage is to investigate what the likely impact is going to be and what direction the trend is likely to move in. There are three key impacts as a result namely:-

Impact on the total size of market demand;
Impact on the relative size of market segments within the total demand; and
Impact on the type of product demand.

If there is a change in the political climate, this might affect the demand for certain products/services from the customers. The change of tastes/directions of consumers might bring a certain social change which might in turn require a change of technology to facilitate it. The PEST Analysis is to help capture the likely impact of a particular issue and to calculate the probability that this issue will occur. The impact and probability are quite distinct. The impact can be high but the probability can be low and vice versa or equal. Figures 4-1 to 4-5 show the four segments of impact/probability issues under the four PEST environments. An example of an insurance company is used to define its particular business environment.

Figure 4-1 : Impact/Probability issues in Political Environment

Figure 4-2 : Impact/Probability issues in Economic Environment

Figure 4-3 : Impact/Probability issues in Social Environment

Figure 4-4 : Impact/Probability issues in Technological Environment

4.3 Moulding SMP Checklists to PEST Analysis

In view of the PEST Analysis framework, a more specific question, and one which is relevant to the SMP Checklists in the DBOA in particular, concerns the strategic factors in the PEST environment. This argument has motivated the investigation to address this question. It has been found that the seven strategies in the SMP Checklist (see Appendix G) have indeed covered the impact/probability issues raised in the PEST Analysis through:-

(1) Low Cost Strategy

Stabilise Insurance Premium (Economic)

Reduce profit margin at low end (Social)

(2) Product Differentiation Strategy

Change of business cycle (Economic)

Environmental awareness (Social)

Change of product life cycle (Technological)

(3) Product Efficiency Strategy

Change on Insurance Regulations (Political)

Control on types of Insurance (Political)

Industrial restructuring (Social)

(4) Insurance Market Competitiveness Strategy

Control of Insurance Policy (Political)

Control on Insurance Market Accessibility (Political)

New Entrants (Economic)

Maturity of Insurance Market (Social)

(5) Customer Services Strategy

Change of people’s lifestyle (Political)

Insurance Fraudulence (Economic)

(6) Human Resources Strategy

Updating the skills of human expertise (Technological)

(7) Information System Effectiveness Strategy

Automation (Technological)

Flexibility of rebranding products/services (Technological)

4.4 Conclusions of Analysis

As can be seen from Section 4.3, the seven strategies in the SMP Checklists have covered the aspects/probabilities of the PEST Analysis. As discussed in Section 3.2.1.3, PEST Analysis is amongst various well established methodologies namely Porter’s Five Force Model, Value Chain Analysis, Relationship Marketing, Generic Strategies and SWOT Analysis used to develop the SMP Checklists. SMP Checklists are only a part of the DBOA. DBOA also consists of software application development and project development lifecycle. Hence, DBOA would be essential if solutions are to be successfully embedded into organisational environments in terms of political, economic, social and technological.

The Conventional approaches (i.e. business strategies and IT strategies are in two separate streams) may not ensure the software application to successfully support the business so an integrated approach (i.e., combining business and IT strategies in the same stream) has been proposed through DBOA as potentially, a more effective solution. Central to this new approach is the concept, that business goals, aims and objectives are effectively included in software development.

Still, the main criticism of the approach is likely to be that the reliability of DBOA which much depends to some extent on the maturity of techniques. The intuitive counter argument would be that these algorithms would vary widely from one step to the next but this will depend on how it is practised by the IT professionals and in particular, the response from the business management. A more rigorous argument is provided in the concluding section of Chapter 5.

4.5 Closing Remarks

This chapter has presented an analysis of the reliability and applicability of DBOA to different business environments. PEST Analysis consists of four categories of issues in a business environment: political, economic, social and technological and has been used to evaluate the applicability of DBOA. The strategic factors in the seven strategies of the SMP Checklists are then moulded to the PEST’s impacts/probabilities issues in the four categories of business environment. It has been found the SMP Checklists have provided a complete set of strategic factors to cover the impacts/probabilities. This supports the applicability of DBOA in the business environment. However the reliability of DBOA still largely depends on the maturity of the techniques used and the level of proficiency when it is practised.

For this reason, it is necessary to demonstrate the reliability of DBOA through practice. The next chapter will apply the conceptual model of DBOA to a practical business solution. It will be implemented within a real business environment through a case study project in a credit insurance company.

~ The secret to success is to do the common things uncommonly well ~

(John D. Rockerfeller Jr.)

CHAPTER FIVE: IMPLEMENTATION OF

DBOA THROUGH A CASE STUDY PROJECT

5.1 Introduction

This chapter will present an extensive case study using DBOA. The purpose of applying DBOA in a real business environment is to validate this approach in a practical situation. The case study was carried out in a credit insurance company. The evaluation of the case study revealed that both the management and IT department staff felt generally satisfied that the DBOA approach had helped reduce the communication gap between them significantly. They also considered that DBOA was relatively a more effective way to develop software applications to meet their business objectives than the methods they had previously used.

However the case study also highlighted several difficulties encountered during the implementation of DBOA which had to some degree, affected the progression of the project. Those difficulties will be described in detail in the evaluation of the case study section. As a result of the implementation difficulties in DBOA, further research work is required in order to increase the effectiveness of this approach.

5.2 Project Initiation

CAD Consultants Ltd. (CAD), a credit insurance company, the sponsor of this research project, is a wholly owned subsidiary of the BTR plc group (an industrial engineering conglomerate with a revenue of £8 billion listed on the London FTSE stock exchange). It forms part of the BTR group’s financial services and provides management services in trade finance to BTR’s other subsidiaries. The main functions of CAD are credit insurance management, debt collection, bond insurance and insurance claims. The company was established in 1976 and has been in profit since opening. However the company’s profits have fallen in recent years. Several factors are considered to have contributed to this decline in profitability:

Sell-off of BTR’s subsidiaries

Since 1995, BTR has disposed of nearly 40% of its subsidiaries. CAD has thus lost some major customers such as Dunlop Slazenger, Westinghouse, Pilkington, Hawker-Siddney and Nylex.

High Insurance Premiums

Although credit insurance is a protection against the seller’s loss if a buyer fails to pay after the goods/services have been delivered, high insurance premiums have made many sellers reluctant to insure their products/services. They either request payment in advance or simply run the risk of buyer defaulting.

Fierce Competition in the Insurance Market

As mentioned in Section 3.2.1.3.4, the insurance industry is a lucrative business. However it is also a cut-throat industry. The competition from existing competitors and new entrants has posed a threat to CAD.

High Staff Turnover

There is already a skill shortage in the credit insurance labour market. People with credit insurance expertise are highly sought after all the time. After the departure of a number of key staff (most notably business managers and credit analysts), CAD has found it difficult to fill the vacant positions. Therefore, the company was short-staffed for a period, while the existing staff were trained to take on new responsibilities.

Deficiency in Information Technology

The company’s information systems contained data and services which were run on bespoke commercial systems written for, or by the company over the last twenty years. The problem was that these computer-based information systems had become inadequate to perform the tasks necessary to meet business requirements, and to cope with the volume of work the business was receiving. The existing business processes were still predominately paper-based and operated manually, and were slow and unreliable. Whilst frequent breakdowns of the computer systems caused much inconvenience to business operations, the company was concerned at the gradual loss of its bargaining power and feared that its market position in the insurance industry might gradually decline. Hence, the need to improve the company’s existing information technology was paramount. The old information systems were difficult to maintain, relied heavily on manual input and were poorly documented. Another problem was that the systems were based on versions of the database that were about to become obsolete. As a consequence, there was a high risk of losing technical support from both the software and hardware vendors.

The priority business goals were to retain the company’s market position and to stop the decline in profits. Although CAD’s management were aware of their business situation and were keen to discover means of improvement, they also wanted to have a proper strategic plan covering both the business and technical sides. As part of company’s long-term business strategy, the management understood that they should not focus on just ‘quick fire’ solutions, but rather on long-term planning with significant bottom-line impact. Like many other organisations, CAD’s business and IT strategies were running in two separate streams. For this reason, management found it difficult to justify IT investment against business benefit. The management wanted to assure that their investment in IT would generate worthwhile return in terms of business gains.

Although the IT approach should include ‘best of breed’ technologies and packages as it may be advantageous to be on the leading edge in some areas of IT, CAD also needed to have the right systems in place to process various business transactions. On the one hand, the management were keen to take the advantage of IT to improve their business performance; but on the other hand, the company watched its budget carefully, as they are not a company that throws money around. The company was clearly focused and it could not afford for things to fail when they had invested substantially in them.

DBOA was recommended to the company and it was explained to the management how it could link their business and IT strategies together. CAD’s management agreed to try DBOA as a test case in their organisation.

5.3 Project Plan

Table 5-1 is the DBOA Project Plan summarising the main components that should be produced during each DBOA project development phase. The overall plan of the project was divided into six discrete phases namely: (1) Feasibility Study; (2) Business Study; (3) Functional Prototype; (4) Design Prototype; (5) Implementation; (6) Post-Project Review.

The deliverables (i.e., the reviewable products / documentation etc.) produced by each project phase will be described in the next section. They are used as the basis of project review and control. They also give those involved in the project a reminder of what the deliverables will cover, when, and by whom, they will be developed. In accordance with the DSDM practice, it is expected prototypes will evolve from earlier prototypes, and into the final production version.

DSDM Phase

DSDM Components

Core Models Produced

Support Models Produced

Documentation Produced

(1) Feasibility

Study

– Business Objectives

– Strategic Management

Planning (SMP)

– Business Vision

– Business Requirements

– Business Scope

– Business Activities

– Business Strategic Models (SWOT Analysis, PEST Analysis, Five Forces, Generic Strategies, Relationship Marketing, Value Chain Analysis, Stakeholder Analysis, Brand Strategy)

– SMP Questionnaire / Interviewing Form

– SMP Checklists

– Factors and Definitions for Business Strategies

– SMP Interviewing Forms

– SMP Interviewing Transcripts

– Pre-Project Phase SMP Manual Assessments

(2) Business

Study

– Business Functions

– Business Rules

– System Users

– Business Object (BO) Conceptual Models

– Business Object Architecture (BOA) Model

– Object / Property, Operations/ Relationship Definitions

– Repositories / Reuse Library

– Business Process Models (Flowcharts)

– UML Notation (Use Case Diagrams, Activity Diagrams, State Diagrams, Object & Class Diagrams, Sequence Diagrams, Collaboration Diagrams)

– Business Mission Statement

– Project Requirements using Function Points Table

– ISO9000 Standard Operating – Procedure for Business Processes

(3) Functional

Prototype

– Functional Prototype

– User Interfaces

– Functional Requirements

– 1^st Cut Physical Object Model

– Refined Business Process Models (Flowcharts)

– Refined UML Notation (Use Case Diagrams, Activity Diagrams, State Diagrams, Object & Class Diagrams, Sequence Diagrams, Collaboration Diagrams)

– Refined Function Points Table

– Refined ISO9000 Standard Operating Procedure for

Business Processes

(4) Design

Prototype

– Tested System for Pilot Testing

– Refined User Interfaces

– Non-Functional Requirements

– Optimised Physical Object Model

– Refined Flowcharts

– Refined UML Notation

– Refined Function Points Table

– Refined ISO9000 Procedure

for Business Processes

(5) Implemen-

tation

– System Configuration / Integration

– Data Take-on

– System Goes Live

– Live System Interfaces

– Task Descriptions

– User Manual

– Training Programmes

– Methodology Guide / Specification

(6) Post-Project

Review

– Implementation Review

– Project Enhancement

– Analyse/Collate site throughput information

– Document Omitted/Further Requirements

– Post-Project Phase SMP Checklist Manual Assessment

Table 5-1 : DBOA Project Plan

5.3 Prototyping Strategy

In DSDM, the Time-boxing technique controls the pace of design and development that is so essential to the project. Computer-based techniques make this feasible. It would, indeed to be quite impossible to entertain the idea of tight schedule time-boxes without a means of maintaining both design documentation and implementation in a flexible and responsive way. The implications for the qualities of, and the criteria satisfied by the delivered products, are quite clear. Therefore, both the BO design model and the interface prototype must clearly reflect the business, be flexible to change, quick to build/assemble, reusable and most importantly, support the business.

In this project, a prototyping strategy was to produce a version of the working system to give an idea to the business users of how the prospective application would look like. Hence during the feasibility and business study time-boxing stages, an ‘Online Credit Limit Application (CLA) via the Internet/Intranet’ (OCLAVI) Business Object model was created (details of which will be explained in Section 5.6.1.5). The Functional Prototype and the Design Prototype deliverables were produced in a piecemeal fashion, allowing the users to test and change their requirements.

5.5 DBOA Development Life Cycle Building Blocks

DBOA projects make use of the DBOA Development Life Cycle Building Blocks, which have been designed as part of this thesis. As illustrated in Figure 5-1, the DBOA Building Blocks are used for planning, developing, implementing and reviewing the DBOA project for maximum efficiency. The DBOA Building Blocks are different from the DBOA Project Plan as listed in Table 5-1. Whilst the DBOA Project Plan indicates what ‘deliverables’ are to be produced at different project phases, the DBOA Building Blocks act as a road map indicating what ‘tasks’ must be carried out during different phases. The Building Blocks comprise consistent approaches, techniques and tools, described in a ‘step-by-step’ manner, to assist the project team to improve their efficiency in delivering a complete system on time, within budget and which is appropriate to business needs.

The Building Blocks provide both business management and IT professionals with a full picture of the business processes and management techniques. They serve the purpose of helping the people involved in the project decide what is essential to their business and what can be traded off for speed, although reversibility ensures that any such decision may be subject to review during the post-project phase.

Figure 5-1 : DBOA Development Life Cycle Building Blocks

5.6 Time-boxing

DBOA was developed with heavy emphasis on the importance of Time-boxing. Figure 5-2 shows how the DBOA development process (refer back to Figure 3-6 in Section 3.6) fits into different Time-boxes.

Figure 4-2 : Time-boxing

As suggested by the DSDM Manual [DSDM 1997]: “…Requirements can change, time can never slip…”. DSDM defines Time-boxing as: “…Setting a deadline by which a business objective must be met…”, and suggests that each Time-box should be set for each clearly defined delivery objective. For instance, a prototype, demonstrating particular functionality, should take three to six weeks to develop. Time-boxing techniques could provide a control mechanism to increase the possibility of a delivery time capable of meeting the deadline. A DBOA project comprises five Time-boxes, namely: (1) Feasibility Study;

(2) Business Study;

(3) Functional Prototype;

(4) Design Prototype;

(5) Implementation

After the initial meeting for the feasibility study, each subsequent meeting will take place, as a general rule, at the end of each time-box. It will take the form of a review of the Time-box phase, and an identification of the next phase. During these ‘End-of-project-phase’ meetings, business users (managerial and operational staff) were invited to test the prototype online. The IT department staff then collected the business users’ comments and feedback in order to modify the prototype.

Imposing Time-boxes on a project does entail subjecting the project team to pressure. Technical developers have to meet a number of deadlines throughout the project (instead of just one in the traditional waterfall life cycle approach).

However, in practice, this very tightly controlled schedule is not only feasible, but also keeps the project team strongly focused on the work in hand. It is, of course, critical that the user community is as committed as the IT professionals, and that events such as user acceptance testing are set quite definitively in regards to diary commitments. It has to be said that on occasions the schedule might seem severe, and there is an argument that such a strong emphasis on ‘deadlines’ might detract from further useful discussion and debate. On balance however, both the developers and end-users would not have been so committed had any less rigorous approach to time management been adopted.

5.6.1 Time-box 1 : Feasibility Study

5.6.1.1 Joint Requirement Planning / Joint Application Development

The project was launched in March 1998. The duration of Time-box 1 was four weeks. During the Feasibility Study phase, the Joint Requirement Planning (JRP) and Joint Application Development (JAD) took place in the form of a workshop / project meeting. This format provided an ideal environment for business management and IT personnel to work more closely together.

A project development team was formed comprising three IT department staff namely the IT Manager, the System Development Consultant (author of this thesis) and the System Analyst/Programmer together with four business personnel, namely two Business Managers and two Account Executives.

5.6.1.2 SMP ‘Open-ended Question’ Interviews

In-depth interviews were carried out individually with the seven senior management staff (Managing Director, Operations Director, Commercial Manager, two Business Managers, IT Manager and Financial Controller), as a part of the SMP ‘Open-ended’ Questionnaire exercise. An invitation for the SMP Interview was sent to the management staff (listed in Appendix D). A complete set of transcripts recording the results of the interviews is listed in Appendix E. For the purpose of conciseness, the following tables summarise the results of the interviews.

Question A1: What do you think are the main strengths and weaknesses of your organisation?
Strengths	Weaknesses
Knowledge and expertise in credit insurance	Skill shortage in credit insurance
Innovator of most financial engineering products	Difficulty in management succession
Business expertise in financial and risk management	Hard to find replacement when staff leave
Strong customer base within the BTR plc group	Lack of language skills (French, German, Italian, Scandinavian)
High autonomy of management style, skilful people, experience	Lack of global awareness in terms of market situations
Information technology awareness	A reluctant to change amongst some employees regarding learning the new ways of doing things or new skills
Progressive	Sole reliance on 2 credit Insurance Underwriters (NCM and AON) to supply policies
Bargaining power	Inability to identify marketing resources in other avenues
Competitive pricing	Reliance on 3^rd parties i.e., the insurer services
Network of contacts	The perception of the industry still conservative. It is therefore hard to sell the idea of credit insurance to people
Globalisation	Lack of cover for staff absenteeism
High profile within the BTR group	Small size; not enough human resources
Matured management skills	Lack of forward planning both financially and materially
Uniqueness of industry	‘Fire-fighting’
Long standing relationship with suppliers	Lack of staff training and development
A dynamic organisation

Table 5-2 : Strengths and Weaknesses of the organisation

Question A2 : From your organisation’s point of view, what long- and short-term challenges are you facing?
Long-term Challenges	Short-term Challenges
Globalisation of business particularly in Asia Pacific regions	Facilitation of self-growth with the BTR plc group
World economic slowdown	Getting BTR’s subsidiaries (i.e., CAD’s customers) to accept changes in financial engineering innovation products and services as well as new technology and new concepts
Asian economic recession	Staff training in skills, new products and services
Human barrier (external customers and internal staff)	Develop South American market in 1999
Getting acceptance of change in financial and credit insurance from customers and staff members	Customer relations in mainland Europe, North America and South America
Cannot determine business direction unless BTR’s buying and selling are in place	Staff development
Need to switch decisions very quickly in response to changes	Customer finance (new product from CAD)
Customer relations in Asia Pacific regions	Growing the business
Harnessing different credit insurers	Internet business transactions
Finding alternative sources of insurance and finance suppliers (at the moment, CAD is too reliant on propriety suppliers)	Cross training between credit management team and Business Managers
Launching new products (probably allied to risk management)	Integrating audit and business management
Technological advancement	Retaining non-BTR customers after the sell-offs by parent company
New product development	Credit management team’s consolidating structural changes
Finding and developing new products which are more diversified and versatile to cater for wider spectrum of clientele	Deteriorating global circumstances (both economical and political)
Develop products for clients’ needs	BTR’s ever changing business acquisitions and disposals of subsidiaries
Retain external business ongoing	We have to change our direction quickly in response to these changes
Develop new markets and products	BTR’s sell-offs – have to retain disposed units’ credit insurance business

Table 5-3 : Long- and Short-term challenges

Question A3 : What are your organisation’s aims and objectives?
Aims	Objectives
Grow to a more dynamic organisation with more innovative new products and services	Get customer’s acceptance and take up new products and services
Growth in terms of reputation, size and profitability evenly	Get internal staff to accept and train on the new services and products
Provide BTR units as well as external customers with tools and advice they need to grow their business	Maintain profit
Maximise profit and minimise cost	Self-growth and professionalism
Increase turnover	Regular contact with customers world-wide
Be a lead player in the credit insurance agent field	Trading with the US
	More marketing and business development
	Improve quality of service
	Improve staff standard
	Improve company welfare to staff in terms of financial reward and other incentives
	Provide financial advice and guidance for BTR world-wide and external customers

Table 5-4 : Organisational aims and objectives

Question B1 : What factors do you take into consideration when improving your products/services

Products / services must protect customers to minimise risk

Catering for different aspects of customers’ needs

Ability to provide services to customer at any time in any region

Meet customer needs, availability of products

Competitive pricing, cost effectiveness, speed, product knowledge, product trend, market awareness in terms of customisation or tailoring

Availability in dealing with clients’ queries

Constantly reviewing internal procedures

Table 5-5 : Factors to improve products/services

Question C1 : What do you consider to be the most important factor(s) in maintaining your market position?

To ensure “safe guarding” of customers’ major assets (receivables)

To obtain confidence from customers that whatever CAD introduces, CAD is helping customers’ growth in sales volume and profit line

Cost and quality of service

Competitive pricing, quality of service, flexibility, cost effectiveness, service, friendliness, approachability, professionalism

Table 5-6 : Factors to maintain market position

Question C2 & C3 : What kinds of competitions and competitors you are facing?
Competition	Competitors
Alternative products such as letters of credit	Credit Insurance Brokers, Agents, Underwriters, Insurance Policy Manager
Similar services provided by other credit insurance brokers, agents and Underwriters	Competitors are situated globally
No longer a “captive” business, open to competition from any credit related service providers	Credit Insurance Brokers, Agents and Policy Managers are smaller than CAD
Ignorance i.e., lack of knowledge and understanding of our products and services	Credit Insurance Underwriters such as NCM, Trade Indemnity and AON are much bigger than CAD
Banks as they provide letters of credit as an alternative option of credit insurance
Alternative risk minimisation options such as letters of credit or advanced payment
Alternative services, products available from other sources to provide insurance

Table 5-7 : Competitions and competitors

Question D1 : What is your perception of the relationship between your organisation and its customers?

Not quite satisfied with the current relationship with customers especially CAD has received a lot of complaints especially from its European customers

Need to improve the customer relationship in terms of the quality of CAD’s products (i.e., to be able to minimise trading risk) and the availability of information to customers (i.e., risk management information, buyers’ track records, country risks etc.)

Variable between very good and very poor

Have problems with European customers probably because of the language skill shortage within CAD to serve European customers in different European languages

UK and North American customers seem to be happy

Need to improve European customer relationship, CAD could have provided much better services than it is currently providing

Not good especially in European region outside UK

Table 5-8 : Relationship with customers

Question E1 : What is your personal experience in working at your organisation?

Management team seems to be happy with their current situation. There are some problems amongst the subordinate staff

Some operations staff are very reluctant to accept the change of business and to learn the new products and services

Lack of communication amongst staff members

‘Team spirit’ will improve business performance and quality of services

Easy to change the company but to change the people or to get them to change is so difficult

Staff retention has been a frequent problem (in cycles)

Generally too few people have “carried” the company. In other words, there is a lack of empowerment and delegation within the company

When there are problems no matter big or small subordinate staff or middle management staff will simple refer the problems upward to senior management

Management team members are sometimes too busy to communicate with subordinate staff

There is no training on personal development courses especially for management staff

There has been some credit insurance , time management, languages and legal knowledge training for general staff but not enough

The general staff situation doesn’t look good at the moment

The company should have an incentive scheme for staff members to raise staff morale and loyalty

Staff training, especially in this unique area of credit insurance and trade financial service industries is badly needed

Social functions out of office hours to enable staff members get together in a relaxed environment would also improve the relationship amongst staff and thus would eventually contribute to the company

Communication amongst staff in both formal and informal ways must improve

The company needs to ensure to get the right type of staff with suitable skills

There is also a lack of financial reward and motivation within the company

Staff training is badly needed for existing staff in order to help them to cope with the departure of staff and to improve efficiency

Avoid increasing pressure on staff

Communication is important between subordinate and management staff

Company should also define objectives not only to the management staff but to all the staff

There are some conflicts amongst the subordinate staff members

The general morale in the operations department at the moment is quite low due to the recent departure of some staff

The failure of the company to recruit replacements has added considerable pressure to the existing staff

The operations staff have expressed discontent regarding the current situation

There should be communication at all levels. Financial rewards or other forms of incentive would help to raise the staff morale

The company should lay down plans as to staff training, staff quality improvement and job target etc.

The company should recognise staff’s achievement and output

Team building through retreats, meetings, and workshops involving all levels (not just management!!!) should be encouraged

Staff complain about the inefficiency of the IT system

The approval of a budget from the management to the IT investment is another hurdle for IT development

Table 5-9 : Human Resources

Question F1 : What role do you think the technology plays within your organisation? And what do you suggest to change? And what are your reasons for change?

Role of technology

Technology plays a crucial role within CAD as CAD’s products are its services and all the company’s business transactions are conducted through the computer system. If the computer system is down, virtually no transactions can be carried out and the business will come to a halt.

Very critical as all information supplied is held in the IT system, thus heavily reliant on the computer system.

IT is a must. If the system is down, business will stop immediately

Very critical as information is supplied all held in the IT system, thus heavily reliant on the computer system.

Suggestions to change

CAD’s services must not only be available to UK or Europe. The company should enable its customers to use the services from anywhere at any time.

External communication with CAD’s suppliers and customers via the internet and intranet technology

Speed – the system is too slow

Management want to have a system which can easily generate various reports to provide customers with accurate information and to assist them in making strategic business decisions. At the moment, management have found it either hard or even impossible to do so

At the moment, the management are not happy with the overall standard of the IT system. Everything needs to change including software, hardware, printers etc. The system should be upgraded to be more user-friendly and faster

The company’s financial package Masterpack is really disappointing. It does not meet the user’s requirements. The company needs to upgrade the Masterpack system or totally replace it

Reasons to change

CAD aims at globalisation of our services. Hence, the computer system should assist the company to do so.

Major benefits can be gained through changes such as improved communications, improved working practices and reduced paper flow, improved access to information and the sharing of product development. This is applicable to both internal staff and external customers – both will be better informed.

It will save time and costs if business transactions can be conducted in a timely fashion.

If CAD cannot provide customers with accurate risk assessment reports in a smooth and speedy way, customers will go elsewhere.

The system is too slow and incapable. It does not satisfy the users’ needs and much time is wasted in waiting for the screen to change and in waiting for a report to be printed out from the printer.

The company needs to clarify the issue of the Masterpack package itself that is to ascertain whether CAD has simply not used the Masterpack package to its full potential and therefore the users have a large number of problems, or whether Masterpack itself just cannot perform up to the users’ criteria.

At the moment, it normally takes 3 working days to process a credit limit application transaction and the decision is in paper-based format. If CAD has an internet transaction system, the processing time for a standard credit limit application would be reduced to 10 – 12 seconds and the decision would be in electronic format. The internet transaction would enable the company to cut costs and save time. Operations staff would also have an opportunity to learn new and interesting skills.

Table 5-10 : Technology’s roles and changes

5.6.1.3 SMP ‘Closed Question’ Checklist Manual Assessment

After the SMP ‘Open-ended’ Question interviews, an SMP ‘Closed’ Question Checklist Manual Assessment exercise was held. This time, all seven members of senior management staff were assembled together to conduct the SMP Checklist Manual Assessment in a workshop format. The purpose of this exercise was to review the results of the previous interviews. Any ambiguities or clarifications were raised during this workshop. In the previous interviews, individual interviewees gave their own answers. This time, there was only one set of the SMP ‘Closed’ Question Checklists being used. Every answer provided was either agreed by all the seven management staff or by a majority. The purpose of the exercise was to establish a consensus amongst the management regarding business performance.

Not surprisingly, there were some disputes and arguments amongst the management staff. For instance, some staff had strong opinions with regards to training and development. Others severely criticised the information technology improvement. Some advocated cost and expenditure cuts while others argued that an increase in business volume was the key. Due to these non-agreements, it took nearly a full working day to complete the exercise. It was indeed an exhaustive exercise and a daunting experience to the facilitator (the author of this thesis) of this exercise. Full results of the SMP Checklist Manual Assessment are listed in Appendix H.

5.6.1.4 Business Objectives

In view of the results of the SMP Checklist Manual Assessment exercise, it was agreed by both the management and IT personnel that the establishment of a global access to customers was of primary importance. The business objectives were identified to provide CAD’s services electronically via an interactive Web Site to support the SMP. The following is a mission statement, listing the key business strategies, aimed at:

(1) Low Cost Strategy

The result of the SMP Checklist Manual Assessment revealed that 50% of the Low Cost Strategy had been met at the time of the assessment. Problems identified concerning cost were:

a reliance on 3^rd parties, i.e., the Insurance Underwriters, had added cost;
an inability to identify marketing resources from other avenues;
the legacy computer systems were expensive to maintain, thereby increasing the operational cost;
the company search services from Graydon, Infoseek and Dun & Bradstreet were expensive.

To improve this situation, the project must:

migrate the existing legacy computer system to an open system and use internet technology to reduce maintenance costs;
pay only local phone call rates to communicate overseas through a more effective use of email and internet communications;
enable CAD and BTR to benefit from cost savings through global agreements with credit information service providers to obtain company search reports at a cheaper rate.

(2) Product Differentiation Strategy

The result of the SMP Checklist Manual Assessment revealed that only 25% of the Product Differentiation Strategy had been met. Problems identified concerning product differentiation were:

a lack of financial and material forward planning;
a lack of global awareness in terms of market situation;
a reluctance to change, learn new ways of doing things and acquire new skills.

To improve the situation, the project must:

attract a wider range of customers especially the penetration of foreign markets by offering the services internationally;

use a Web-based business for branding company’s products and services, known as ‘Branding for the Web’;
provide a credit insurance limit application service 24 hours a day, in multilingual and multicurrency facilities as opposed to the traditional 8-hour day, 5-day week services, monolingual and single-currency facilities provided by competitors;
provide an interactive Web Site to enable online decisions.

(3) Product Efficiency Strategy

The result of the SMP Checklist Manual Assessment revealed that 46% of the Product Efficiency Strategy had been met. Problems identified concerning product efficiency were:

the processing of a credit limit application transaction took three working days which was considered to be too slow;
the products / services could not cater for all aspects of customers’ needs;
the products / services were too inflexible.

To improve the situation, the project must:

eliminate repeated manual entries of data into the system – thereby avoiding the error prompt and thus saving time and money;
provide online information to clients on their credit limits to date so that customers will get first-hand information instantly;
allow monthly sales declarations to be completed and submitted by customers through the Web.

(4) Insurance Market Competitiveness Strategy

The result of the SMP Checklist Manual Assessment revealed that 50% of the Insurance Market Competitiveness Strategy had been met. Problems identified concerning the insurance market competitiveness were:

the availability of alternative products such as letters of credit offered by banks;
the increasing availability of similar services as provided by other credit insurance brokers, agents and underwriters.

To improve the situation, the project must:

improve the accuracy and speed of transactions to enable the handling of a larger volume of business and delivery of faster services than those of competitors do.

(5) Customer Services Strategy

The results of the SMP Checklist Manual Assessment revealed that 67.5% of the Customer Services Strategy had been met. Problems identified concerning customer services were:

a lack of multilingual staff to communicate with European customers in French, Dutch, German, Italian or Scandinavian;
the customers were not happy with the lack of availability of information regarding risk management, buyers’ track records, country limits etc.

To improve the situation, the project must:

provide better services to retain existing customers and to attract new customers;
enable CAD’s customers to be self-sufficient in the support and maintenance of the Web Site and its links with CAD’s business applications;
provide a multilingual Web Site in French, Dutch, German, Italian and Scandinavian languages.

(6) Human Resources Strategy

The result of the SMP Checklist Manual Assessment revealed that 68% of the Human Resources Strategy had been met. Even though this was regarded as a satisfactory achievement, there was still evidently room for improvement, especially in the subordinate staff’s situation in some key areas such as:

difficulties in the recruitment and replacements of staff;
a lack of staff training and development;
a lack of ‘team spirit’;
staff resistance to change and unwillingness to accept new ideas;
an unhealthy distance between management team and subordinate staff;
the management staff seemed too busy to communicate with subordinate staff;
a lack of financial or other means of incentives to encourage good performance;
a lack of communication amongst staff members even at the same level;
conflict amongst subordinate staff members;
no recognition of subordinate staff’s achievements;
subordinate staff morale was low.

To improve the situation, the project must:

minimise data entry within CAD – at present, all credit limit applications (CLAs) (about 1000/month) have to be entered manually by the clerical staff into CAD’s credit management system on two separate occasions if the CLA requires an application to be made to the Insurance Underwriters (about 600 CLAs per month). The time saved will allow CAD staff to expedite the more complex CLAs, thereby further enhancing their knowledge and experience, whilst facilitating further sales growth;

minimise monotonous and tedious work through the adoption of efficient, user-friendly software. Indeed this will further stimulate the staff’s desire to broaden their knowledge and expertise;
provide new skills to staff through the use of new technology.

(7) Information Systems Effectiveness Strategy

The result of the SMP Checklist Manual Assessment revealed that 50.8% of the Information Systems Effectiveness Strategy had been met. Problems identified concerning information systems effectiveness were:

computer systems were too slow and frequently broke down;
system interfaces were not user-friendly;
the information system was not up to standard – not only software but also hardware peripherals such as printers, terminals, desktop and networking systems;
the financial package was disappointing, it was not up to the users’ requirements.

To improve the situation, the project must:

provide leading-edge technology to improve the effectiveness of the computer-based information systems in terms of development time, system administration and maintenance;
provide a reliable and consistent system to avoid system downtime.

5.6.1.5 Purpose and Scope

As can be seen from Section 5.6.1.4, the lowest score in the SMP Checklist Manual Assessment was the ‘Product Differentiation Strategy’ where only 25% of the objectives had been met at the time of the assessment. Therefore, the priority was to concentrate on how to improve Product Differentiation. The management agreed in the identification of the right kinds of technological approaches which could help them improve business performance through products / services differentiation.

The purpose of the project was to automate and streamline business processes, with a view to speeding up the response time to customers. The new services offered were envisaged as round-the-clock, global and multilingual. This would differentiate CAD from its competitors who only provide nine-to-five services, local time, from Monday to Friday. Furthermore most of the competitors use only English or the official language of their own country to communicate with customers.

CAD recognised that since the emergence of ‘Electronic Commerce’ (e-commerce) over the Internet/Intranet, there had been an exponential growth in e-commerce business. They were aware further that investment in such technology would

speed up processing time substantially by allowing customers to have instant online access to the information held at CAD via the World-Wide-Web (WWW). The Internet/Intranet technology would also enable the direct transfer of data, thus eliminating paper/fax forms, and thereby minimising manual data entry at CAD and speeding up the service.

From a business point of view, such an improvement in the speed of business transactions would assist global business development and expansion. The Web Site would provide 24 hours global access and make available immediate online responses to customers. The Web Site would be interactive allowing CAD’s customers to submit online credit limit applications (CLA) with the benefit of receiving an immediate decision. The Web Site would also allow customers to check the status of a CLA, and give access to credit reports. It was also planned as far as possible to eliminate all paper forms by facilitating direct input via the Web Site of information such as monthly sales declarations made by CAD’s customers. All these factors had made a strong case for using the e-commerce to differentiate services and to minimise running costs.

In addition, the Web Site would provide a language selection option to enable customers to choose between English, French, Dutch, German, Italian or the Scandinavian languages. This e-commerce project was managed using the DBOA approach in a way that was in keeping with the business objectives and expectations. The system was required to:-

automatically generate static Web-pages containing information on company’s profiles, CLA submission forms, CLA decisions and Frequent Asked Questions (FAQ) with answers to standard customer enquiries;
dynamically generate personalised and customised Web-pages providing answers to specific, non-standard customer enquiries;
provide multi-lingual support;
record and track Web access, automatically build a CLA database to store and display CLA application progress and decision reports.

Preliminary tasks of the project were:

the selection of Web Site development tools and Internet/Intranet access solutions;
the selection of integration tools to link CAD’s Web Site and CAD’s database to the UNIX mainframe;

the selection of integration tools to link the window based business applications such as Lotus Notes, cc:Mail, Microsoft Office, Lotus Smartsuites with the UNIX mainframe-based legacy database systems;
the selection of an Electronic Data Interchange (EDI) tool that can be integrated with the UNIX database or Lotus Notes;
the selection of translation software for multi-lingual Web pages.

Figure 5-3 shows the structure of the conceptual model for CAD’s e-commerce project. DBOA approach was used to develop a BO for the ‘Online Credit Limited Application Via the Internet/Intranet (OCLAVI)’ Project and to monitor the project development. DBOA was used to develop the business structure and the logic behind the software application. In this context, BO acted as the backbone with links connecting the data access module to Hypertext Modelling Language (HTML) Web-pages.

5.6.1.6 Project Requirements

The main objective of the project was to develop an interactive Web Site to offer CAD’s customers Online CLA via the Internet/Intranet. The main priority of the application was to allow online CLA submission and to obtain immediate decisions. It was also planned to introduce other Web workflow applications to replace the paper / fax forms currently used by customers, to provide online reports, and to offer multilingual interfaces. The project outlined clear-cut requirements in both the business and technological contexts of the general need to provide an electronic CLA transaction service to customers in a speedy, secure and reliable manner.

5.6.1.7 Project Tools Selection

An ‘Invitation To Tender’ (ITT) was sent to selected Web tool vendors seeking solutions to CAD’s IT requirements, as elicited through this project. The ITT document included details of the business objectives, requirements, budget and time frame. The Requirement Checklist designed to assist in determining the selection of the vendor for the tools and services appropriate to the project is listed in Appendix I.

As a result, a total of four vendors submitted their tenders to bid for this project. Ardent Software Inc.’s ‘Redback’ Web Enabling Tool was selected due to the fact that it met the highest numbers of selection criteria and the price quoted for the software was within CAD’s project budget. In addition, this tool also supported OO programming language and OO analysis and design.

Figure 5-3 : Structure of CAD’s E-Commerce Project Conceptual Model

5.6.1.8 Project Estimation using Function Points

The estimation of development time for the ‘OCLAVI’ project was measured by Function Points. Function Points are part of the DSDM technique used to estimate the ‘amount of functionality’ required from an application, thus producing an estimate of the

project completion time. The basic idea involves counting screen inputs, outputs and other features of a description of functionality [IFPUG 1997].

The Function Points Table listed in Table 5-11 illustrates the essentials of this estimation technique. The estimation strategy proceeds by identifying each function as ‘easy’, ‘medium’ or ‘difficult’ in terms of expected development ‘complexity’. The function points were set after the JRP and JAD meeting (refer to Section 5.6.1.1) with the business users, at which the necessary requirements were obtained from them.

Three project team members from the IT department were responsible for analysis, designing, implementing and debugging the system. Four project team members from the business and operations departments served to provide business information and expertise, and to give comments on the structure and contents of Business Object and the Business Object Architecture. They also undertook the prototypes testing and user-acceptance testing.

Since Function Points are units used to measure elements of the project itself, should there be changes in user requirements during any of the project phases, the Function Points Table will need to be re-scheduled accordingly. It is important to note that within a tight time scale, it would be impossible to accommodate extra functionality without changes to the Function Point estimation. Therefore, there are significant implications for the cost and/or duration of the project if such changes are required.

Online Credit Limit Application via the Internet/intranet (OCLAVI) Project Function Points Table
Task	Functions	Priority	Level of Difficulty (1 = easy; 2 = medium; 3 = difficult)	Estimated developer-hours (easy = 6 hrs; medium = 12 hrs; difficult = 18 hrs)
1	Design User-friendly Web Interface to BTR Web standards	Must	2	12
2	Bi-lingual (English & Dutch) Versions	Must	3	18
3	Search Engine function for NCM’s buyer database	Must	3	18
4	Enable clients to submit CLA to CAD via the Web	Must	2	12
5	Facilitate CLA from CAD to NCM via SNA Link	Must	3	18
6	Facilitate online decision to be made to client	Must	3	18
7	Display client credit reports on the Web browser	Must	1	6
8	Enable clients to download / print details of live credit limits applications	Must	1	6
9	Enable clients to download / print details of all their credit limits	Must	1	6
10	Enable clients to amend their buyer reference number for a buyer and submit to CAD via the Web	Must	2	12
11	Facilitate clients to view their policy details	Must	1	6
12	Enable clients to amend their contact details & submit back to CAD via the Web	Must	2	12
13	Provision of credit reports in PC format for viewing and printing	Must	2	12
14	Access to site controlled by user ID & password based on CAD Customer No.	Must	2	12
15	Provide English & Dutch online help	Must	3	18
16	Provide automatic update CLA log system	Must	2	12
17	Allow CLA business rules to be configurable by CAD	Must	2	12
18	Provide facilities for capturing NCM’s decisions to update CLA log & buyer systems	Must	3	18
19	Online response to clients (e.g, error prompt, acknowledge receipt)	Must	3	18
20	Enable clients to save / print completed CLA forms	Must	2	12
21	Match CAD’s CLA forms to NCM’s credit limit form data requirements	Must	1	6
22	Ensure response time between client & CAD & NCM is acceptable	Must	3	18
23	Provide facilities to enable clients to print out CLA online decision	Must	2	12
24	CAD to enable Web Site to support at least 8 concurrent users	Must	2	12
25	Develop CAD Web Site to support both Microsoft Internet Explorer version 3.0 and Netscape Navigator 3.0 or any of their above versions	Must	1	6
26	Prototype \ Review Actions	Must	2	12
27	Web Site Dutch Interface Version	Should	3	18
28	Provide monthly sales declaration input Web form	Should	2	12
29	Provide links to other relevant Web Sites (e.g., D&B, BTR etc)	Should	1	6
30	French Version Interface	Like To	3	18
31	Swedish Version Interface	Like To	3	18
32	Italian Version Interface	Like To	3	18
33	Finnish Version Interface	Like To	3	18
34	Norwegian Version Interface	Like To	3	18
35	Danish Version Interface	Like To	3	18
36	Integrate monthly sales declaration submitted by clients via the Web with Masterpack automatically for invoicing clients for premium	Like To	3	18
37	Provide clients with facilities to view / print country credit profile	Like To	2	12
38	Provide FAQ listing on the Web	Like To	2	12
39	Provide script form for client to submit their comments / questions	Like To	2	12

	Total :		87 points	522 hours

Table 5-11: Function Points

The Function Points table (Table 5-11) has shown that the total points scored for this project were 87. If each point requires 6 developer hours, the total developer hours would be 522. The project team did not have any formal measurement tools to estimate exactly the period of time that was expected to be spent on each function point. They had neither any metric tools nor standards to evaluate the balance and accuracy of function points versus business requirements. Rather, the project team based this on their previous project development experience, and used only a simple estimation strategy, identifying each function as:

‘easy’ (1 point);
‘medium’ (2 points); and
‘difficult’ (3 points)

in regards to expected development difficulty.

Based on the number of developer hours required, this project spanned a six-month period with each IT department staff members working around 12 hours per week on the technical part. The time spent on testing the prototype with the business users was not calculated. Likewise, the number of hours spent by the business users in providing business information and testing the prototypes were not calculated as function points. The time spent on staff training was not calculated as function points either.

The importance of tasks was determined by the three different priorities namely:

‘Must’;
‘Should’; and
‘Like To’

The top priority is the ‘Must’ tasks and they must be dealt with first. After all the ‘Must’ tasks have been done, the ‘Should’ tasks will follow. The rest of the time will be spent on doing the ‘Like To’ tasks. The Purpose of this is to ensure that if there are still tasks outstanding when the deadline is reached, they will only be the lowest priority tasks which result in minimum disruption to the overall progression of the project.

5.6.2 Time-box 2 : Business Study

The duration of Time-box 2 was 4 weeks. During the business study phase, detailed business functions and business rules were captured. A Business Object (BO) called ‘Online Credit Limit Application via the Internet/Intranet’ (OCLAVI) was developed. This BO contained the four levels of Business Strategies, Business Processes, OO Models and Database Management Systems.

5.6.2.1 ISO9000 Procedure for ‘OCLAVI’ project

The ISO9000 Standard Operating Procedure for the ‘OCLAVI’ project was then created. Within the procedure, business processes were defined for this project development. All of the processes and necessary tasks were based on the Business Mission Statement and Project Requirements Document, drafted as a result of the SMP Checklist Manual Assessment exercise. This procedure is re-produced in Table 5-12. The graphical representation of the procedure using Flowchart, is illustrated at the end of the procedure manual.

CAD-QP		ONLINE CREDIT LIMIT APPLICATION VIA THE INTERNET/INTRANET (OCLAVI) PROCEDURE				Q2111
1. PURPOSE The purpose of this procedure is to describe how to use the ‘Online Credit Limit Application (CLA) via the internet/intranet (OCLAVI)’. This procedure targets 2 kinds of users: (1) CAD’s customers and; (2) CAD’s staff. Section 4 will explain in detail. This procedure is an extension of the main procedure of Q2100 – How to process Credit Limit Application which describes the conventional way of processing CLAs. Under CAD’s circumstances elicited through the SMP Checklist Manual Assessment, the current situation of our business performance is as follows:- *Low Cost Strategy* Total no. of factors : ___________15_____ Total no. of objectives met: _____7.5_____ Percentage of objectives met: ____50%___ *Product Differentiation Strategy* Total no. of factors : ___________14_____ Total no. of objectives met: ______3.5____ Percentage of objectives met: _____25%__ *Product Efficiency Strategy* Total no. of factors : ___________25_____ Total no. of objectives met: ______11.5___ Percentage of objectives met: ____46%___ *Insurance Market Competitiveness Strategy* Total no. of factors : ____________15____ Total no. of objectives met: _______7.5___ Percentage of objectives met: _____50%__ *Customer Services Strategy* Total no. of factors : ____________20____ Total no. of objectives met: ______13.5___ Percentage of objectives met: _____67.5%_ *Human Resources Strategy* Total no. of factors : ____________25____ Total no. of objectives met: ______17____ Percentage of objectives met: _____68%__ *Information Systems Effectiveness Strategy* Total no. of factors : _____________60___ Total no. of objectives met: ______30.5___ Percentage of objectives met: ____50.8%__ 2. SCOPE Applicable to CAD’s Operating Procedures. This procedure covers credit limit applications using the e-commerce technology via CAD’s Web Site. 3. RESPONSIBILITY (1) Business Manager To ensure this procedure is complied with and kept up-to-date with any changes in line with Procedure Q2100. (2) Operations Team To be responsible for using the internet/intranet system properly to process the CLA, liaise with the Insurance Underwriters (e.g., NCM) and customers. (3) I.T. Dept Staff To be responsible for maintaining the internet/intranet system to ensure smooth communications between the customer and CAD and NCM. To provide the internet/intranet training to staff members and customers in using the related internet/intranet facilities. (4) Customer To be responsible for following the instructions as set out in this procedure to use the services provided by CAD’s Web Site on the internet/intranet. 4. PROCEDURE [DETAIL OF POLICY] Part A : For CAD’s customer (1) Log on to the internet and go to CAD’s Web Site (http://www.btrplc.com/CAD/cla/index.html) using a standard internet browser such as Netscape Navigator or Microsoft Internet Explorer. (2) Enter the customer’s user ID and password. (3) Choose a language (English / Dutch / French / German) (4) Click on an option or link as required:- – Option 1 : Submit CLA – Option 2 : Download CLA decision – Option 3 : View Buyer’s country limit – Option 4 : Update the customer’s company’s information Option 1 : Submit CLA (i) Enter buyer’s no if known otherwise click the search buyer icon and type out the buyer’s name in the box provided. (ii) If the buyer is found, the screen will display the buyer’s details such as name, address, buyer reference no., and current credit limit. (iii) If the buyer is not found, the customer will need to create a new buyer by providing the details of the buyer. Click OK when finished and the new buyer no. will be displayed on the screen. (iv) In the case of an existing buyer, a credit limit is already allocated. If the allocated limit is more than the requested limit, the customer will be likely to get an online decision. (v) However if the requested limit is more than the current allocated limit, the customer’s application will be held pending further processing. CAD staff will either make an internal decision or forward the application to NCM Insurance Underwriter to apply for an increase of the credit limit. The customer will be notified of the result at a later stage. The decision will be stored in the customer’s user account and the customer can download it from CAD’s Web Site. (vi) In the case of a new buyer, credit checking is necessary and a company search report needs to be obtained. If the company search report is satisfactory, the buyer will be referred to NCM Insurance Underwriter to apply for an allocated credit limit. The customer will be notified of the result at a later stage. The decision will be stored in the customer’s user account and the customer can download it from the CAD’s Web Site. (vii) Both the online decision and deferred decision records will be stored in CAD’s system. However it is strongly recommended that the customer should print out a hard copy of all decisions for the customer’s own file record. (viii) Once submitted the CLA will be processed and recorded in CAD’s system and one of the following responses will be given:- 1. CLA approval with conditions; 2. CLA deferral Option 2 : Download CLA decision (i) Click the decision icon to download decisions on any of the customer’s previous applications. As mentioned above, all the decision messages are permanently stored in CAD’s Web Site. For decisions already downloaded, the message headings are red in colour, for the new decision messages, the headings are in blue. Option 3 : View Buyer’s country limit (i) Click the view buyer’s country limit icon and enter the buyer’s country limit. (ii) If the customer want to search for more than 1 buyer, just repeat the step (i). Option 4 : Update the customer’s company’s information (i) If the customer’s company has changed its postal address, telephone no., fax no., email address etc., please click the update the customer’s company’s information icon and enter the customer’s new information, click the submit icon when finished. Part B : For CAD’s Staff (1) CLAs entered via the Web will be recorded in the CLA log system buyer systems. If an online decision has been made it is recorded further as such and no action is required by CAD staff . Where a CLA has been deferred the CLA will need to be processed as a manually entered CLA. Please refer to procedure Q2100 – How to process CLA for details. (2) Download all the incoming messages such as CLA applications, new buyers, updated customer information. (3) For new buyer, create a new buyer file and perform a company search. (4) When a final decision is made, a decision message should be uploaded to the customer’s user account in CAD’s Web Site. 5. RECORDS As a result of the ‘OCLAVI’ processing, the following records are:- – CLA log record in CAD’s credit management system; – CLA online decision record in CAD’s Web server; – Updated customer information record (if applicable); – Updated buyer’s credit limit; 6. DOCUMENTATION AND REFERENCES SMP Checklists Business Mission Statement Project Requirement Function Points Table Redback Web Development Tool User Manual NCM’s buyer database through SNA link NCM policies Buyer’s files Customer’s files NOTES
Issuing Department:	Approved by :		Date:	Revision:	Page:
I.T.	Peter Maybury		1/4/98	1.0

Table 5-12 : ISO9000 Procedure for ‘OCLAVI’ project

Figures 5-4 and 5-5 are the two Flowcharts for the ‘OCLAVI’ project business processes.

Figure 5-4 : Flowchart for ‘OCLAVI’ project (Part A ; For CAD’s customer)

Figure 5-5 : Flowchart for ‘OCLAVI’ project (Part B : For CAD’s staff)

5.6.2.2 OO Modelling for ‘OCLAVI’ project

Object-Oriented Analysis and Design (OOAD) modelling techniques using UML Notation was used to model the business processes. As mentioned in Section 2.3.2, those OOAD methodologies including UML have up to now, only been used to model software applications which may not include any business strategic issues. As a matter of fact, the novelty of the DBOA’s way of using UML is that business processes to be modelled already embrace the essence of business strategies, so that the business strategies can now be modelled in software application. As discussed in Section 2.3.3, there were some good techniques amongst the three earlier methodologies incorporated into UML which have been excluded from the notation after the methods were unified. Those techniques are: (1) Object-Oriented Software Engineering (OOSE)’s Complete Use Case Diagram, Use Case and Test Case Diagram, Use Case Object and Business Object Diagram; and (2) Object-Oriented Modelling Techniques (OMT)’s Event Diagram.

Fowler [1996] recommends that developers should not stick to one single methodology. They should use their judgement to select appropriate techniques from different methodologies and apply them as required. As OOSE’s Business Use Case and Business Object Diagrams are considered to be useful for this purpose, they have been included in this project. A set of UML Notation plus the OOSE’s BO Diagrams are listed as follows:

(i) Use Case Diagram for Credit Limit Application

(i)(a) Use Cases and Actors

The object modelling stage starts with the Use Case Diagram. A Use Case Diagram as shown in Figure 4-6 is a high-level modelling diagram. Its purpose is to distinguish the system objects (that is the tasks to be carried out in a system, called Use Cases) and the human objects (that is the persons who carry out these tasks, called Actors). The Use Cases and Actors model is used to define the relationships between the business processes, and how people handle these processes. Each Use Case represents a task inside the business processes.

Another purpose of the Use Case Diagram is also to illustrate the different roles played by the same Actor in different systems. For instance, an Account Executive processes the credit limit application (CLA) when s/he is working on the CLA. But the same Account Executive will take on the role of a debt collector when s/he is dealing with debt collection.

In the Use Case Diagram in the ‘OCLAVI’ project as illustrated Figure 5-6, there are four Actors namely: (1) Customer; (2) Account Executive; (3) Business Manager; and (4) Insurance Underwriter. The Customer plays the roles of submitting the CLA and of receiving a CLA decision. The Account Executive plays the roles of receiving, processing and making decisions on the CLA. The Business Manager plays the roles of approving or rejecting the CLA if the application is beyond the discretionary limit of the Account Executive. The Insurance Underwriter plays the role of approving or rejecting the CLA if the application is beyond the discretionary limit of the Business Manager.

The ‘Check Risk Factor’ is decomposed into three extended Use Cases namely: ‘Check Country Risk Profile’, ‘Do Company Search’ and ‘Forward to Insurance Underwriter’. The difference between a main Use Case and an extended Use Case is that a main Use Case gives an overview of the task, whilst an extended Use Case describes in more detail any sub-tasks involved in the main Use Case in question.

From the experience of using the Use Case Diagrams, it has been found that the Use Case Diagram can intuitively capture a high-level business abstraction. Such high-level concepts do not generally elaborate in detail a software development, but the Use Case Diagram can potentially be carried over to object modelling since it treats the Actors and Use Cases as objects. It also gives a clear and simple picture to assist the developer in capturing the overall tasks in a system and in clustering different tasks as the responsibilities of different Actors.

Figure 5-6 : Use Cases and Actors Diagram for ‘OCLAVI’ project

(i)(b) Use Cases and Objects

Figure 5-7 is the Use Cases and Objects diagram, in which objects are derived from Use Cases. At this stage, the objects to be identified are based on the business processes. Three types of objects have been converted namely the:

Interface Object (which is the communication boundary between the end-user and the system);
Control Object (which manipulates the functionalities and performance of the system, and is situated between the Interface Objects and Entity Objects); and

Entity Object (which is responsible for data storage). Each type of object carries out different duties.

In other words, a group of objects comprising one Interface Object, one Control Object and one Entity Object has been created for each Use Case at the left hand side of Figure 5-7, so that the objective to convert the business processes (represented by Use Cases) to objects could be achieved.

Figure 5-7 : Use Cases and Objects Diagram for ‘OCLAVI’ project

(a)(iii) Complete Use Cases Model

Figure 5-8 is a Complete Use Case Model for the ‘OCLAVI’ project. This diagram is in fact, a rationalisation of Figure 5-7 to remove the duplicated CLA Entity Object, and just name each distinct one. It also shows the communication between the:-

Business End-users and the Interface Objects;
Interface Objects and the Control Objects;
Control Objects and the CLA Entity Object;
CLA Entity Object and the CAD System Object;

(5) CAD System Object and the CAD IT department staff.

This is a classic example of how a Use Case can be used to created a Business Object unit to bridge the communication gap between business end-users and system developers. The diagram clearly illustrates how these business end-users send commands to the system, and how the system obtains the commands and transforms them into messages to signal the developers. The developers then react with such actions as are necessary for the business requirements.

Figure 5-8 : Complete Use Case Model for ‘OCLAVI’ project

(a)(iv) Business Use Cases and Business Objects

As shown in Figure 5-9, the ‘OCLAVI’ project comprises an Interface Object, a Control Object and a number of Entity Objects which are derived from the Use Case. The ‘OCLAVI’ project is thus like a Business Object encapsulating Use Case Objects. This makes clear the difference in levels of abstraction between the ‘OCLAVI’ Business Object and the encapsulated objects. The BO at the OO modelling level is like a collection of software objects. A BO at the business level deals with business transactions. The individual encapsulated objects contribute to software modelling, assisting, for instance, in the definition of attributes, operations and behaviours.

Figure 5-9 : Business Objects for ‘OCLAVI’ project

(ii) Activity Diagram

The second step is to use the Activity Diagram, as depicted in Figure 5-10, to describe the actions taken at different stages of the processing. The first activity starts with verifying the customer’s username and password. If the username and password are obtained, the system will verify. If the username and password are not provided, the system will request the user to fill out an application form for a new customer account online. Then the system will create a new customer username and password for the new customer. The second activity is to ask customer to select language from the four languages (English, Dutch, French and German). The third activity is to give the customer four options to proceed. ‘Option #1’ is the CLA submission. ‘Option #2’ is downloading the CLA decision for the CLA(s) previously submitted where an immediate decision could not be made. ‘Option #3’ is viewing the buyer’s country limit. ‘Option #4’ is updating the customer’s company information.

If the user chooses ‘Option #1’ – to submit a CLA, the system will request a buyer’s name. If the buyer’s name is provided, the system will search the database to retrieve the buyer. If the buyer is found, the buyer’s name and number will be displayed on the screen. If the buyer’s name cannot be found or is not provided, the system will request the user to fill out a form for a new buyer account online. A new buyer name and number will then be created. The next step is to request the credit limit and period covered. Once the figures are provided, the system will search the database to check whether the limit requested has exceeded the allocated limit or not. If the requested limit is within the allocated limit, the system will proceed to the online decision stage where the CLA will be approved online. If the requested limit is beyond the allocated limit, online decision cannot be made. The system will defer the application pending further processing. The system will forward the application to the Insurance Underwriter for an increase in the limit allocated. In the case of new buyers, the system will also defer the application pending a company search and subsequent referral to the Insurance Underwriter for an allocated limit. If the user chooses ‘Option #2’ – to download the CLA decision for the CLA(s) previously submitted, the decision is made, based on the risk factors of the buyer. The risk factors refer to the trading record and country risk. Therefore the system will request a company search report on the buyer. If the company search report is favourable, the report will be forwarded to the Insurance Underwriter to apply for an allocated limit. After the Insurance Underwriters has allocated a credit limit to the buyer, the system still has to check whether the limit requested is within the allocated limit or not. If so, the CLA will be approved. If not, the CLA will be rejected. If the company search report is unfavourable, the report will not be forwarded to the Insurance Underwriter. The CLA will be rejected. Since the above procedure cannot be done immediately, all the CLAs under this category will have to be deferred. All the subsequent decisions will be uploaded to CAD’s Web site for customers to download the next time they logon. If the user chooses ‘Option #3’ – to view the buyer’s country limit, the system will request the buyer’s country name. When the buyer’s country name is obtained, the system will display the buyer’s country limit on the screen. If the user chooses ‘Option #4’ to update the customer’s company information, the system will display the customer company’s current information. The user can overtype the text box with the new information. The system will ask the user to confirm the correctness of the new inputs. If the new information is confirmed, the system will display the new information on the screen while at the same time updating the customer’s information in the database.

Figure 5-10 : Activity Diagram for ‘OCLAVI’ Business Object

(iii) State Diagram

The State Diagram as shown in Figure 5-11 is like a state machine. Objects have both behaviour and state. Some objects do, and know, more things, or at least they are more complicated things than others. Some objects are incredibly complex and the State Diagram illustrates clearly how they work.

Figure 5-11 shows the ‘OCLAVI’ Business Object which is treated as an object with a variety of attributes, functions and behaviours. The rectangles represent the states that are stages in the behaviour of this object. States are represented by attribute values of the CLA object. The arrows represent transitions which are progressions from one state to another and are represented by the invocation of a method on the object class. Transitions are often a reflection of business rules. Therefore, there are messages attached to the transition lines describing the situation. The transition arcs will then point in the appropriate destination states according to the rules as set. There are also two kinds of pseudo-states: (1) an initial state, in which an object is first created and (2) a final state, that an object does not leave once it has entered a state.

Figure 5-11 : State Diagram for ‘OCLAVI’ Business Object

(v) Class Hierarchy

The development of the Use Case Diagram, Activity Diagram and State Diagram all describe the business processes. It is important firstly, to determine how the business is processed, what is the direction of workflow and in what order the sequence of transactions occurs as the process moves from one stage to another.

At the business process modelling stage, developers would ask: “Now that I have identified all the business processes involved in this application, what objects do I need to carry out these tasks?” As illustrated in Figure 5-12, Objects and Classes emerge from the business processes modelling diagrams. Classes like Employee, Buyer, Customer and Insurance Underwriter were identified. The relationship amongst different classes is indicated by a link with description of their relationship. For example, the relationship between Business Manager and Insurance Underwriter is that Business Manager negotiates premium rate with the Insurance Underwriter.

Attention is drawn to the Employee Class in particular as both inheritance and aggregation were used to deal with many different possible combinations amongst those Sub-classes. In the Employee Class, inheritance was used to factor out Managerial and Subordinate Employee Classes (viz. the triangular arrow notation in Figure 5-12). Separately, the types of employment term were represented using multiple inheritance. Aggregation was also used to link these Sub-classes of the Employee Class to different categories of the Employment Term Class (viz. the diamond shape notation in Figure 5-12). As a result, there were four different types of employees namely:

Full-time permanent employee;
Full-time temporary employee;
Part-time permanent employee;

(4) Part-time temporary employee.

There were also two sets of rules namely:

Rule 1:Managerial staff can only be Full-time permanent employee, that is type (1); and

Rule 2:Subordinate staff can be any one of these four types.

The Employee Class was therefore derived into two Sub-classes namely Managerial Employee Class and Subordinate Employee Class. This set of Classes was aggregated with the Contract Term Class. This Contract Term Class was derived into two Sub-classes namely Hour Class (which distinguishes between Full-time Employee Class and the Part-time Employee Class); and Duration Class (which distinguishes between the Permanent Employee Class and the Temporary Employee Class).

The main reason for distinguishing Managerial from Subordinate Employee Classes is that not only because of their contract term, but also because of the different attributes, behaviours and functions they have in the CLA business activity but also in other business activities.

Another example is the Customer Class. There are four different types of customers namely:

BTR unit Domestic customer;
BTR unit Overseas customer;
Non-BTR unit Domestic customer; and
Non-BTR unit Overseas customer.

A Customer Class was established first and was specified into two different Sub-classes namely BTR unit and Non-BTR unit. A Region class was established and was included by aggregation in the Customer Class. This Region class was also specified into two Sub-classes called Domestic customer and Overseas customer.

Relationship lines were used to link classes and objects with a description of the relationship between them.

Figure 5-12 : Class Hierarchy Diagram for ‘OCLAVI’ project

(v) Sequence Diagram

Sequence Diagram demonstrates clearly the logic required to fulfil the Use Case scenario. It also shows messages sent by one object to another and the length of time taken to run the invoked method. With Sequence Diagrams, developers can maintain traceability of the methods in the Class Diagrams. As well as giving the return value, the Sequence Diagram also holds its own internal logic of the scenario.

Figure 5-13 shows the Sequence Diagram for ‘OCLAVI’ Business Object where an Account Executive Object first checks the customer’s status from the Status Checker Object. Objects in UML are shown underlined to distinguish them from Classes. Objects and Classes are drawn as a rectangular box. The dashed line describing from each box represents the object’s timeline – that is, the duration of an object’s particular activity. Where a broader line is placed over this, this represents the activation of one of the object’s methods. The visual intent is to illustrate the flow of control and distribution of responsibilities.

The Account Executive Object sends a message to the Status Checker Object to check the customer status. If the Status Checker Object cannot find the customer, it will pass the message to request the New Account Creator Object to create a new customer account. The New Account Creator Object will then send a message to the Existing Customer Object with a return value of a customer account that has been created. This also applies to Buyer Object. Then the Account Executive Object sends a message to the Country Risk Checker Object to check country risk of the Buyer. The return value from the Country Risk Checker Object is either low-to-medium risk or high risk. If it is high risk, the CLA will be rejected at this point. If it is low-to-medium risk, company search will be invoked.

The Company Searcher Object is created to receive messages from the Account Executive Object to conduct a company search. The company search outcome will then be sent back to the Account Executive Object as return values. If the company search report is not satisfactory, the CLA will be rejected at this point. If the company search report is satisfactory, a request for an allocated limit from the Insurance Underwriter Object will be invoked. An asynchronous arrow is used in the Sequence Diagram from the Account Executive Object to the Insurance Underwriter Object. An asynchronous arrow here means that the system must start up a concurrent process for the Insurance Underwriter Object.

The flow of processing in the Account Executive Object is not interrupted but continues directly. It must later synchronise with the result returned from the Insurance Underwriter Object. The Asynchrony here depends how long it takes for the Insurance Underwriter Object to return a value either agreeing or refusing to increase the allocated limit. If the allocated limit is less than the limit requested and the Insurance Underwriter Object has rejected the request to increase the allocated limit, the CLA will be rejected. If the allocated limit is less than the limit requested but the Insurance Underwriter Object has approved the increase of the credit limit for the buyer, the CLA will be approved.

(vi) Collaboration Diagram

Unlike some other notation that shows both state and behaviour in Class Diagrams, UML shows behaviours separately in Collaboration Diagrams. The basic difference between the two approaches is that UML Class Diagrams do not include messages, because messages tend to clutter the Class Diagrams and make them difficult to read. Since UML Class Diagrams do not show this message flow between classes, a separate diagram, the Collaboration Diagram, is created. Collaboration Diagrams show the message flow between objects in an object-oriented application and define the basic associations between objects.

Figure 5-14 presents the Collaboration Diagram for the ‘OCLAVI’ Business Object. The rectangles represent the various objects and the roles they take within the application, and the lines between the classes represent the relationships or associations between them. Messages are shown as a label followed by an arrow indicating the flow of the message, and return values are shown as labels with arrow-circles beside them.

Collaboration Diagrams are usually drawn in parallel with Class Diagrams, especially when Sequence Diagrams have not been developed for the application. Collaboration Diagrams can be used to get the big picture of the system, incorporating the message flow of many Use Case scenarios.

Although the order of message flow can be indicated on a Collaboration Diagram by numbering the messages, this typically is not done because Sequence Diagrams are much better at showing message ordering.

Figure 5-13 : Sequence Diagram for ‘OCLAVI’ Business Object

Margin Text for the ‘OCLAVI’ project Sequence Diagram:

Download the Credit Limit Application (CLA) form submitted by the customer via the Internet/Intranet.
If it is an existing customer, retrieve this customer’s no. and details from the customer’s screen. Retrieve this customer’s file from the filing cabinet as well.
If it is a new customer, generate a new customer no. from the customer’s screen and create a new customer file.
If it is an existing buyer, retrieve this buyer’s no. and details from the buyer’s screen. Retrieve this buyer’s file from the filing cabinet as well.
If it is a new buyer, generate a new buyer’s no. from screen and create a new buyer’s file.
Check country risk for buyer are, if country risk is high, reject the CLA. If the country risk is low / medium, continue to process.
Do a company search for a new buyer or any existing buyer whose company search report is more than 12 months old.
Obtain company search reports from company search service companies e.g., Graydon, Dun & Bradstreet and Infocheck.
If search report, together with the overall exposure, does not speak in favour of the limit requested, reject CLA.
If the search report, together with the overall exposure, speaks in favour of the limit requested, apply for allocated limit from the Insurance Underwriter.
If the allocated limit is more than the limit requested, approve the CLA.
If the allocated limit is less than the limit requested, forward to the Insurance Underwriter for decision.
If the Insurance Underwriter’s decision is positive, approve the CLA, if negative, reject the CLA.

Figure 5-14 : Collaboration Diagram for ‘OCLAVI’ Business Object

5.6.3 Time-box 3 : Functional Prototype

The duration of Time-box 3 was seven weeks. The objective of the Functional Prototype was to produce a version of the working system from analysis and design notation to implementation.

During this phase, the OO models drawn up using UML notation were mapped into the Redback Web Enabling Tools. The emphasis at this stage was on the development of data fields and the associated screen handling. This was no more than a ‘rough’ prototype, but it was able to demonstrate the essential features of the interface and some of the functionality of the new system. Interfaces were created with the feature sufficient to enable a CLA transaction to progress to the users, through a standard Internet browser (Netscape Navigator or Microsoft Internet Explorer).

An IT internal review meeting was held for testing prior to the prototyping session with the business users. A range of modifications and improvements were made, with suitable care to ensure that the UML models were kept consistent with the Redback Web Enabling Tool implementation.

The final activity to take place in this time-box was a JAD session to review the prototype with the business users. Some examples of the prototyping user interfaces are given in Appendix J. The following sub-section describes the results of this session.

5.6.3.1 Outcome from the Functional Prototype Session

It was necessary to involve users drawn from both the management and clerical staff. Business Managers could validate the business logic and business rules behind the system and Account Executives could contribute their opinions on the user-friendliness and overall performance of the application.

The prototype was in fact a working model designed to pave the way for future project development and improvement to the application. Even at such an early stage, decisions were required from the users to determine whether the prototype was fulfilled the criteria necessary to meet the business requirements, in particular, helping the company to improve their business performance.

The objective of this JAD session was to give the business users some ideas of the look of the interfaces. At this stage, only the essential hyperlinks between the client application and the internal server were set up.

The external link between CAD’s Web server and the Insurance Underwriter’s server was not yet connected, neither was the Internet Gateway. The aim was merely to show to the users the layout of the interfaces, to check whether there were any data fields

missing and to demonstrate the linkage between the in-house Web server and the client desktop’s Internet browser. This session produced substantial new, and modified, requirements. A full set of transcripts of users’ requirements from this prototyping session is listed in Appendix K.

The new users’ requirements were recorded as tasks for the next Time-box. As the new requirements were within the time scale, it was not necessary to add further developer hours to the Function Points Table. However the IT department staff had to determine whether or not the change of requirements could be achieved within the Time-box. If it could, they would just update the Function Points Table accordingly without altering the time scale. If not, the project development team would negotiate an extension to the project’s delivery deadline.

5.6.4 Time-box 4 : Design Prototype

The duration of Time-box 4 was seven weeks. The main objective of this phase of the Design Prototype was to provide the bulk of the essential functionality of the application. The Functional Prototype had been largely concerned with the design of the user interface and with business functionality, and paid little attention to such non-functional requirements as integrating the newly-developed application and the existing database system.

Another important focus of the activities carried out in this phase was to update the ISO9000 procedure manual in response to the changes resulting from the prototyping session. The developers also had to update the OO models to ensure that the design models correctly reflected business processes, hence ensuring the delivery of a business application that could effectively support the business. Since a Business Object (BO) for the ‘OCLAVI’ project had been developed as a conceptual model to pave the way for software system analysis, design and implementation, the changes suggested by the business users were applied to the modification of the BO. Such a cycle proceeds iteratively so that the model can be checked and altered, as and when is required.

Essential to this phase was the designing and building of the system. Hence by the end of this phase the system, in principle, should contain absolutely all functionalites in a form suitable for testing in the final JAD session. There should be no components of functionality left ‘un-implemented’ if the schedule is to be met.

This time the external link to the Insurance Underwriter’s database was connected. The users could now browse its contents via the CAD Web Site. The schedule in Time-box 4 was quite similar to that in Time-box 3. Firstly the IT developers

modified the system in accordance with the users’ changes of requirements elicited from the previous JAD session. The new prototype was tested again after the modification. Then, an internal IT department review meeting was held to discuss progress and modifications. Much care was taken to keep adequate records and check on what could potentially have become a quite frantic rate of change. Version control was the real issue. There were three versions of the application in this project, namely the: (1) Prototyping version; (2) Pilot testing version; and (3) Production version.

Towards the end of Time-box 4, a JAD session was held to test the Design Prototype with the users. The users were invited to try to submit a mock Online CLA through the test bed linked between the Web browser, CAD’s Web server and the Insurance Underwriter’s database. All the databases had been copied from the live systems to the test systems so that if the CLAs were approved, the users would get online decision on their screens. Otherwise, the application would be forwarded to the deferred decision folder pending further processing. The users could also download the decision reports on deferred CLAs previously submitted.

This time, the JAD session revealed the requirements for a few minor changes, such as tidying up the position of the data fields, setting the margins of the documentation and changing the report format. The IT department staff were able to make these amendments during the JAD session. After the meeting, the IT department staff reviewed the prototype again and created a Pilot testing version. This time, not only the users within the project development team, but also CAD’s customers were invited to test the application. After the Pilot testing, the Pilot version was modified further before being converted to a release version for implementation in Time-box 5.

5.6.5 Time-box 5 : Implementation

The duration of Time-box 5 was five weeks. The activities in this Time-box were mainly designed to test the reliability of the system in collaboration with the users, and to perform any final debugging that was required. No extra requirements from the users were accepted within this Time-box. If the user had wanted to make any further changes, the project team would have had to reschedule the project development life cycle.

Other activities at this stage included obtaining the users’ approval for the release of the application, issuing user guidelines, organising user training programmes, setting up a Web production server, connecting to the Internet Gateway, configuring firewall security for the Intranet access, linking CAD’s Web server to BTR’s corporate Intranet

server, creating a rollout plan, notifying customers of the Web Site registration procedure, and setting up customer user names and passwords.

Finally, the test site was moved from the test bed to the production server. A data take-on procedure was performed and the system went live in October 1998. The first phase of this project was to make the system available to BTR’s subsidiaries through BTR’s Intranet server. It was planned to extend availability of the system to customers outside the BTR group as the second phase of the project.

5.7 Post-Project Review

The ‘OCLAVI’ project had been delivered on time, within budget and was operational. In order to measure the level of improvement in business performance as a result of this project, a preliminary Post-project review exercise was executed five weeks after the system had gone live. This Post-project review was held in November 1998. CAD’s seven management team members assembled together to conduct the Post-project SMP Checklist Manual Assessment exercise. Evidence, in the form of financial statements, sales volume figures, and staff records, was examined.

A comparison between the Pre-project and Post-project SMP Checklist Manual Assessments was executed. Notes were made concerning the level of improvement or decline in the business performance. The numbers of new factors meeting business objectives and failing to meet business objectives were both recorded. Problem areas were outlined and flagged for future investigations.

As part of the ‘continuous improvement’ practice, the Project Requirement Statement and the Function Points Table were updated in accordance with the conclusions from the Post-project SMP Checklist Manual Assessment exercise. After meeting with the business management, and having obtained the necessary recommendation from them, the IT department staff updated the ISO9000 Operating Procedure. The contents of the procedure were revised in response to the changes which had arisen. The components inside the BOA repository modules were modified in accordance with the new instructions as set out in the procedure. The software application was also modified based on the modified design work.

5.7.1 Results of the Post-Project SMP Checklist Manual Assessment

The Post-project SMP Checklist Manual Assessment exercise was carried out in order to evaluate the DBOA project against business performance and to see whether the

DBOA approach had successfully supported the organisational SMP. The results of the Post-project SMP Checklist Manual Assessment are listed in Appendix L.

The post-project SMP Checklist Manual Assessment has shown that there was a 13% improvement in overall business performance. The variations between the two assessments are listed in Table 5-13.

SMP Checklists	Assessment Date : March 1998 % of objectives met	Assessment Date : November 1998 % of objectives met	Margin
Low Cost Strategy	50%	60%	+10%
Product Differentiation Strategy	25%	50%	+25%
Product Efficiency Strategy	46%	60%	+14%
Insurance Market Competitiveness Strategy	50%	63.3%	+13.3%
Customer Services Strategy	67.5%	72.5%	+5%
Human Resources Strategy	68%	76%	+8%
Information Systems Effectiveness Strategy	50.8%	66.6%	+15.8%
Average Margin : +13%

Table 5-13 : Comparison between the Pre-project and Post-project SMP Checklist Manual Assessment

5.7.2 Refined Function Points

To satisfy the criterion of ‘continuous improvement’, any failures identified to meet the business objectives, as a result of the post-project SMP Checklist Manual Assessment exercise, would trigger the process improvement mechanisms documented within the ISO9000 procedure.

It was agreed by both management and IT department staff that modification work should be carried out. The second phase of the project was only an enhancement, but the Function Points Table still had to be refined (see Table 5-4) to record all the new functional requirements and to estimate the time and resources required. This was to be followed by an update of the ISO9000 procedure, OO models and the interfaces.

No	Functions	Priority	Level of Difficulty (1 = easy; 2 = medium; 3 = difficult)	Estimated developer-hours (easy = 6 hours; medium = 12 hours; difficult = 18 hours)
1	Organisational chart with employee profiles and photos	Must	2	12
2	Bank addresses and contact names	Must	1	6
3	NCM Schedule 1 – decide on standardised format	Must	2	12
4	View Credit Limits – allow client to view complete decision from data stored on Client Limit File	Must	3	18
5	Decide on which reports are needed:- 1. Client Limits 2. Client Limit Applications 3. Debt Collection 4. Claims	Must	3	18
6	Buyer search = VAT number / country codes	Must	2	12
7	One page summary / highlights by country or current events – to be added to the Dun & Bradstreet country profiles (at the front of the D&B profiles)	Must	2	12
8	CAD addresses:- UK = London + Sutton Coldfield US = Ellicott City + St. Louis + Charlotte	Must	1	6
9	User ID per client and contact name to be entered on each application	Must	3	18
10	Stop postcode and company reg. No. being sent to NCM	Must	3	18
11	Review payment terms	Must	1	6
12	Add delete button to uplift screen to remove unwanted limits	Must	2	12
13	Add validation after the decision has come back from NCM to refer to CAD if there are any conditions	Must	3	18
14	Check uplift if buyer no is incorrect	Must	1	6
15	Input explanatory notes -> help file (in all languages)	Should	3	18
16	Suite of software provided by CAD : Adobe Acrobat	Should	1	6
17	Number of hits on certain pages e.g., Country Profiles	Should	1	6
18	Credit limit uplift screen needs more information (terms and conditions)	Like to	2	12
19	Add fields created by and created date to log screen	Like to	1	6
20	Useful links : e.g., Export Trader, The Economist etc.	Like to	1	6
21	Frequent Asked Questions (FAQ)	Like to	2	12
	Total :		40 points	240 hours

Table 5-14 : Refined Function Points

In the future, the SMP Checklist Manual Assessment exercise should be carried out at a six monthly interval to review business performance. More importantly, as mentioned in Section 1.1, since the business situation and economic climate are always changing, organisations should be prepared to adapt to changes and be ready to respond promptly to them. DBOA is designed to seek to provide the techniques to do this.

5.8 Evaluation of the Case Study

The project team considered that DBOA had been an effective tool to assist them in running the project better. The IT department staff found that the DBOA had offered a way of addressing business problems first before bogged down in the details of technical issues. When the IT department staff developed the software application, they understood the reasons why it had to be done in a particular way to tackle business problems. Management and business users considered the ‘OCLAVI’ project using the DBOA approach a satisfactory one. They experienced fewer problems compared to previous projects not using DBOA. The ‘OCLAVI’ project’ was delivered on time, within budget and operated satisfactorily.

At this stage, the management realised that they would not be able to determine whether the company had gained any tangible business benefit immediately upon completion of this project. It was clear to them that the impact would rather be felt in the medium- to long-term. They thus agreed to conduct another SMP Checklist Manual Assessment exercise in six months time. The following sub-sections will present a detailed evaluation of the project to date.

5.8.1 From business strategies to implemented software

The project team felt that the ‘Open-ended’ questionnaire design had enabled IT department staff to capture the business scene more holistically. It had also encouraged those involved to express their feelings more sincerely and hence had enabled IT department staff to understand the business situation better. The SMP interview has provided an opportunity for business management and IT department staff to communicate better with each other.

The SMP Checklist, in a ‘Closed’ questionnaire format, had transformed the loose, unstructured and hard-to-measure information obtained from the interviews into tight, structured and easy to measure strategic factors. The SMP Checklist Manual Assessment exercises during the pre- and post-project phases had provided an opportunity for IT department staff to measure organisational business performance at different stages. Hence, software applications could be modified accordingly for ‘continuous improvement’. The measurement of business performance could also help the organisation to evaluate its investment in software development against business gains.

The ISO9000 operating procedure had integrated business strategies with business processes. Such an integration had enabled a correlation to be formed between business strategies and day-to-day business operations. From the results of the pre-project SMP Checklist Manual Assessment exercise, it was seen that CAD’s main concern was product differentiation strategy as the company had scored the lowest percentage of achievement (only 25%) in this area. To implement the product differentiation strategy, both management and IT personnel had decided to launch an e-commerce project called the ‘Online Credit Limit Application via the Internet/Intranet (OCLAVI)’. The objective of this project was to differentiate their Credit Limit Application (CLA) service from that of other competitors by making it available over the internet/intranet, thus overcoming all time zone and geographical restrictions.

The use of Object-oriented modelling techniques to model the business processes had provided a means of transforming business abstraction into software development. Software development would thus be more statistically based and business focused. In the case study, the Unified Modelling Language (UML) standard notation was used to model the ‘OCLAVI’ project. UML was considered to be capable of modelling the business processes of the ‘OCLAVI’ project.

The DSDM project management technique had brought business management and IT department staff closer together. The iterative and evolutionary prototyping approach

had enabled the frequent testing of the system to minimise the risk of failing to deliver the system on time and within budget.

The tripartite integration of: (1) business strategies, (2) software development and (3) project management, as a whole, had made IT department staff aware that when business strategies and software applications are linked together to form a single pool of knowledge and developed in an iterative project development life cycle, software applications produced are likely to be more effective in supporting the organisational SMP. Project team also considered DBOA easy to implement and the learning curve was not steep. On the whole, the outcome of the project has revealed that DBOA has demonstrated merits in reducing the communication gap between business management and IT department staff, by enabling the development of software applications embracing the knowledge acquired from the business.

Although DBOA is not a ‘salvation device’ to promise ailing organisations to immediately turn competitive and successful, both the business management and IT department staff appreciated that DBOA is an ideal tool for fostering communication between them and provides the techniques to enable IT department staff to acquire business knowledge, objectives and requirements. The management also welcomed the opportunities to review the project against business performance. This could help them justify their investment in IT against their business benefit.

The project has, in some ways, provided a good opportunity to apply DBOA in a practical context, but it does not assist in the simplification of complex business strategies, which are by nature complicated. The difficulties that arose when trying to make software applications directly simulate business strategic models (e.g., Porter’s Five Forces Model, Generic Strategies Model, Relationship Marketing Model, Value Chain Analysis Model) still exist. Business models are goal-driven whilst software models are application-driven. Software modelling techniques are concerned with mimicking the business scenario as closely as possible.

Since DBOA is implemented through project-based software applications as the means of supporting organisational SMP, the management personnel still have to review the impact of the project on their business performance and subsequently on their business objectives. This limitation is considered to be the main disadvantage hindering the DBOA approach to directly implement the business strategies.

5.8.2 Selection of project team members

According to the DSDM principles, they say: “… It is absolutely essential for such a project with heavy user involvement that the right people assemble at the right time, and are given the right facilities to enable them to make the required decisions…”. Unfortunately, this may only happen in an ideal world. In the real world, if the right people are not available, there is no other option but to select whoever is available (if not necessarily right) for the job in hand.

In the ‘OCLAVI’ project, the selection of the four business users was based on their availability. There were some colleagues whom the project team leader considered suitable to be involved. However they had turned down the invitation due to heavy workloads and busy travel schedules. Under these circumstances, only those who were less busy and were willing to participate in the project team were selected.

This also happened in the IT department. Due to the unavailability of technical skills amongst the IT department staff to develop the Web Site, the only other alternative was to purchase the ‘Commercial Package Off The Shelf’ (COTS). Extra expenses were incurred in the engagement of an outsource consultant to train the IT department staff how to use the Web Enabling Tools. Such expenditure might violate the Low Cost Strategy.

The constraints of the ‘right time and the right facilities’ were also viewed as perhaps rather unrealistic. The project almost, foundered on several occasions, as one might expect. For example, the dates, times and venues of the project meetings had to be changed at very short notices due to the unavailability of either team members or meeting facilities (e.g., meeting room, overhead projector, flip chart, screen, network connection, power socket etc.).

5.8.3 Communication gap between business management and IT professionals

As demonstrated in the case study, DBOA had encouraged constructive communication between business management and IT department staff, and had provided with the mechanism to help IT department staff to clarify the organisational terms and concepts used in the SMP. On the other hand, the management were very much involved, to the point where the ‘project team’ was quite definitely an apt description of a mix of people – both ‘business’ and ‘technical’ expertise was brought to bear upon the project. There was an integration of these two roles and a change of relationship from supplier/consumer to partnership. To quote Mike Bull, the Managing Director of CAD:

“… It is very important to improve communication amongst project team members. I believe that ‘team spirit’ will improve project success, business performance and quality of services…”

However, the narrowing of the communication gap between the business and IT had nevertheless, on some occasions, also introduced conflict between them. It may seem contradictory that an improvement of communication could have led to a conflict, but due to the ‘mix’ of the project team members, the ownership of the project should equally be shared by both the business and the IT department staff. It was found that when the project achieved some results, team members tended to claim credit for themselves. When there were problems, certain team members tended to refuse to accept responsibility for them and began blaming each other. The situation had become: “Your success is my success. My problems are your problems too!” This tension, on some occasions, caused misunderstanding amongst team members, had impaired team spirit and increased arguments.

5.8.4 Joint Requirement Planning / Joint Application Development

A holistic approach, a result of the partnership between business and IT, tends to improve the understanding of business by the IT department staff. Hence IT department staff are able to appreciate the business situation, identify the business strategies and fulfil the expectations from the business more effectively and accurately. The objective of JRP and JAD is to get team members from all backgrounds to focus on a common goal. Logically, the commitment from all parties should be equal. In the case of the ‘OCLAVI’ project, certain management staff members still maintained the attitude that it was an IT project, not a business project and tended to avoid ‘over-commitment’. On one occasion when a manager was consulted by an IT department staff about some ideas, this person expressed a reluctant saying, “… I’m not paid to do your job…”. As a result, most ideas and decisions actually came from the IT side. This kind of incident shows that the business community has yet to be convinced that software development can be seen as business development.

5.8.5 Iterative Prototyping

The iterative prototyping approach is intended to enable the project team to review the application and modify it, in response to changes in business requirements, in the very early stages of the project. This should leave sufficient time to remedy any shortcomings of the application. In the case of the ‘OCLAVI’ project, the business users also welcomed such an approach. However this imposed considerable pressure upon the IT department staff. They found it a daunting task to produce a Functional Prototype for the users to test within a very short period of time, in order to meet the Time-box deadline. Subsequently, the IT department staff had to modify the Functional Prototype and to produce the Design Prototype for testing before another Time-box deadline, for testing. Then, they had to modify the Design Prototype again for pilot testing before the time-box deadline. After the pilot testing, they once again, had to modify and debug the application for implementation before the Time-box deadline. During the various project phases, the IT department staff felt that they were under a lot of pressure as a direct result of having to produce four different versions of prototypes against various deadlines.

5.8.6 Business management involvement

One of the motivations of DBOA is the involvement and participation of business management in the project. It is believed that their involvement will enable IT department staff to implement the business strategies more effectively. Through the experience obtained from this project, it was noted that too much emphasis on business management involvement might contradict the DSDM’s principle of: “…Design recommendations are not good enough. Empowered decision-makers are essential…”. When management were too much involved, they tended to assume more responsibilities than they should, with the result that decisions were not delegated to the appropriate ‘empowered decision makers’, as they should have been. Consequently, even some trivial matters were unnecessarily passed upward to the management for approval, which resulted in delays.

5.9 Closing Remarks

This chapter has described the ‘OCLAVI’ project using DBOA. The initial feedback from the company’s management was that they felt the project had been successful in terms of meeting the project requirements, delivery deadline and cost. Due to the newness of the system, the long-term benefit with regard to competitiveness and profitability remains to be seen. The project needs to be reviewed in six months’ time when business results, such as sales volumes, numbers of customers and profitability, are obtained. The evaluation of the case study has also highlighted several difficulties encountered with the DBOA implementation such as: the selection of right people for the project team, conflict amongst project team members, over-involvement on business management contradicting the empowerment of decision makers, and pressure of the IT developers imposed by the Time-box deadlines in the Prototyping strategy. Nevertheless, these problems may be seen as ‘resistance’ from people, rather than ‘failure’ of the DBOA project. The next chapter will conclude this research study and evaluate the overall effectiveness and potential of DBOA. It will also discuss how, in future research, these ‘resistance’ problems might be solved.

~ Our greatest glory in life consists not in never falling but in rising each time we fall ~

(Silken Lemen)

CHAPTER SIX : CONCLUSIONS

6.1 Introduction

This thesis has proposed a conceptual model of Dynamic Business Object Architecture (DBOA) to support organisational Strategic Management Planning (SMP). The techniques provided aim at bridging the communication gap between business management and IT professionals.

Throughout this thesis, an account of SMP has been given. The research focuses upon the overriding importance of SMP for organisations if they are to remain competitive. The ‘Open-ended’ question format SMP interviewing form and the ‘Closed’ question format SMP Checklists have been generated as part of this research to capture the business situation, measure business performance and identify business strategies. The process improvement techniques using the ISO9000 Standard Operating Procedure to assimilate business strategies to business processes have been defined. Object-Oriented Analysis and Design (OOAD) methods, Business Objects (BOs) and Business Object Architecture (BOA) have been explored, surveyed and examined. The Dynamic Systems Development Method (DSDM), a project management approach, has also been studied and its contributions and deficiencies have been evaluated.

The development of a Dynamic Business Object Architecture (DBOA) has been described thoroughly in Chapter 3. DBOA was implemented in a business organisation through a case study to demonstrate the practical application of the techniques. The results of the case study provided an early indication the primary benefit of DBOA was to be able to reduce the distance of the communication gap significantly by ensuring the IT professionals retain the business focus throughout the development lifecycle. In addition, it minimised the risk of omitting any of the essential stages of the implementation process from capturing business situation to delivering software application.

The review mechanism of DBOA aims to support ‘continuous improvement’ of business performance, thus further enhancing the reliability of this approach. Project team also considered that DBOA may also be generally applicable, as its implementation would only require a few relatively minor sector specific modifications if it is applied to

other organisations. This particular finding supports the claim that DBOA can be expected to provide a low cost and an easy to implement solution to the communication gap problem.

However the case study also highlighted several difficulties encountered during the implementation of DBOA. The scepticism that often accompanies the introduction of new paradigms into organisations and the shifts in the organisational culture required for successful management of changes are the areas that need to be addressed before the impact of DBOA could be maximised. Some other research efforts such as the ‘continuous improvement’ in business performance, validation and customisation of the SMP Checklists and automated tools to support DBOA, are also identified as the scope for future research.

6.2 Review of the research

The aim of this research study has been to investigate some new and emerging technologies to address the old and fundamental problem of the communication gap between business management and IT professionals. The main task of the present study has been to integrate these technologies in an attempt to develop a solution to bridge this communication gap. The task of this thesis, is to demonstrate that this integration forms the basis for a novel approach; and to suggest that in the development of such an approach, there are important implications for both the business and IT communities in the future of software development for business applications.

The aim of DBOA development is to support organisational SMP. SMP is recognised as the key which enables organisations to become more competitive and successful. DBOA attempts to provide a mechanism to help IT professionals to more effectively capture the organisational business situation, measure business performance, identify business strategies and implement business strategies through software development. With this mechanism, both IT professionals and business management will benefit from an enhanced mutual communication.

DBOA is a conceptual framework with all the steps and techniques necessary to monitor the above processes, which will minimise the risks associated with human error or negligence encountered when implementing business strategies. Furthermore, DBOA is intended to ensure a smooth transition from the business strategic level to the software development level. It also seeks to provide a mechanism to review software development against improvement in business performance subsequent to its implementation.

6.3 Review of DBOA approach

Throughout this research, organisational challenges were investigated and addressed. A detailed analysis of these challenges was conducted. Strategic Management Planning (SMP) was examined and studied. Various new software technologies (Object-Oriented Analysis and Design Methodologies (OOAD), Business Objects (BOs), Business Object Architecture (BOA)) and software project management technology (Dynamic Systems Development Method (DSDM)) were investigated. The development of the DBOA represents an integration of the SMP, BOs, BOA and DSDM.

DBOA is intended to raise IT professionals’ awareness that their communication gap with the business management could be improved if the software they develop is targeting to implement the business strategies.

6.3.1 ‘S.M.A.R.T.’ evaluation criteria

DBOA is evaluated by the ‘S.M.A.R.T.’ evaluation criteria to see if it is:

6.3.1.1 ‘S’calable

‘Scalable’ refers to the ability of a software application to expand to meet future needs or additional requirements without the need to redesign the basic system. In the case of DBOA, although different BOs may share the same databases, OO analysis and design models, business processes and business strategies, the number of BOs can be increased without affecting the integrity of those already in existence.

6.3.1.2 ‘M’easurable

‘Measurable’ refers to the ability to quantify the level of a situation as an indication or a signal to enable necessary action(s) to be taken. In DBOA development, the SMP Checklist Manual Assessment provides a simple formula to measure the percentage of the business objectives achieved, namely:

Number of objectives met x 100% = percentage of objectives met

Total number of objectives set

An increase in the percentage of the objectives met indicates a greater degree of success in meeting the business objectives, and vice versa.

6.3.1.3 ‘A’chievable

‘Achievable’ refers to the feasibility of accomplishing the business goal or objective. The holistic approach of the DSDM life cycle adopted in the DBOA

development increased interactions between business management and IT professionals. The SMP ‘Open-ended’ question interviews and the SMP ‘Closed’ question Checklist Manual Assessment exercises have also improved communication between them.

In the case of the ‘OCLAVI’ project, at this stage the project team could not assess the long-term impact of DBOA, that is, whether it had actually assisted in the achievement of the objectives set by the business. Nevertheless, it was the experience of the IT department staff in the case study that they felt it relatively easier to achieve user requirements using DBOA compared with other approaches they had previously adopted.

6.3.1.4 ‘R’eusable

‘Reusable’ refers to the ability of the software components to be used again in different applications. In DBOA, the BO is a classic way of object reuse through the reuse of components inside a BO such as business strategic models, business processes, OOAD models and DBMS in different business applications.

6.3.1.5 ‘T’ime-manageable

‘Time-manageable’ refers to a good time-management on project which ensures the project is delivered on time. In DBOA, the Time-boxing technique has offered a good time-management control to ensure that a project is delivered on time thereby eliminating the risk of project becoming over-budget, or failing to be delivered.

6.3.2 Difference from other Business Object models

As discussed in Section 2.4.5, BOs have been used to build different business applications. The main difference between DBOA and other BO models is the use, by DBOA, of the OO paradigm in the business strategic discipline. The adoption of conventional OO is intended to improve software performance by reusing software components through the techniques of inheritance, polymorphism and encapsulation. The transformation from a traditional software-driven OO design concept to a more business-driven business process concept has been claimed by some OO methodologists and researchers to be successful. However the effectiveness of the business processes has yet to effectively reflect the business strategies imposed by the business.

As mentioned in Section 1.7.2, Business Process Re-engineering only covers the way business activities are conducted. There is no link between business processes and business strategies. Currently, researchers and developers in BO are more interested in the reuse of business components which encapsulate the business activities taking place

within the business domain, for example, order taking, invoicing, payment, inventory, stock taking and purchasing. However by defining the business activities without understanding the organisational aims and objectives behind them may prove to be insufficient. Software cannot offer the maximum business benefit unless it is developed to implement business strategies.

Strategies help organisations determine business directions. Some organisations might have their business strategies in place, but the business processes might not correctly reflect these strategies. If business processes are there to implement the business strategies, they should accurately reflect the business strategies in day-to-day business operations. Some organisations do not even have strategies so it would be impossible to develop any software application to implement the business strategies.

Apparently, there is an absence of mechanisms in other BO models (refer to Section 2.4.5), that can link business strategies and business processes together and to ensure that business processes embrace the essence of business strategies. The critical factor for achieving business objectives depends on how business strategies are implemented, that is how the ideas and instructions are defined. DBOA attempts to provide the mechanism to link the business strategies to the business processes. This differs markedly from a variety of other approaches of BO to develop software as business solutions.

6.4 Limitations of DBOA

Theoretically, DBOA may seem to be an ideal ‘modus operandi’ to implement the business strategies via software development. However the effectiveness of DBOA could not be proved without first applying it in a real business environment. For this reason, a case study was carried out in a business organisation. As described in Section 5.8 (Evaluation of the case study), the project revealed some difficulties encountered during the early stages of DBOA implementation. The following sub-sections will discuss further the limitations of DBOA which would need improvements before it can truly be regarded as a proven and mature technology.

6.4.1 Pride versus honesty

The ‘Open-ended’ question format in the SMP interview initially aims at encouraging business management to express their views and concerns about their business situation more frankly and genuinely. However the experience gained from the case study has shown that in some situations, the management felt uneasy discussing the current business situation and sought to protect themselves from possible embarrassment. If problems are concealed, the SMP interviews cannot be taken as totally reliable.

The same phenomenon also applies to the ‘Closed’ question format SMP Checklist Manual Assessment. The SMP Checklist Manual Assessment is intended to quantify the results of the SMP ‘Open-ended’ question interviews as a means of measuring business performance. However it was found that on some occasions, management appeared to be hesitant and indecisive when asked to decide the level of the business performance in some areas. They seemed not to admit the existence of certain problems or just avoided discussing the whole issue. This could make the results of the SMP Checklists a less accurate measure of business performance.

Since DBOA is not developed to be a ‘lie detector’, the answers can only be based on the information obtained from the business management. The interviewer could only use his/her judgement to decide the reliability of the information. Essentially, the interpersonal and communication skills of IT professionals play a very important role in this respect so that business management would be convinced positively and constructively of the business benefit that can be gained through DBOA.

6.4.2 Friction between business management and IT professionals

The business management and IT department staff did not get along well on some occasions during the case study. The management thought that it was a waste of time putting their business duties aside to spend time with the IT department staff to conduct the interviews and the SMP Checklist Manual Assessment exercises.

On one occasion during the project, a Business Manager was arguing with the IT department staff. The IT department staff asked the Business Manager: “… Tell me about your business goals, aims and objectives…”. The Business Manager replied: “… Tell me about what you have got to help me achieve my business goals, aims and objectives…”.

At first glance, the above statement may seem to indicate that the Business Manager did not know about how to achieve his business goals, aims and objectives. However a second look revealed that it was, in fact, quite a sarcastic statement. It indicated that the Business Manager thought the IT department staff was not supposed to know about his business decisions. Thus, this Business Manager expressed the view that he wanted to know how the capabilities and competences of the IT department staff could help him achieve his business goals.

Some business personnel are sceptical about technological advancement. They are sometimes uncooperative with IT personnel as they regard the technology as a threat to their job security. Even though some business personnel have a more open-minded attitude and they understand that the purpose of technology is to offer solutions to solve business problems and to help them carry out their duties better, they still think that their skills might eventually be made redundant by the technology.

Another difficulty is that it is not easy to sell the idea of DBOA to a sceptical management team. A senior manager put it as follows:“…Why interview, why checklist… If I want to improve my customer services, I do not need your DBOA. I can just ask all my staff to smile to the customers. I can just send Christmas cards to all my customers. This works too…”

6.4.3 Short- to medium- to long-term return on investment

The speed of the ‘continuous improvement’ as suggested in DBOA may be considered to be too long for some organisations. Business management want to see their return on investment quickly (in most circumstances less than a year). They are only interested in the short- to medium-term of the return on investment. They would lose patience waiting for anything that would take more than a year or so to produce the end results. In this case, the IT professionals should not give an impression to the management that DBOA is a ‘quick fix’ treatment. The results of the DBOA approach cannot be achieved overnight. Its achievement is based on the success of software applications delivered to business. It stays with the organisation as long as it is in business.

6.4.4 Time-boxing syndrome

The Time-boxing approach claims to have a nice balance between quality and time control. In Time-boxing, everything is set inside a time-scale agreed between IT professionals and business management, with priorities set. That is the reason why the Time-boxing technique is used to run DBOA project.

However the increasing pressure to produce a prototype in a short period of time and to meet not just one, but several deadlines forced the technical developers to juggle between software quality and timely delivery – especially in a tightly budgeted project. Developers face the dilemma of either delivering quality software at the price of a longer development time and higher cost or delivering software quickly, but neglecting quality.

Experience has indicated that if planning is insufficient, developers may be forced to omit some unfinished tasks if they overrun the Time-boxes or panic to catch up at later Time-boxes, or they might even have to abandon the whole project due to the pressures imposed on them.

6.4.5 Work pattern/paradigm shifts for both business and IT personnel

With DBOA, it may seem that the boundary between the business world and the technical world is removed. IT professionals have crossed the border to communicate with business management. They are also given an opportunity to experience working in a business environment as opposed to their own technical environment. However some IT professionals have found it difficult adapt to this change in their work practices and to re-train themselves to learn new skills and acquire business knowledge.

Some in business management still have the attitude that it is not their duty or their responsibility to join a DBOA development team and work with IT personnel. They still maintain the view that a DBOA project is largely concerned with technical matters and has little to do with business.

This problem might be overcome if IT professionals were to use minimum technical rubrics and software jargons such as: ‘problem domain’, ‘methodologies’, ‘re-engineering’, ‘encapsulation’ and the like. That would foster the relationship between business management and IT professionals by utilising a common language.

6.5 Research Progress

The underlying DBOA framework has been established. DBOA is a conceptual model offering a complete life cycle basis for managing the processes from capturing an organisational business situation through to software application development. DBOA has been applied practically in a business organisation through a case study which took place at a credit insurance company. The project span was six months and was completed in November 1998. A post-project review SMP Checklist Manual Assessment exercise will be conducted six months after the completion of the project. Due to the time allowed for this research and the completion of research funding in December 1998, the results of this exercise cannot be included in this thesis.

Within the limited time and resources of this research study, there was only one case study using the full scope of DBOA (DBOA has been partially used by other projects before this case study). Certainly, one case study can only provide limited information, so that it is difficult to judge whether or not the results of this research can prove that DBOA has helped to bridge the communication gap between business management and IT professionals. There is therefore a need to conduct further case studies, in a variety of other organisations in different business sectors, and to compare the results. While no formal method is used to prove the results, case study approach, thus serving as a qualitative analysis to test the feasibility and effectiveness of the approach. It is for this reason that the findings of different case studies could be used to perform an empirical analysis that supports the hypothesis of DBOA.

6.6 Further Research

New research dimensions have emerged from the results of this study. As discussed in Section 5.4, the case study experience has produced some insights into the implementation difficulties experienced by the project team when applying the concepts of DBOA in a real business situation. There is an important distinction to be made between ‘theory’ and ‘practice’. Due to its significant research implications, it would be useful to investigate the difference between the conceptual model of DBOA (theory) and the real world situation dealing with the business management personnel (practice) in the light of this research. A comprehensive model, integrating the theoretical approaches of DBOA and the experiences from practice, would offer some possible approaches to improve this situation. At the time of submitting this thesis, proposals for future extensions to this work are described in the following sub-sections.

6.6.1 Cultural shifts within organisation

As discussed in Section 6.4, the implementation problems of DBOA were largely caused by the cultural phenomena. The negative attitudes and indifferences in behaviours by some people in a single organisation have blocked the shifts of paradigms introduced by DBOA.

This incipient problem only emerged when a DBOA project was actually running in a real situation – thereby revealing the attitudes of the participants. For this reason, the results of the SMP interviews and the SMP Checklist Manual Assessments might not be as reliable as they are sometimes thought to be. As mentioned in Section 6.4.1, some people may say one thing in an interview and act differently in reality. Those incidents have led to the need to diagnose the cultural aspect of the organisation and to identify a solution to overcome human scepticism to change.

Organisational culture is complex as it involves many aspects and facets within an organisation. Johnson [Johnson et al 1997] has already pointed out that to change the culture is important, but it is also difficult and complicated.

6.6.1.1 Cultural Web Analysis

The outcome from the case study has revealed that CAD is a typical example of an organisation which has embedded a long-standing culture into the organisation itself. The people working there are very used to their way of doing things, to the extent that new ideas are regarded with suspicion. Figure 6-1 is a Cultural Web Analysis diagram adopted from Johnson [Johnson et al 1997] to analysis the current culture in CAD.

Figure 6-1 : Cultural Web of CAD

The Cultural Web Analysis diagram for CAD in Figure 6-1 has pulled together the observations and the outcomes of the case study. Through mapping the various aspects of the paradigm and culture of an organisation, it might be easier to understand the implementation problems of applying DBOA to the organisation. It has also highlighted which elements should be managed and changed to enable the DBOA to be adopted more successfully.

6.6.1.2 Forcefield Analysis

In addition to the Cultural Web Analysis, another way to identify more precisely those factors affecting the application of DBOA is the Forcefield Analysis adopted from [Johnson et al 1997]. The Forcefield Analysis diagram in Figure 6-2 shows what are the forces for and against the implementation of DBOA, in CAD.

Figure 6-2 : Forcefield Analysis based on CAD’s Cultural Web

6.6.1.3 Desired Cultural Web

The Forcefield Analysis provides an initial view of the problems that need to be tackled which might have been specified through the Cultural Web. It lists the forces in favour of the adoption of DBOA and the forces against it. In the case of CAD, the forces mainly come from the people’s attitudes. It is recommended that future research should investigate mechanisms to tackle the cultural problem within organisations when applying DBOA. A desirable Desired Cultural Web for the future is presented in Figure 6-3.

DBOA attempts to bridge, or at least reduce, the communication gap between business management and IT professionals. The ‘cultural shifts’ that arise in an organisation have very much to do with human behaviour. The achievement of the conditions for DBOA to best fit an organisation’s culture can be judged on the basis of those who are responsible for implementing the DBOA, that is the I.T. professionals and

those who would be affected – namely the business management and the application users. It is understood that this would be a major shift of paradigm involving the whole organisation. For this reason, the SMP interview and the SMP Checklist Manual Assessment exercise should be conducted with all company staff at all levels as opposed to just with the management staff, to acquire a more accurate situation within an organisation.

Figure 6-3 : Desired Cultural Web for CAD

The implementation of DBOA is as much a cultural issue as it is a technical one. Organisations need to be more open to new approaches and structures, as well as new technology, if they are to derive the full benefit of DBOA. DBOA must be culturally acceptable within an organisation – this will require proactive management, new measurements for success and incentive schemes. DBOA should be made part of a company’s goals rather than being treated as a method or approach to run software projects. In summary, to enable DBOA to be more successfully adopted, this thesis recommends that organisations should provide an environment with:

the right mix of new management techniques and technology that can support the cultural shifts an organisation faces;
proactive and open-minded management;
new incentive schemes and measurements for success;
an evolutionary, as opposed to revolutionary, approach to organisation change.

Much research effort is currently being put on tackling the side effect of cultural shifts in organisations when new paradigms of work practice are introduced. As yet there is no ideal solution and it would be worth experimenting other sources of technologies in order to minimise the risk in skills transfer and maximise the acceptance from people. Future research must address this issue if further progress is to be made in this challenging area of research.

6.6.2 Continuous Improvement

To achieve ‘continuous improvement’ in business performance, when the next post-project review SMP Checklist Manual Assessment takes place, any identified failures in meeting the business objectives must be able to trigger the process improvement stage which should filter through the object modelling and application design. ‘Continuous improvement’ also includes improvement in communication between business management and IT professionals as proposed in the Desired Cultural Web in Section 6.6.1.3.

6.6.3 Validation of SMP Checklists

Personal opinion can sometimes be subjective. One can argue that the improvement of business performance may not necessarily be attributed to certain software applications. Business performance can be improved by various means other than software. Although the software development using the DBOA approach is initiated by an SMP Checklist Manual Assessment exercise, it may be argued that the success of software applications is not necessarily attributable to the accuracy of the SMP Checklist Manual Assessment in measuring business performance. Others may say that software applications can also successfully support business through avenues other than via the contribution of an SMP Checklist Manual Assessment.

So far, the linkage between business performance measurement and the software development is still vague. There should be a link to connect them together in order to transcend the subjective views of different individuals to objective views to promote the effectiveness of DBOA.

Furthermore, the SMP Checklist Manual Assessment currently only provides a percentage of the overall objectives achieved within a particular business strategy. In order to validate its accuracy, the development of a mechanism to measure not only on a broad level but also on specific level to track each strategic factor and to compare the changes in each of them during different phases of the SMP Checklist Manual Assessment exercises.

6.6.4 Customisation of SMP Checklists

The SMP Checklists presented in this thesis were developed through the study of various literature and publications. CAD’s management staff also contributed substantially giving the benefit of their expertise and their knowledge of insurance industry. The Checklists contain the strategic factors which should be sufficient to be used in the insurance industrial sector. It is anticipated that the SMP Checklists can be easily customised for other industrial sectors based on the checklists produced from this study as they only require a few relatively minor sector specific modifications.

6.6.5 Automated tool to support DBOA

As part of the research plan, it is intended to develop a sophisticated automated DBOA tool with high accuracy, but which is also simple and easy to use. This automated tool should link the SMP Checklists to the ISO9000 Operating Procedure for business processes and filter through the OO models and the application design environment. This automated tool serves two purposes namely:-

To replace the ‘paperware’ with ‘software’ that could eliminate errors at any stage of the development process caused by the carelessness or incompetence of those people who perform the processes.
To further increase the reliability, accuracy and accessibility of the DBOA processes.

Another benefit is that IT professionals can use this user-friendly tool without the requirement of possessing substantial expert knowledge in the field as this tool would take them through the various steps in the implementation processes of a DBOA project. This may help to reduce the shortage of human expertise. With this automated tool, SMP could then be formalised and computerised hence business processes could more easily be audited.

6.7 Closing Remarks

In conclusion, this thesis presents a DBOA model to support organisational SMP. DBOA shows certain advantages with respect to the origination of Business Objects (BOs) and demonstrates that BOs have the potential to become powerful modelling techniques to implement business strategies. DBOA integrates business and IT domains aiming to bridge the communication gap between them. It allows both business management and IT professionals to work together towards business objectives.

Additionally, the review mechanism substantiates the spirit of ‘continuous improvement’ in business performance which makes DBOA adaptive and responsive to environmental changes. The above features of DBOA distinguish it from other BO models in terms of the level of object abstraction and scope of adaptation. The paradigm of DBOA paves the way for new directions in Business Object development. Even though after the case study, rather than the many that would be needed to support a strong claim for the usefulness of DBOA, the fact that it was regarded as useful in developing a needed strategic software system is evidence in its favour. DBOA provides a new conceptual modelling method which the research advocates as a useful guideline for developing an automated strategic tool.

The cultural shifts in an organisation when new paradigms are introduced and scepticism from some people towards DBOA are the two teething problems which arose from the case study. Indeed, these can be deemed to be beyond the scope of the current research. This does not however render them inappropriate as conclusions to be, at least, thought about. If resistance to change from people in organisations is inevitable, recommendations can be made that may minimise the problems. In view of this, future research work is anticipated focusing upon the adoption of new techniques for example, Culture Web Analysis and Forcefield Analysis, to improve the cultural shifts and scepticism problems.

Finally, the benefits of the ISO9000 Standard Operating Procedure, Object-Oriented Analysis and Design Modelling technique using the UML standard notation and the ‘Redback’ Web Enabling Tools were not fully evaluated throughout this thesis. It was mainly because other techniques like SMP, BOs and DSDM were considered to be more practical in terms of the core focus of this research. It is also worth emphasising that DBOA is a conceptual model, independent from any OO design methodologies or OO programming languages.

~ The world is moving so fast these days that a person who says it can’t be done is generally interrupted by someone doing it ~

(Harry Emerson)

REFERENCES

[Adels et al 1997]. Adels H, Beelaard R and Symons A. “Delivering quality in global IT services” in the British Computer Society Software Quality Management ’97 Conference Proceedings. Mechanical Engineering Publications, London, 1997, pp 15-26. ISBN 1 86058 110 2.

[Alexander 1996] Alexander, C. “The Pattern Language” in the Conference on Object-Oriented programming systems, Languages, and Applications 1996, San Jose, CA, October 1996, ACM/SIGPLAN Conference Proceedings.

[Angoss 1996] Angoss Software. Angoss RAD Developer Manual. Angoss Software International Ltd., Toronto.

[Ardent 1998] Ardent Software (1998). “Redback Web Application Development Tool Getting Started User Manual”. UniData, Inc. Denver, Colorado. Documentation DRB-1401 Rev. 051297.

[Baker 1996] Baker M. “Workflow Meets Business Objects” in the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’96) Business Object Design and Implementation Workshop II. October 1996, San Jose, CA, TX, USA. (Source: http://www.tiac.net/users/juth/oopsla96/oo96final.html)

[Barrett et al 1997] Barrett N, Lillie J and Howard T. “PHH Insurer Service – MotorFlex” in the DSDM European Conference, 17^th-18^th September 1997, Warwick, UK (Source: http://www.dsdm.org)

[Beedle 1997] Beedle M. “A ‘light’ distributed OO Workflow Management System for the creation of Enterprise Architecture in BPR environment” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’97) Business Object Design and Implementation Workshop III. October 1997, Atlanta, GA, USA. Springer, London 1998. ISBN 1-85233-108-9, pp 90-99.

[Berrisford et al 1994] Berrisford, G and Robinson, K. Object Oriented SSADM. Prentice Hall, London, 1994. ISBN 0 13309 444 8.

[Berrisford 1996] Berrisford, G. “Discrete event modelling” in the Proceedings of Object-Oriented Information System 1996 Conference. London, December 1996. Springer-Verlag, London, 1996, pp 340-354. ISBN 3-540-76132-2

[Best 1995] Best L. “What is Architecture Software Development?” in an article served by the Portland Pattern Repository, AMS Inc., USA. Source: http://c2.com/ppr/ams.html

[Blackman 1995] Blackman C. “Introducing RAD into Legal & General” in the DSDM European Conference, 5^th-6^th December 1995, London, UK (Source: http://www.dsdm.org)

[Boehm 1986] Boehm, B. “A Spiral Model of Software Development and Enhancement” in the ACM SIGSOFT Software Engineering Notes, August 1986.

[Booch 1994] Booch G. Object-Oriented Analysis and Design. Benjamin-Cummings Publishing Company Inc. 1994 (2^nd Edition). ISBN 0-805-35340-2.

[Booch et al 1998] Booch G, Jacobson I and Rumbaugh J. The Unified Modeling Language User Guide. Addison-Wesley, Mass, USA 1998. ISBN 0-201-57168-4.

[Brown et al 1996] Brown C and Asch D. Managing Strategy. Macmillan Press, NY.

[Brown et al 1997] Brown C and Pearson I. “Britannia Building Society Client Borrowing Programme” in the DSDM European Conference, 17^th-18^th September, Warwick, UK (http://www.dsdm.org)

[Butler 1995] Butler Group (1995). Strategy on Rapid Application Development. Butler Group, Hull, UK.

[Butler et al 1997] Butler J, Goodings K and Harrow E. “The Internet and DSDM” in the DSDM European Conference, 17^th-18^th September 1997, Warwick, UK (Source: http://www.dsdm.org)

[Casanave 1995] Casanave C. “Business-Object Architectures and Standards” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’95) Business Object Design and Implementation Workshop I. October 1995, Austin, TX, USA. Springer-Verlag, London, 1997. ISBN 354060962, pp 7-28.

[Casanave 1997] Casanave, C. “Standardised Business Objects” in the Conference of Building & Using Financial Business Objects, London, UK, 22-23 October 1997 (http://www.omg.org).

[Choudhury et al 1997] Choudhury I and Patel D. “Business Object Modelling Approach to develop a Customer Services framework to enable horizontal Reuse across Vertical Industries” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’97) Business Object Design and Implementation Workshop III. October 1997, Atlanta, GA, USA. Springer, London 1998. ISBN 1-85233-108-9, pp 178-182.

[Clegg 1996] Clegg D. “RAD and OO – Two Acronyms for the price of one” in the DSDM European Conference, 27^th-28^th November 1996, London, UK (Source: http://www.dsdm.org)

[Constantine 1996] Constantine, L. “Objects As If People Mattered” in the OOPSLA’96 Conference, San Jose, CA, October 1996. Source: http://www.acm.org/sigplan/oopsla/oopsla96/oopsla96.html.

[Daniels 1996] Daniel, J. “The Reality of Business Objects Today” in the OMG Building and Using Financial Business Objects Conference, 23-23 Oct 1996, London.

[Data Access et al 1997] Data Access Technologies, Sematech, Inc., Prism Technologies, Iona Technologies Ltd. “Business Object Facilities Submission” in the Object Management Group’s Request For Proposal-4. Source: http://www.omg.org.

[Digre 1995] Digre T. “Business Application Components” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’95) Business Object Design and Implementation Workshop I. October 1995, Austin, TX, USA. Springer-Verlag, London, 1997. ISBN 354060962, pp 151-165.

[Digre 1996] Digre, T. “Business Objects Facility Presentation in the OOPSLA’96 Conference Business Objects Design and Implementation II Workshop, 5-10 October 1996, San Jose, California. Source : http://www.tiac.net/users/jsuth/

[Doughty et al 1996] Doughty S and Read C. “Usability and DSDM experiences at the Thames Water.” in the DSDM European Conference, 27^th-28^th November 1996. (Source : http://www.dsdm.org )

[DSDM 1995] DSDM Consortium. Dynamic Systems Development Method Version 2.0. Tresseract Publishing, Surrey, UK, 1995.

[DSDM 1996] DSDM Consortium. The Underlying Principles of DSDM. Source: http://www.dsdm.org/method.html

[DSDM 1997] DSDM Consortium. Dynamic Systems Development Method Version 3.0. Tresseract Publishing, Surrey, UK, 1997.

[Dunn 1997] Dunn S. “Lease Plan UK Ltd’s DSDM case study” in the DSDM European Conference, 17^th-18^th September 1997, Warwick, UK (Source: http://www.dsdm.org)

[Earl 1989] Earl M.J. Management Strategies for Information Technology. Prentice Hall, 1989. ISBN 0-135-51656-0.

[EDS 1997] Electronic Data Systems Corp. “Business Object Facilities Submission” in the Object Management Group’s Request For Proposal-4. Source: http://www.omg.org.

[Elliot 1997] Elliot G. “DSDM within WH Smith News” in the DSDM European Conference, 17^th-18^th September, 1998 (source: http://www.dsdm.org)

[Estrin 1998] Estrin L. “Business Object Transitioning” in the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Source: http://www.jeffsutherland.org/oopsla98/estrin.html.

[Evitts 1996] Evitts P. “Business Objects, Business Patters” in the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’96) Business Object Design and Implementation Workshop II. October 1996, San Jose, CA, TX, USA. (Source: http://www.tiac.net/users/juth/oopsla96/oo96final.html)

[Faulkner et al 1995] Faulkner D and Rowman C. The Essence of Competitive Strategy. Prentice Hall International (UK) Ltd., Exter, UK. ISBN 0-13-291477-8

[Firesmith et al 1997] Firesmith D, Henderson-Sellers B and Graham I. OPEN Modeling Language (OML) Reference Manual. SIGS Books, NY, USA, 1997. ISBN 0-521-64823-8.

[Ford 1996] Ford D. “Using RAD to support the Nortel Competitive Intelligence Project” in the DSDM European Conference, 27^th-28^th November 1996, London, UK (Source: http://www.dsdm.org)

[Fowler 1996] Fowler M. “Analysis Patters and Business Objects” in the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’96) Business Object Design and Implementation Workshop II. October 1996, San Jose, CA, TX, USA. (Source: http://www.tiac.net/users/juth/oopsla96/oo96final.html)

[Freburger 1987] Freburger, K. “Rapid Prototyping Control Panel Interfaces” in the OOPSLA’87 Conference, Orlando, FL., 1987. OOPSLA Proceeding Compendium ACM SIGPLAN CD-ROM.

[Gamma et al 1995] Gamma E, Helm R, Johnson R and Vlissides J. Design Patterns : Elements of Reusable Object-Oriented Software. Addison Wesley Longman Inc., Mass, USA, 1995 (11^thEdition). ISBN 0-201-63361-2.

[Genesis/Visigenic 1997] Genesis Development Corp & Visigenic Software Inc. “Business Object Facility Submission” in the Object Management Group’s Request for Proposal-4. Source: http://www.omg.org.

[GOAL/QPC 1985] GOAL/QPC. The Memory Jogger – A Pocket Guide of Tools for Continuous Improvement, GOAL/QPC, 13 Branch Street, Methuen, MA 01844, USE. ISBN 1-879364-03-4.

[Graham 1994] Graham I, Migration to Object Technology, 1994, Addison-Wesley, N.Y. ISBN 0-201-59389-0.

[Griffith 1997] Griffiths V. “The High Value of Low Profits” in the Financial Times dated 10^th June 1997. Source: http://www.ft.co.uk

[Grothehen et al 1995] Grothehen T and Schwarb R. “Implementing Business Objects: CORBA Interfaces for Legacy Systems” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’95) Business Object Design and Implementation Workshop I. October 1995, Austin, TX, USA. Springer-Verlag, London, 1997,pp 87-93. ISBN 354060962.

[Guido et al 1997] Guido G and McCarthy W. “Accounting as Romance: Patterns of Unrequited Love and Incomplete Exchanges in Life and in Business Software” in the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’97) Business Object Design and Implementation Workshop III. October 1997, Atlanta, GA, USA. (Source: http://jeffsutherland.org/oopsla97/oo97final.html )

[Hammer et al 1995] Hammer M and Champy J. Reengineering the Corporation – A Manifesto for Business Revolution. Nicholas Brealey Publishing, London, UK, 1995 (19^th Edition). ISBN 1-85788-056-0.

[Haugen 1997] Haugen R. “Radically Distributed Supply Chain Systems” in the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’97) Business Object Design and Implementation Workshop III. October 1997, Atlanta, GA, USA. (Source: http://jeffsutherland.org/oopsla97/oo97final.html )

[Haugen 1998] Haugen R. “Which Business Objects?” in the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Source: http://www.jeffsutherland.org/oopsla98/haugen.html.

[Hemal 1997] Hemal G. “Strategies Manifesto” in the Fortune Magazine, Fall 1997 (Source: http://www.strategosnet.com).

[Henderson-Sellers et al 1994] Henderson-Sellers B and Edward J. Book Two of Object-Oriented Knowledge: The Working Object. Prentice-Hall, Sydney, Australia, 1994, ISBN 0-130-93980-3.

[Henderson-Sellers et al 1996] Henderson-Sellers B, Graham I and Firesmith D. “Using Object-Oriented Techniques to Model the Life Cycle for OO Software Development” in the 1996 International Conference on Object Oriented Information Systems (OOIS’96), London, Springer, London, 1996, pp211-220. ISBN 3-540-76132-2.

[Henderson-Sellers et al 1997] Henderson-Sellers B and Firesmith D. “Choosing Between OPEN and UML” in the American Programming, Vol. 10, Issue 3, PP 15-33.

[Henderson-Sellers et al 1998] Henderson-Sellers B, Simons A and Younessi H. The OPEN Toolbox of Techniques. Addison-Wesley, Mass, USA,1998 (1^st Edition), ISBN 0-201-33134-9.

[Hertha et al 1995] Hertha W, Bennett J, Post F and Page I. “An Architecture Framework: From Business Strategies to Implementation” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’95) Business Object Design and Implementation Workshop I. October 1995, Austin, TX, USA. Springer-Verlag, London, 1997. ISBN 354060962, pp 47-60.

[Herzlich 1995] Herzlich P. “Looking for metrics from the early adopter programme” in the DSDM European Conference, 5^th-6^th December 1995, London, UK (Source: http://www.dsdm.org)

[Herzum et al 1998] Herzum P and Sims O. “The Business Component Approach” in the Proceedings of the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Springer, London, 1998. ISBN 1-85233-108-9, pp 46-58.

[Hordijk et al 1998] Hordijk W, Molter S, Paech B and Salzmann C. “Working With Business Objects – A Case Study” in the Proceedings of the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Springer, London 1998. ISBN 1-85233-108-9, pp 14-18.

[Hruby 1998] Hruby P. “Structuring Specification of Business Systems with UML (with Emphasis on Workflow Management Systems)” in the Proceedings of the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Springer, London 1998. ISBN 1-85233-108-9, pp 77-89.

[Hsia 1996] Hsia, P., Hsu, C., Kung, D., Hepner, M. and Wang, J. “An Object-Oriented Approach to Incremental Delivery of Software Systems” in the OOIS’96 Conference, London, 1996, Springer, London, 1996, pp 431-446. ISBN 3-540-76132-2.

[Hung et al 1997] Hung K and Patel D. “Modelling Domain Specific Application Frameworks with a Dynamic Business Object Architecture (DBOA): An Approach and Implementation” in The Proceedings of the Object-Oriented Programming Systems Languages and Applications (OOPSLA) 1997 Conference Business Object Design and Implementation III Workshop, Atlanta, Georgia, USA, 5^th-9^th October 1997. Springer, London, ISBN 1-85233-108-9, pp 167-177.

[Hung et al 1998(a) Hung K, Simons A and Rose T. “The Truth Is Out There?: A Survey of Business Objects” in the Proceedings of The 5^th International Conference on Object-Oriented Information Systems (OOIS) 1998, 9^th-11^th September 1998 at the University of La Sorbonne, Paris, France. Springer, London. ISBN 1-85233-04605, pp 183-200.

[Hung et al 1998(b)] Hung K, Simons A and Cvetkovic S. “A Dynamic Business Object Architecture For Supporting Strategic Management Planning” in The Object-Oriented Programming Systems Languages and Applications (OOPSLA) 1998 Conference Business Object Design and Implementation Workshop IV, 18^th-22^nd October 1998, Vancouver, Canada (Source : http://www.jeffsutherland.org/oopsla98/oopsla98_hung.html ).

[IBM 1997] IBM Corp. “Common Business Objects Submission” in the Object Management Group’s Request For Proposal-4. Source: http://www.omg.org.

[IBM/Oracle 1997] IBM Corp & Oracle Corp. “Business Object Facilities Submission” in the Object Management Group’s Request For Proposal-4. Source: http://www.omg.org.

[IFPUG 1996] International Function Point Users Group. Ohio, USA. Source: http://cuiwww.unige.ch/OSG/FAQ/SE/se-faq-s-2.html#S-2.

[Jacobson 1996] Jacobson I, “Use Case Engineering Tutorial” in the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA)’96 Conference, San Jose, California, USA, October 1996.

[Jacobson et al 1994] Jacobson I et al, The Object Advantages: Business Process Reengineering With Object Technology, 1994 (Addison-Wesley, New York), ISBN 0-201-42289-1

[Johnson et al 1996] Johnson R and Yoshida K. “Models of Business Objects: Accounts” in the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’96) Business Object Design and Implementation Workshop II. October 1996, San Jose, CA, TX, USA. (Source: http://www.tiac.net/users/juth/oopsla96/oo96final.html)

[Johnson et al 1997] Johnson, G & Scholes, K. “Exploring Corporate Strategy Text and Cases”, Prentice Hall, London. ISBN 0-13-525635-6.

[Kardaras 1995] Kardaras D. “An Integrated Qualitative Caused Model of Organisational and IT Variables and its use in Information Systems Strategic Planning”. PhD Thesis, Department of Computation, University of Manchester Institute of Science and Technology, Manchester, UK.

[Knights et al 1991] Knights D and Murray F. Organisation Politics and Information Technology Management. John Wiley & Sons, ISBN 0-471-93586-7.

[Kossman 1995] Kossman R. “An Architectural Framework for Semantic Inter-Operability in Distributed Object Systems” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’95) Business Object Design and Implementation Workshop I. October 1995, Austin, TX, USA. Springer-Verlag, London, 1997, pp 63-68. ISBN 354060962.

[Kueechler et al 1998] Kuechler B and Burg B. “Using Intentional Information to Co-ordinate Inter-operating Workflows” in the Proceedings of the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Springer, London 1998. ISBN 1-85233-108-9, pp 61-76.

[le Comte 1997] le Comte R. “Business Process and Workflow Management in an Enterprise Resource Planning Context” in the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’97) Business Object Design and Implementation Workshop III. October 1997, Atlanta, GA, USA. (Source: http://jeffsutherland.org/oopsla97/oo97final.html )

[Lim 1998] Lim, W. (1998). Managing Software Reuse. Prentice-Hall, CA. ISBN 0-13-552373-7.

[Longman 1995] Longman B. “Boston Globe Tracking System” in the DSDM European Conference, 5^th-6^th December 1995, London, UK (Source: http://www.dsdm.org)

[Marshal 1998] Marshall C. “Organisation in a Chaotic World” in the Proceedings of the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Springer, London 1998. ISBN 1-85233-108-9, pp 151-155.

[Marshall 1997] Marshall C. “Business Object Management Architecture” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’97) Business Object Design and Implementation Workshop III. October 1997, Atlanta, GA, USA. Springer, London 1998. ISBN 1-85233-108-9, pp 3-13.

[Martin 1991] Martin, J. Rapid Application Development. Macmillan, NY, 1991. ISBN 0-02-376775-8

[McCarthy et al 1995] McCarthy W and Geets G. “Modeling Business Enterprises as Value-Added Process Hierarchies with Resource-Event-Agent Object Templates” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’95) Business Object Design and Implementation Workshop I. October 1995, Austin, TX, USA. Springer-Verlag, London, 1997. ISBN 354060962, pp 94-113.

[McCarthy et al 1997] McCarthy B and O’Shea L. “Irish Permanent Experience in RAD/JAD” in the DSDM European Conference, 17^th-18^th September 1997, Warwick, UK (Source: http://www.dsdm.org)

[McGregor et al 1996] McGregor D et al. “A Pattern For Reuse” in the Object Magazine April 1996, SIGS Publications Inc., NY. Source: http://www.sigs.com/publicatins/doc/objm/9604/objm9604.f.mcgregor.html

[Nakamura et al 1998] Nakamura H and Johnson R. “Adaptive Framework for the REA Accounting Model” in the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Source: http://www.jeffsutherland.org/oopsla98/makamura.html.

[NIIIP1997] NIIIP CONSORTIUM. “Common Business Objects Submission” in the Object Management Group’s Request for Proposal-4. Source: http://www.omg.org.

[Northmore et al 1996] Northmore B and Lambertstock T. “RAD under a fixed price contract” in the DSDM European Conference, 27^th-28^th November 1996, London, UK (Source: http://www.dsdm.org)

[O’Neill 1997] O’Neill J. “SPRINT – Software Performance Improvement Programme” in the DSDM European Conference in the DSDM European Conference 17^th-18^th September 1997, Warwick, UK (Source : http://www,dsdm.org)

[OMG 1995] OMG, Object Management Group – Object Management Architecture Guide, 1995 (John Wiley & Sons, Inc., New York). ISBN 0-471-14193-3.

[Oskarsson et al 1996] Oskarsson, O and Glass, R (1996). An ISO9000 Approach to Building Quality Software. (First Edition). Prentice-Hall, Inc., New Jersey. ISBN 0-13-228925-3.

[Par 1990] ParcPlace Systems, Mountain View, CA. ObjectWorks\Smalltalk Release 4 Users Guide, 1990. Source: http://www.parcplace.com

[Parnell et al 1996] Parnell C, Broom A and Hollins A. “LASSY RADMAN – Rapid Application Development on Automation of Manual Licences” in the DSDM European Conference, 27^th-28^th November 1996, London, UK (Source: http://www.dsdm.org)

[Partridge 1996] Partridge, C. Business Objects Reengineering for Reuse. Butterworth-Heinemann, Oxford, 1996. ISBN 0-7506-2082-X.

[Pascale et al 1994] Pascal R, Athos A and Gross T. “The Reinvention Roller Coaster: Risking the Present for a powerful future” in the BBC Executive Video Seminars in Transformation.

[Paul et al 1997] Paul S, Park E and Chaar J. “Essential Requirements for a Workflow Standard” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’97) Business Object Design and Implementation Workshop III. October 1997, Atlanta, GA, USA. Springer, London 1998. ISBN 1-85233-108-9, pp 100-108.

[Payne 1995] Payne A. “Advances in Relationship Marketing” in the Cranfield Management Series. (Source: http://www.cbs.ac.uk).

[Peppard et al 1996] Peppard J and Rowland P. The Essence of Business Process Re-engineering (Essence of Management). Prentice-Hall, ISBN 0-133-10707-8.

[Poirier et al 1995] Poirier S and Ashford C. “Semantics: The Key to Interoperability” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’95) Business Object Design and Implementation Workshop I. October 1995, Austin, TX, USA. Springer-Verlag, London, 1997. , pp 69-74. ISBN 354060962.

[Porter 1980] Porter M. “Competitive Strategy: Techniques for Analysing Industries and Competitors”. Macmillan Inc., N.Y. ISBN 0-02-025360-8.

[Porter 1985] Porter M. “Competitive Advantage: Creating and Sustaining Superior Performance”. Macmillan Inc., N.Y., 1985. ISBN 068 484 1460.

[Porter et al 1985] Porter M and Millar V. “How Information Gives You Competitive Advantage” in the Harvard Business Review, July/August 1985.

[Ramackers et al 1995] Ramackers G and Clegg, D. “Object Business Modelling Request & Approach” in the Proceedings of Object-Oriented Programming, Systems, Languages & Applications (OOPSLA)’95 Conference, Austin, Texas, USA, Oct 1995 (Eds. Sutherland et al) (Springer-Verlag, London) pp 77-86. ISBN 3-540-76096-2.

[Ramackers 1996] Ramackers, G . “Business Process Re-engineering with Extended Use Cases and Business Objects” in the Object World ’96 UK Conference, June 1996, London.

[Rapley 1996] Rapley K. “British Airways Travel Shops System” in the DSDM European Conference, 27^th-28^th November 1996, London, UK (Source: http://www.dsdm.org)

[Reenskaug 1996] Reenskaug, T. Working With Objects. Manning Publishing, Connecticut, USA, 1996. ISBN 0-13-452930-8.

[Reisig 1982] Reisig, W. Petri nets: An introduction. EATCS Monographs on Theoretical Computer Science, Vol. 4. Springer-Verlag, 1982. ASIN 038 71337 23 8.

[Rockart et al 1996] Rockart, J.F. “Chief Executives Define Their Own Data Need” in the Harvard Business Review, March-April 1996.

[Rolland 1996] Rolland, C. “Challenges in Object Oriented Modelling: From Conceptual Modelling to Requirements Engineering” in the OOIS’96 Conference, London, December 1996, Springer, London 1996, pp3-17. ISBN 3-540-76132-2.

[Rostal 1998] Rostal P. “From Business Objects Towards Adaptive Agents” in the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October, 1998, Vancouver, Canada. Source: http://www.jeffsutherland.org/oopsla98/rostal.html.

[Rumbaugh et al 1991] Rumbaugh J, Blaha M, Premerlani W, Eddy F and Lorensen W. Object-Oriented Modeling and Design. Prentice hall, 1991, ISBN 0-136-29841-9.

[Rumbaugh 1996] Rumbaugh, J . “The Unified Modelling Language Tutorial” in the OOPSLA’96 Conference, October 1996, San Jose, CA.

[Schmid et al 1998(a)] Schmit H, Rlebishch M, Haverhagen A, Tarly T and Lissmen H. “A Business Object Framework Architecture” in the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Source: http://www.jeffsutherland.org/oopsla98/schmid2.html.

[Schmid et al 1998(b)] Schmid H and Simonazzi F. “Business Procedures Are Not Represented Adequately in Business Applications and Frameworks” in the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Source: http://www.jeffsutherland.org/oopsla98/schmid1.html.

[Schmidt 1998] Schmidt M. “Building Workflow Business Objects” in the Proceedings of the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Springer, London 1998. ISBN 1-85233-108-9, pp 64-76.

[Schulze 1997] Schulze W. “Fitting the Workflow Management Facility into the Object Management Architecture” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’97) Business Object Design and Implementation Workshop III. October 1997, Atlanta, GA, USA. Springer, London 1998. ISBN 1-85233-108-9, pp 109-117.

[Schulze et al 1996] Schulze W, Bohm M and Meyer-Wegener M. “Services of Workflow Objects and Workflow Meta-objects in OMG-compliant Environments” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’96) Business Object Design and Implementation Workshop II. October 1996, San Jose, CA, TX, USA. Springer, London 1998. ISBN 1-85233-108-9, pp 118-125.

[Schwaber 1995] Schwaber K. “SCRUM Development Process” in the Proceedings of the Conference of Object-Oriented Programming Systems Languages Application (OOPSLA’95) Business Object Design and Implementation Workshop I. October 1995, Austin, TX, USA. Springer-Verlag, London, 1997, pp 117-134. ISBN 354060962.

[Shaw et al 1993] Shaw M et al. “Software Architecture and the tools to support it” in the Conference of Advances in Software and Knowledge Engineering [Ambrider V and Tutora G (eds)], World Scientific Publishing Co., NJ, USA. Source: http://www2.umassd.edu/Coursepages/SoftwareArchitecture/lecture/search.html

[Shelton 1996] Shelton, R et al. OMG Business Application Architecture White Paper. OMG Business Object Management Special Interest Group (BOMSIG). Sources: http://www.omg.org.

[Shlaer et al 88] Shlaer S and Mellor S.J. Object-Oriented Systems Analysis – Modeling the world in data. Yourdon Press, Eaglewood Cliff, NJ, USA (1988), ISBN 0-136-29023-X.

[Shortland et al 1997] Shortland R and Kirkham E. “DSDM for Process Re-engineering in BT Labs” in the DSDM European Conference, 17^th-18^th September 1997, Warwick, UK (Source: http://www.dsdm.org)

[Sloman 1995] Sloman A. “Making RAD a success” in the DSDM European Conference, 5^th-6^th December 1995, London, UK (Source: http://www.dsdm.org)

[Somerville 1989} Somerville I. Software Engineering. Addison-Wesley, 1989 (3^rd Edition).

[Spottiwoode 1998] Spottiwoode C. “Ride the Mainstream! With MACK Business Object” in the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Source: http://www.jeffsutherland.org/oopsla98/spottiswoode.html.

[Spottiwoode 1996] SPOTIWOOD, C. “The Emperor’s New Clothes” in the OOPSLA’96 Conference Business Objects Design & Implementation Workshop II”, 5-9 October 1996, San Jose, CA, USA (Source: (http://www.tiac.net/users/jsuth/).

[SSA 1997] SSA INC. “Business Object Facility Submission” in the Object Management Group’s Request For Proposal-4. Source: http://www.omg.org.

[Stapleton 1997] Stapleton, J. Dynamic Systems Development Method The Method in Practice. (First Edition). Addison Wesley Longman, Harlow, UK. ISBN 0-201-17889-3.

[Sutherland 1998] Sutherland J. “Business Object Component architecture: A Target Application Area for Complex Adaptive Systems Research” in the Proceedings of the OOPSLA’98 Conference Business Object Design and Implementation Workshop, 18^th-22^nd October 1998, Vancouver, Canada. Springer, London 1998. ISBN 1-85233-108-9, pp 156-166.

[Sutherland 1995 (a)] Sutherland, J et al. OOPSLA’95 Business Object Design and Implementation Proceedings, 1996, Springer, London, ISBN 3-540-76096-2.

[Sutherland 1995 (b)] Sutherland J, “The Object Technology Architecture: Business Objects For Corporate Information Systems” in the 1995 Symposium for VMARK Users, Albuquerque, USA, 1995 (http://www.tiac.net/users/jsuth/).

[Sutherland 1995(c)] Sutherland, J. “Capturing Business Object Benefits in Corporate Information Systems” in the IPP Interoperability Symposium, Brown University, N.Y. Sources: http://www.mpgfk.tu-dresden.de/~weise/docs/ippbrown.html.

[Swords et al 1997] Swords D and Turner I. Strategy from the Inside Out (Self-Development for Managers, 1997 (International Thomson Business Press), ISBN 1861521928

[Tagg et al 1992] Tagg R and Liew B (1992). “Object-Oriented Database Methodology – State of the Art” in the “Lecture Notes for the School of Mathematical and Information Sciences”, Massey University, Palmerston North, New Zealand. (Source: http://www.massay.ac.nz/~cs/tagg.html ).

[Taylor 1995] Taylor P. “Rapid Delivery in BT” in the DSDM European Conference, 5^th-6^th December 1995, London, UK (Source: http://www.dsdm.org)

[Thome 1993] Thome, B. Systems Engineering – Principles and Practice of Computer-Based Systems Engineering. John Wiley & Sons, NY., 1993. ISBN 047 1935522.

[Thomson 1996] Thomson D. “Experiences of DSDM in Shell Expro” in the DSDM European Conference, 27^th-28^th November 1996, London, UK (Source: http://www.dsdm.org)

[TRC 1997] Technical Resource Connection Inc. “Common Business Objects Submission” in the Object Management Group’s Request For Proposal-4. Source: http://www.omg.org.

[White et al 1997] White S et al. “Architecture Reuse through a Domain Specific Language Generator” in the Fourth International Conference on Software Reuse, April 1996, Toronto, Canada. Source: http://www.umcs.maine.edu/~ftp/wisr/wisr8/papers/WhiteS/WhiteS.html

Appendix A : Bibliography

Booch, G. (1994). Object-Oriented Analysis and Design. Second Edition, Benjamin-Cummings Publishing Company, Inc. ISBN 0-805-35340-2.

Bowman, C and Asch, D (1996). Managing Strategy, Macmillan Press, London. ISBN 0-333-60888-7.

Coad, P., and Yourdon, E. (1991). Object-Oriented Analysis. Second Edition, Prentice-Hall International. ISBN 0-136-29981-4 .

Cottrel, N., and Rapley, K. (1991). Factors critical to the success of executive information systems in British Airways. European Journal of Information Systems. Vol. 1, Issue 1, pp 65-71.

Fowler, M (1997). Analysis Patterns: Reusable Object Models. First Edition. Addison-Wesley, CA. ISBN 0-201-89542-0.

Fowler, M and Scott, K (1997). UML Distilled Applying the Standard Object Modeling Language. (First Edition). Addison-Wesley, Massachusetts. ISBN 0-201-32563-2.

Gamma, E., Helm, R., Johnson, R and Vlissides, J (1995). Design Patterns: Elements of Reusable Object-oriented Software. (Eleventh Edition). Addison Wesley Longman, Inc., Massachusetts. ISBN 0-201-63361-2.

Graham, I (1995). Migrating to Object Technology. First Edition. Addison-Wesley Publishers Ltd. ISBN 0-201-59389-0.

Graham, I. (1994). Object-Oriented Methods. Second Edition. Addison-Wesley Publishers Ltd. ISBN 0-201-59371-8.

Graham, I., Henderson-Sellers, B. and Younessi, H (1997). The OPEN Process Specification. (First Edition). Addison-Wesley, NY. ISBN 0-201-33133-0.

Hammer, M and Champy, J (1995). Reengineering The Corporation A Manifesto for Business Revolution. (Ninth Edition). Nicholas Brealey Publishing, London. ISBN 1-85788-056-0.

Henderson-Sellers B, Simons A and Younessi, H (1998). The OPEN Toolbox of Techniques (First Edition). Addison-Wesley, NY. ISBN 0-201-33134-9.

Jacobson I, Griss M and Jonsson P (1997). Software Reuse – Architecture, Process and Organisation for Business Success (First Edition). Addison-Wesley Longman. ISBN 0-201-92476-5.

Jacobson, I., Griss, M., Jonsson, P (1997). Software Reuse Architecture Process and Organisation for Business Success. (First Edition). ACM Press, NY / Addison Wesley Longman, Massachusetts. ISBN 0-201-92476-5.

McGibbon, B (1995). Managing Your Move to Object Technology Guidelines and Strategies for a Smooth Transition. (First Edition). SIGS Books, NY. ISBN 0-13-242009-0.

Mowbray T and Malveau R (1997). CORBA Design Patterns. First Edition. John Wiley & Sons, Inc., NY. ISBN 0-471-15882-8.

Partridge, C. (1996). Business Objects: Re-engineering for Re-use. Butterworth-Heinemann, Oxford. ISBN 0-7506-2082-X.

Perry, D.E., Staudenmayer, N.A., and Votta, L.G. (1994). People, organizations, and process improvement. IEEE Software. Vol. 11, Issue 4, pp 36-45.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. (1991). Object-Oriented Modeling and Design. Prentice-Hall. ISBN 0-136-29841-9.

Soley, R and Stone, C (1995). Object Management Architecture Guide (Third Edition). John Wiley & Sons, Inc., NY. ISBN 0-471-14193-3.

Steels, L. (1994). Beyond objects. Proceedings of the Eighth European Conference on Object-Oriented Programming, Tokoro, M., and Pareschi, R. (editors), Bologna, Italy, pp.3-11.

Taylor, D (1995). Business Engineering With Object Technology. (First Edition). John Wiley & Sons, Inc., NY. ISBN 0-471-04521-7.

Taylor, D (1995). Object-Oriented Technology: A Manager’s Guide.(Thirteen Edition). Addison-Wesley, NY. ISBN 0-201-56358-4.

Walden, K. and Nerson, J.-M. (1995). Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems. Prentice Hall International (UK) Ltd. ISBN 0-130-31303-3.

Yourdon, E. (1993). A natural productivity in object-orientation. In Software Engineering Productivity Handbook. Keyes, J. (editor), Windcrest/McGraw-Hill, pp.97-117. ISBN 0-079-11366-4.

Appendix B: A Survey of Business Objects

Questionnaire

Dear OOPSLA’97 delegates,

I am currently doing my PhD research in Business Objects and would like to collect information from both the I.T. developers and the Business End-users. Your comments and feedback are very important to my research. Please take a few moments to complete this questionnaire and your kind effort is greatly appreciated. Thank you.

Kitty Hung

PhD Scholar

School of Computing, Information Systems & Mathematics

South Bank University, London

Email: hungks@sbu.ac.uk

Have you ever heard of Business Objects?

A r Yes

B r No

If the answer is yes in Q1, how long have you heard of Business Objects?

A r Less than 6 months

B r 1 – 2 years

C r More than 2 years

Where did you hear from Business Objects?

A r Conferences & Seminars

B r Research Papers / Journals

C r Advertisements on magazines

D r Direct marketing from Vendors

Have you started to use Business Objects in your organisation?

A r Yes

B r No

If your answer is Yes in Q4, how long have you started?

A r Less than 6 months

B r 1 – 2 years

C r More than 2 years

If your answer is No in Q4, will you plan to use Business Objects in the future?

A r No

B r Yes, within a year

C r Yes, but after a year

D r Not sure

If you are currently using Business Objects, are you using any CASE Tools to support?

A r Yes

B r No

If you are already using Business Objects, did you:

A r buy the Business Objects off the shelf

B r develop the Business Objects in-house

C r both

What projects are you adopting Business Objects?

A r Mission Critical

B r Non-Mission Critical

If you are using Business Objects in your projects, did you find your systems:

A r Improved in a great deal

B r Slightly improved

C r No change

D r Worst than before

Do you agree with the standardisation of Business Objects?

A r Yes

B r No

C r Neutral

Any reasons make you adopt Business Objects? (Tick any boxes appropriate)

A r Enhance reuse

B r IT developers will understanding business requirements better

C r Cost saving

D r Improve software quality

E r Easier to maintain

F r Influence by the Software Vendors

G r No particular reason, just try out something new

H r Any other reasons _____________

______________________________

What are the main obstacles you are facing in using Business Objects? (Tick any boxes appropriate)

A r Lack of standard

B r Shortage of skilled professionals

C r Steep learning curve

D r Technology not mature

E r Return on investment not justified

F r Rely too much on CASE tools support

G r Any other reasons____________

______________________________

If you are already using Business Objects, will you continue to use them in future?

A r Yes

B r No. Why? _________________

_____________________________

What is the nature of your organisation?

A r Software Vendor

B r Hardware Vendor

C r Consultancy

D r Business Users

D r Research and Development

F r Educational / Academic

How many employees in your organisation?

A r Under 50

B r 50-100

C r 100-500

D r 500-1,000

E r More than 1,000

What is your organisation’s annual revenue?

A r Under US$1,000,000

B r US$1,000,000-5,000,000

C r US$5,000,000-9,000,000

D r US$10,000,000-49,999,999

E r US$50,000,000-99,999,999

F r Over US$100,000,000

Your name: ________________

___________________________

Your Position: ______________

___________________________

Your company: _____________

___________________________

Your country: ______________

___________________________

22 Your email: ________________

___________________________

Appendix C: Results of the Survey of

Business Objects

Result Summary: Over 2/3 of respondents had heard of Business Objects

Although the response to the first question: “Have you ever heard of Business Objects?” is quite encouraging with 72% answering yes and only 27% answering no, some respondents still do not understand what BOs really mean. Extra comments from respondents were: “What is a Business Object? Until we have a good answer to that, we won’t be using them. We know of commercial availability but if we do not know what a Business Objects is, how can we tell if there are any?” “If you mean a particular tool called Business Objects, then ignore this form because I’ve never heard of it. If you mean analysis objects that correspond to real world objects, this counts.”

Result Summary: The growth rate is falling (growth rate is slower than the average growth rate)

In question 2, when asked: “If your answer is yes in question 1, how long have your heard of Business Objects?” Half of the respondents (51%) said they have heard about Business Objects for more than 2 years, 37% said between one and two years and only 12% said less than 6 months.

This above figure is quite alarming. It can be seen that the number of new BO adopters is falling. However one might argue that the 51% is the accumulation of years of adoption and it is quite natural that the growth rate is progressive year by year. Even so, the growth rate seems to be slower than average growth rate.

Result Summary: Half of the resources came from Research Paper / Journal and Conferences / Seminars

Question 3 asked the respondents: “Where did you hear about Business Objects?” 29% was from research papers / journals, 22% from conferences & seminars, 10% from advertisements in magazines, 6% from Direct Marketing, 7% from other source. 28% of the respondents did not answer this question.

The above figure shows that the sources of information for BOs are mainly available through conferences and journals where topics still under research are mostly discussed. Unlike conferences and journals, the advertisement and direct marketing media usually promote commercial products and tools. Such phenomenon has indicated that BOs are more academic driven with more of a concept under research rather than a ‘commercial-product-off-the-shelf.

Result Summary: Only one-third of the respondents had started using Business Objects

Question 4 asked: “Have you started using Business Objects in your organisation?” 39% answered yes and 36% answered no. Although the numbers are very close to each other, 25% of the respondents did not answer this question. Overall, only one-third of the respondents said they had started using BOs development.

Result Summary: Number of new adopters was falling which might cause potential threat to future

In question 5, when asked: “If your answer is yes in question 4, how long have you been using Business Objects?” 19% answered more than 2 years, 15% answered 1 – 2 years and 5% answered less than 6 months. 61% of the respondents did not answer this question. Looking at the period of usage, nearly half of the organisations have been using Business Objects for more than two years. However as stated above, the number of new adopters is actually declining with 5% less than six months compared to 10% more than two years. This has posed a potential threat to the future development of Business Object.

Result Summary: Less than 1/3 had a definite plan to start using Business Objects

Question 6 asked: “If your answer is no is question 4, will you plan to use Business Objects in the future?” 23% answered yes and within a year, 9% answered yes but after a year, 18% answered no and 50% said not sure.

The result is quite disappointing with less than one-third of the respondents have a definite plan to start using Business Objects. The 50% of the respondents who were not sure have reflected the lack of confidence about the concept and maturity of the technology.

Result Summary: Huge expenses on purchase, consultancy and training of CASE tools have discouraged use of Business Objects, as it is hard to justify the return on investment

Question 7 asked: “If you are currently using Business Objects, are you using any CASE tools to support them?” 53% answered yes.

Some of the respondents expressed that their reliance on CASE tool support has become inevitable due to the complexity of Business Objects. This also means that organisations have to spend more on purchase, consultancy and staff training for CASE tools. Such investment has discouraged some organisations from adopting Business Objects, as they are not sure how long it will be before they can see the return on their investment.

Result Summary: Different standards of BOs make it highly unlikely to integrate. Therefore, difficult to reuse

Question 8 asked: “If you are already using Business Objects, did you buy the Business Objects off-the-shelf? Or did you develop the Business Objects in-house? Or both?” 75% developed Business Objects in-house with only 3% buying the Business Objects off-the-shelf. 22% responded both. Some respondents expressed the difficulty in locating the commercial packaged Business Objects suitable for their needs, as there are too few options. Even when available, they find that the price is too high.

For these reasons, they considered that the “do-it-yourself” one is more economical and appropriate to their requirements. This has created a situation that in every organisation; people just get together and create their own Business Objects for their organisation. Then, different organisations have different ways of developing Business Objects which are highly unlikely to integrate with another organisation’s Business Objects. This situation has not only discouraged reuse but also has made the interpretation of BOs very inconsistent amongst business organisations across the domain [9]. Currently there is still a lack of industrial standard for Business Objects.

Result Summary: Nearly 1/3 had confidence in using Business Objects in mission critical projects

Question 9 asked: “In what projects are you adopting Business Objects?” 64% said they already use Business Objects in their mission critical projects and only 36% use in non-mission critical projects. The result is quite enlightening. At least nearly two-third of the respondents feel that BOs can handle important projects.

Result Summary: Nearly 2/3 said the systems had improved a great deal

Question 10 asked: “If you are using Business Objects in your projects, did you find that the impact on your systems was: “No change?” “Or slightly improved?” “Or improved by a great deal?” “Or worse than before?” 60% said Business Objects have improved in systems by a great deal while only 2% overall said the systems are worse than before. So overall, the comments from people are satisfactory.

Result Summary: Nearly half were not sure what the benefits would bring from standardisation

Question 11 asked: “Do you agree with the standardisation of Business Objects?” 32% said yes, 7% said no and 7% said neutral. However 44% of the respondents did not answer this question. It appears that many of them are not sure what the benefits will bring from standardisation. The ultimate goal of OMG’s BODTF is to standardise the Business Objects as a uniformity measurement towards both the quantitative and qualitative values. To achieve this goal, the BODTF must win more people’s appreciation and support on standardisation.

Result Summary: Business Objects move closer to the business world

Question 12 asked: “What reasons make you adopt Business Objects?” 19% said BOs enhance reuse, 13% said IT developers will understand the business better, 16% believed that Business Objects will improve software quality, 15% reckoned that
systems will be easier to maintain and 11% thought that it will be cost saving. Other reasons include: “increase direct participation of domain experts”, “greater capability”, “reduce development time”, “better design”, “convenient place to put information for display”, “currently developing corporate engineering application architecture for future, mental hygiene”, “we sell them”, “business analysts will understand software better”, “support enterprise-scale architectures”, “closer to real world model”, “Commercial-Off-The-Shelf (COTS) vendor products have Business Objects and Sales Objects”, “faster development”, “shorten learning curve”, “better interface”.

Result Summary: Technology of Business Object not mature yet

Question 13 asked: “What are the main obstacles you are facing in using Business Objects?” Not surprisingly, 18% of the respondents found that there are shortages of skilled professionals who know how to use or develop Business Objects. 17% respondents found that the technology not mature. 12% said there is a lack of standard to follow. 7% said learning curve is steep. 2% said the return on investment not justified. 1% said relying too much on CASE tools to support BOs constitutes a problem. 37% of the respondents did not answer this question.

The above result is interesting because it is co-incidental to question 7 where 53% of the respondents Use Case tools to support their development of Business Objects. Out of this figure, there was only 1% of the respondents saying that relying too much on CASE tools to support. This indicates that there is a big potential in the CASE tools market to support Business Objects.

Other reasons include: “performance impact uncertainties”, “lack of funding”, “implementation to diverse systems”, “building and deploying quickly”, “management do not understand”, “management ignorance”, “what are Business Objects? any description?”, “need to educate organisations”, “lack of understanding of business domain”, “unfamiliar”, “applicability to engineering applications unknown”, “management lack of understanding in reading the written materials from software engineers”, “very hard to get business domain aware developers”, “management buy off”, “problems in understanding real business needs / requirements”, “process methodology support vs. vendor COTS”, “problems we have is that the Business Objects is not the natural way we do business and consequently IS is routine the business comments into a computer section”, “initially – steep learning curve after learning it is shorter”, “skill level of the developers is varied”.

Result Summary: Only one-third felt any degree of certainty

Question 14 asked: “If you are already using Business Objects, will you continue to use them in the future?” 36% said yes but the 64% of the respondents did not answer this question. This has reflected that most respondents are still in the “Trial-and-Test” stage. They did not have long term investment plans or strategies for the future adoption of Business Objects. Only one-third of the respondents felt any degree of certainty.

Result Summary: One-third of respondents were business users and half were IT professionals

Question 15 asked: “What is the nature of your organisation?” 18% are software vendors, 5% are hardware vendors, 15% are in consultancy, 32% are business users, 2% are in research and development, 2% are from educational / academic sectors, 28% did not answer this question.

Result Summary: Nearly half of respondents were from organisations with 1,000+ employees

Question 16 asked: “How many employees are there in your organisation?” 42% came from large organisations with more than 1,000 employees, 4% came from medium-to-large firms, 11% came from medium firms with 100-500 employees, 3% came from small-to-medium firms with 50-100 employees, 11% came from small firms with less than 50 employees. 29% of the respondents did not answer this question.

Result Summary: One-third were major industrial players playing influential role in the software advancement

Question 17 asked: “What is your organisation’s annual revenue?” 33% of the respondents said over US$100 million, 4% said between US$50 million and US$100 million, 10% said between US$10 million and US$50 million, 1% said between US$5 million and US$10 million, 5% said between US$1 million and US$5 million and 5% said under US$1 million. 42% of the respondents did not answer this question due to commercial confidentiality.

In view of questions 16 and 17, the majority of respondents work for large organisations employing more than 1,000 people with more than US$100 million annual revenue. We are confident that this survey reflects the viewpoint of several major industrial players where they play a relatively influential role in the advancement of software technology.

Appendix D: Invitation for SMP Interview

Memorandum CAD Consultants Ltd.

797 London Road, Thornton Heath, Surrey, CR7 6AW Tel : 0181 683 0141 Fax : 0181 665 5647

To:	Mike Bull Peter Maybury David Bull Robert Crampton	Kevin Andrew Paul Battams Veronica Williams
From:	Kitty Hung
Date:	3^rd March 1998		Page(s) : 1
Subject:	Strategic Management Planning – Invitation for Interview Thursday, 17^th March 1998

Dear CAD Management Team,

As you may know that I am currently writing up my PhD thesis entitled “A Dynamic Business Object Architecture for supporting Strategic Management Planning”. The aim of the research is to develop a novel approach to assist organisations to implement their business strategies.

In order for me to demonstrate this approach, I need to conduct some case studies from business organisations. CAD, being my PhD sponsoring company, is certainly on the top of my selected list. For this, I wish to conduct a short interview with each of you individually and I sincerely hope that you would spare 20-30 minutes for me on that day to discuss the following issues with you such as:-

Strengths and weaknesses of the organisation;
Long- and short-term business challenges;
Market competitiveness;
Product and customer services;
Human resources issues;
The use of technology within CAD

I will come around to your desk on that day to have a chat with you. Thank you very much in advance for your kind assistance in this matter and I look forward to chatting with you on the 17^th March.

With kind regards,

Kitty Hung

Appendix E: Results of the SMP Interview

Strategic Management Planning Questionnaire

~ For CAD Consultants Ltd.’s Management Team ~

Interviewee : Mike Bull

Position : Managing Director

Length of service : Since 1976

PART A : GENERAL

A1. What do you think the main strengths and weaknesses in your organisation?

Strengths: Knowledge in credit insurance / innovator of most financial engineering

Products / business expertise in financial and risk management / strong customer

based within the BTR plc Group / High autonomy of management Style

Weaknesses: skill shortage in credit insurance / difficulty in management succession /

Hard to find replacement when staff leave.

A2. From your organisation’s point of view, what long- and short-term challenges are you facing?

Short-term challenges: Facilitation of self-growth with the BTR plc group /

getting BTR’s subsidiaries (i.e. CAD’s customers) to accept changes on

financial engineering innovation products and services as well as new technology

and new concepts / staff training on skills on new products & services / develop

South American market in 1999.

Long-term challenges: Globalisation of business particularly in Asia Pacific regions

/ world economic slowdown / Asian economic recession / human barrier (external

customers and internal staff) / getting acceptance of change in financial & credit

insurance from customers and staff members / cannot determine business direction

unless BTR’s buying and selling are in place / need to switch decision very quickly

in response to the changes.

A3. What are your organisation’s aims and objectives?

Aims: Grow to a more dynamic organisation with more innovative new products

& services.

Objectives: To get customer’s acceptance and take up new products & services / to

get internal staff to accept and train on the new services & products / to maintain

profit, self-growth and professionalism.

PART B: SERVICES / PRODUCTS

B1. What factors do you take into consideration when improving your products / services?

The products / services must protect our customer to minimise risk / To cater different

aspects of Customers’ needs / To provide services to customer at any time in any region.

PART C : COMPETITIVENESS

C1. What do you consider to be the most important factor(s) in maintaining your market position?

To ensure “safe guarding” of our customers’ major assets (receivables) /

To obtain confidence from customers that whatever we introduce, we are

helping customers’ growth in sales volume and profit line

C2. What kind of competition is your organisation facing?

Alternative products such as L/Cs / Similar services provided by other credit

Insurance brokers, agents and underwriters

C3. Who are your competitors? Where are they? What are their sizes?

Name of your competitors: Credit Insurance Brokers, Agents, Underwriters and

Insurance Policy Managers etc.

Where are your competitors: Global

What are their sizes: The Credit Insurance Brokers, Agents and Policy Managers are

Usually smaller than CAD but the Credit Insurance Underwriter such as NCM,

Trade Indemnity and AON are much bigger than we are.

PART D: CUSTOMERS

D1. What is your perception of the relationship between CAD and its customers?

I’m not satisfied with the current relationship with our customer especially we

receive a lot of complaints from our European customers. We need to improve

the customer relationship in terms of quality of our products (i.e. to be able to

minimise trading risk) and the availability of information to customers (i.e. risk

management information, buyers’ track records, country risks etc.)

PART E: HUMAN RESOURCES

E1. What is your personal experience in working at CAD?

I am happy to be the MD of CAD. I have good relationship with my peers within the

BTR group although I do find my job challenging because of all the changes in

Business and staff movement etc. Most of the time, the work pressure is manageable.

I am also happy with my remuneration package. However, I do have problems with

some of my staff members. Some of them are very reluctant to accept the change of

business and to learn the new products and services. I’ve also found that there is a

lack of communication amongst our staff member with one and another. I do want

to change the situation from Figure 1 to Figure 2.

It is very important to improve the communication amongst staff. I believe in ‘team spirit’ will improve business performance and quality of services. However, I know it

is so easy to change the company but to change the people or to get them to change is so difficult.

PART F: TECHNOLOGY

F1. What role do you think the technology plays within CAD? And what do you suggest to change? And what are your reasons for change?

Technology role: : Technology plays a crucial role within CAD. Our products are

our services and all our business transactions are conducted though the computer system. If the computer system is down, virtually no transactions can be carried and the business will come to a halt.

Suggestions to change: Our services must not only available to UK or Europe

Only. We should enable our customers to use our services from anywhere at any time. We should also use the technology to improve the speed of our services

Reasons to change: We aim at globalisation of our services. Therefore, the computer

system should support us to do so.

Strategic Management Planning Questionnaire

~ For CAD Consultants Ltd.’s Management Team ~

Interviewee : Peter Maybury___

Position : Operations Director

Length of service : Since 1976

PART A : GENERAL

A1. What do you think the main strengths and weaknesses in your organisation?

Strengths: People / Experience / Expertise / IT awareness / Progressive

Weaknesses: Lack of language skills (French, German, Italian, and Scandinavian) /

Global awareness in terms of market situation / reluctant to change amongst some

employees such as learning the new ways of doing things and learning new skills

etc. / Solely relying on 2 Credit Insurance Underwriters (AON and NCM) to supply policies to us, we need to identify marketing resources from other avenues

A2. From your organisation’s point of view, what long- and short-term challenges are you facing?

Short-term challenges: Customer relations in mainland Europe, North America and

South America / Staff development / Customer Finance (a new product from CAD)

/ growing the business / Internet business transaction / cross training between credit

management team and Business Managers (integration of audit and business

management).

Long-term challenges: Customer relations in Asia-Pacific region / Harnessing

Different credit insurers / Finding alternative sources of insurance & finance suppliers

(at the moment, we are too reliant on proprietary suppliers) / Launching new products

(probably allied to risk management)

A3. What are your organisation’s aims and objectives?

Aims: Growth in terms of reputation, size and profitability evenly

Objectives: To have all customers world-wide in regular contact / trading with US

PART B: SERVICES / PRODUCTS

B1. What factors do you take into consideration when improving your products / services?

Customer satisfaction / Pricing / Income & profit / Overall benefits to BTR plc &

External customers / speed / efficiency / quality etc.

PART C : COMPETITIVENESS

C1. What do you consider to be the most important factor(s) in maintaining your market position?

To sustain customer relations / quality of services

C2. What kind of competition is your organisation facing?

No longer a “Captive” business / Open to competition from any credit related service

providers

C3. Who are your competitors? Where are they? What are their sizes?

Name of your competitors: Trade Indemnity Credit Insurance Underwriter / Other

Credit Insurance Brokers and Agents / Other credit Insurance Underwriters

Where are your competitors: Global

What are their sizes: Trade Indemnity is bigger but other credit insurance brokers and

agents should be smaller than CAD

PART D: CUSTOMERS

D1. What is your perception of the relationship between CAD and its customers?

Variable between very good and poor. We have problems with our

European customers. Our UK and North American customers seem to be happy

with us. We need to improve European customer relationship. We could

provide much better services than we are Currently providing.

PART E: HUMAN RESOURCES

E1. What is your personal experience in working at CAD?

Personally I found myself facing a lot staff and personnel problems. My staff retention has been a frequent problem (in cycles) throughout my 20 years with CAD. Although the problem seems to have improved a bit recently, generally too few people have “carried” the company. In other words, there is a lack of empowerment and delegation within the company. When there are problems no matter big or small subordinate staff or middle management staff will just refer the problems upward to senior management. My workload is huge but I have managed to cope with the pressure. My work relationship with other colleagues at the company is various – OK with management team but . sometimes I’ve found myself too busy in communicating with people particularly with the subordinate staff.

PART F: TECHNOLOGY

F1. What role do you think the technology plays within CAD? And what do you suggest to change? And what are your reasons for change?

Technology role: Technology plays vital role that we remain at the forefront of

Technological advances (where clear benefits can be identified)

Suggestions to change: external communication with our suppliers and customers via

the Internet and Intranet technology

Reasons to change: Major benefits can be gained through changes such as improve

Communications / reduced working practice and paperflow document /

improved access to information and sharing of product development which is

applicable to both internal staff and external customers, both will be better informed.

Strategic Management Planning Questionnaire

~ For CAD Consultants Ltd.’s Management Team ~

Interviewee : Robert Crampton

Position : Commercial Manager

Length of service : Since 1997

PART A : GENERAL

A1. What do you think the main strengths and weaknesses in your organisation?

Strengths: Industry knowledge / bargaining power / competitive pricing / network of

Contacts, globalisation.

Weaknesses: Reliance on third parties i.e. the insurer services, perception of the

industry still conservative i.e., hard to sell the idea of credit insurance to people.

This is also applicable to our competitors.

A2. From your organisation’s point of view, what long- and short-term challenges are you facing?

Short-term challenges: Retaining non-BTR customers after the sell-offs / business

Growth, credit management team’s consolidating structural changes / Deteriorating global circumstances (both economical and political)

Long-term challenges: Technological advancement / New product development

A3. What are your organisation’s aims and objectives?

Aims: To provide all BTR units as well as external customers with tools and advice

they need to grow their business

Objectives: To provide quality trade financial services to our customers

PART B: SERVICES / PRODUCTS

B1. What factors do you take into consideration when improving your products / services?

Customer needs / availability of products / competitive pricing

PART C : COMPETITIVENESS

C1. What do you consider to be the most important factor(s) in maintaining your market position?

Cost and quality of service

C2. What kind of competition is your organisation facing?

‘Ignorance’ : i.e. the lack of knowledge and understanding of our products and services / ‘banks’ : as they provide letters of credit as an alternative option of credit insurance

C3. Who are your competitors? Where are they? What are their sizes?

Name of your competitors: _____________________________________________

___________________________________________________________________

Where are your competitors: ___________________________________________

___________________________________________________________________

What are their sizes: __________________________________________________

___________________________________________________________________

PART D: CUSTOMERS

D1. What is your perception of the relationship between CAD and its customers?

I think overall we have good customer relationship with existing customers but I’ve found it difficult to penetrate new market and to establish relationship with potential

customers. Once potential customers have accepted the idea and use us, the

maintenance of customer relationship is easy.

PART E: HUMAN RESOURCES

E1. What is your personal experience in working at CAD?

I am happy in working at CAD. I can cope with my work pressure and my working

relationship with my colleagues is fine.

PART F: TECHNOLOGY

F1. What role do you think the technology plays within CAD? And what do you suggest to change? And what are your reasons for change?

Technology role: : Critical as information supplied all held in the IT system / heavily

Rely on computer system

Suggestions to change: Speed – the system is too slow

Reasons to change: Save time and save cost if the business transactions can be conducted in a timely fashion.

Strategic Management Planning Questionnaire

~ For CAD Consultants Ltd.’s Management Team ~

Interviewee : Kevin Andrew___

Position : Business Manager

Length of Service : Since 1980

PART A : GENERAL

A1. What do you think the main strengths and weaknesses in your organisation?

Strengths: High profile within the BTR group / Matured management skills / Our type

of industry is unique in both BTR group and UK / Long standing relationship with

suppliers.

Weaknesses: Lack of cover in staff absenteeism / Small size not enough resources

in terms of human and finance and material

A2. From your organisation’s point of view, what long- and short-term challenges are you facing?

Short-term challenges: BTR’s ever changes of business acquisitions and disposals of subsidiaries. We have to change our direction quickly in response to the changes

Long-term challenges: Finding and developing new products, which are more diversified and versatile to cater wider spectrum of clientele.

A3. What are your organisation’s aims and objectives?

Aims: Grow the organisation in business volume, profitability and recognition.

Objectives: Do more marketing and business development / improve quality of service / improve staff standard / improve company welfare to staff in terms of financial reward and other incentives

PART B: SERVICES / PRODUCTS

B1. What factors do you take into consideration when improving your products / services?

Cost effectiveness / speed

PART C : COMPETITIVENESS

C1. What do you consider to be the most important factor(s) in maintaining your market position?

Competitive pricing / Quality of service

C2. What kind of competition is your organisation facing?

Alternative risk minimisation options such as Letters of Credit or advanced payment

C3. Who are your competitors? Where are they? What are their sizes?

Name of your competitors: NCM (Underwriters), Trade Indemnity (Underwriters),

AON (broker)

Where are your competitors: World-wide

What are their sizes: larger than CAD

PART D: CUSTOMERS

D1. What is your perception of the relationship between CAD and its customers?

Not good especially in European region outside UK. Probably because of the

Language skill shortage within CAD to serve European customers in different

European languages.

PART E: HUMAN RESOURCES

E1. What is your personal experience in working at CAD?

My personal experience working in CAD is good. However, during my 18 years

service with the company, there is not any training of personal development course

especially for management staff. There have been some credit insurance ,

time management, languages and legal knowledge training for general staff but

not enough. The general staff situation doesn’t look good at the moment. I

suggest the company should have the incentive scheme for staff member to

raise the staff morale and loyalty. Staff training especially in this unique area of

credit insurance and trade financial service industries is badly needed. Social

functions out of office hours to enable staff members get together in a relaxed

environment would also improve the relationship amongst staff thus would

eventually contribute to the company. Communication amongst staff in both

formal and informal ways must improve.

PART F: TECHNOLOGY

F1. What role do you think the technology plays within CAD? And what do you suggest to change? And what are your reasons for change?

Technology role: :very crucial

Suggestions to change: I want to have a system, which can easily generate

various reports to provide customers accurate information and to assist me in

making business strategic decisions. At the moment, I’ve found it either hard or

even impossible to do so.

Reasons to change: Personally I am not happy with the IT system within the

organisation against the business needs and the IT department staff are not

competent in providing the support. If we cannot provide customers with accurate

risk assessment reports in a smooth and speedy way, our customers will go somewhere else.

Strategic Management Planning Questionnaire

~ For CAD Consultants Ltd.’s Management Team ~

Interviewee : Paul Battams

Position : Business Manager

Length of Service : Since 1990

PART A : GENERAL

A1. What do you think the main strengths and weaknesses in your organisation?

Strengths: CAD is a unique company engaging in a business integrated amongst

Credit insurance broker, credit insurance agent and credit insurance management /

Staff knowledge / expertise / knowledge / part of BTR plc group (a world-wide

Organisation) serving BTR units world-wide / buying power influence

Influence .

Weaknesses: lack of forward planning / ‘fire fighting’ / lack of staff training and

development

A2. From your organisation’s point of view, what long- and short-term challenges are you facing?

Short-term challenges: BTR’s sell-offs – have to retain disposed units’ credit insurance business.

Long-term challenges: develop products for clients’ needs / to retain external business

ongoing / to develop new markets and products.

A3. What are your organisation’s aims and objectives?

Aims: to maximise profit / to increase turnover / to be a leader in the player in credit

insurance agent field

Objectives: to develop an all round company that can provide financial advice and

Guidance for BTR worldwide as well as external customers.

PART B: SERVICES / PRODUCTS

B1. What factors do you take into consideration when improving your products / services?

Product knowledge / product trend / market awareness in terms of customisation

or tailoring / availability in dealing with clients’ queries / constantly reviewing

internal procedures

PART C : COMPETITIVENESS

C1. What do you consider to be the most important factor(s) in maintaining your market position?

Flexibility / cost effectiveness / service / friendliness / approachability / professionalism

C2. What kind of competition is your organisation facing?

Alternative services / products available from other sources to provide insurance.

C3. Who are your competitors? Where are they? What are their sizes?

Name of your competitors: Other insurers / brokers / agents

Where are your competitors: Global

What are their sizes: Insurers are big but most insurance brokers and agents are small

PART D: CUSTOMERS

D1. What is your perception of the relationship between CAD and its customers?

Very good in my area with my UK customers. 80% of the disposed subsidiaries from

the BTR’s sell-offs retain our service

PART E: HUMAN RESOURCES

E1. What is your personal experience in working at CAD?

Personally I am happy with my job. Although my job is demanding and busy,

I’ve got good job satisfaction when I can see end results and have met objectives.

However, I can see problems in some other staff’s situation. The company needs

to ensure to get the right type of staff to perform suitable skills. There is also a lack

of financial reward and motivation within the company. Staff training is badly

needed to train existing staff in order to cope with the departure of staff problems so

staff can perform efficiently. Avoid to add pressure on staff. Communication

is important amongst subordinate and management staff. Company should also

define objectives not only to the management staff but also all the staff.

PART F: TECHNOLOGY

F1. What role do you think the technology plays within CAD? And what do you suggest to change? And what are your reasons for change?

Technology role: IT is a must. If system is down, business will stop immediately

Suggestions to change: I am not happy with the overall standard of IT system.

Everything should change – software, hardware, printer, etc. System should be

upgraded to more user-friendly and higher speed.

Reasons to change: The system is too slow and incapable. It does not satisfy my

needs and I’ve found that I have wasted a lot of time in waiting for the screen to

change and waiting for a report to be printed out from the printer.

Strategic Management Planning Questionnaire

~ For CAD Consultants Ltd.’s Management Team ~

Interviewee : Veronica Williams__

Position : Financial Controller

Length of Service : Since 1996

PART A : GENERAL

A1. What do you think the main strengths and weaknesses in your organisation?

Strengths: I am at the at the accounts department dealing with figures only. I do not

know the strength of our organisation. I can only tell you that from the accounting_

point of view, our books are in black. We are a profitable company. We do not owe

people money._

Weaknesses: _As Mike Bull always says, we do not make enough profit. He always

wants to make more profit.

A2. From your organisation’s point of view, what long- and short-term challenges are you facing?

Short-term challenges: _The fate of BTR group. If they exist we exit. If they

go out of business, no matter how profitable we are, we will be gone as well.

Long-term challenges: _The ongoing disposal of BTR’s subsidiaries. When the

units are sold off, they stop using our service. We need to keep them because

I do not think we can rely only on BTR’s companies. We need external business

as well.

A3. What are your organisation’s aims and objectives?

Aims: To survive under such a stormy situation.

Objectives: _To attract more non-BTR customers so that there might have a chance

that we can become independent from BTR group.

PART B: SERVICES / PRODUCTS

B1. What factors do you take into consideration when improving your products / services? _Cost effective, meet customer’s requirement and speedy services

___________________________________________________________________

PART C : COMPETITIVENESS

C1. What do you consider to be the most important factor(s) in maintaining your market position?

_Always watch out what our competitors are doing. Always keep an eye on new__

_comers. Always have to create new idea. Keep in pace of the market trend.

Never fall behind to our competitors.