Rapid Application Development in Dynamic ... - Semantic Scholar

4 downloads 133292 Views 315KB Size Report
one of the responses has been the Rapid Application Development (RAD) ... The special project was funded by two large food companies, for whom the so ...
Rapid Application Development in Dynamic Organisations with Business Modelling A Practitioners Point of View

Alan J.J. van Beek and Hans B.F. Mulder

Victor E. van Reijswoud

Essential Action Engineers LTD. P.O. Box 58, 2280 AB Rijswijk The Netherlands

Delft University of Technology P.O. Box 356, 2600 AJ Delft The Netherlands

Abstract Nowadays market turbulence and technological developments are changing organisations and the way in which business is conducted. A quick market response supported by direct available information systems is necessary in order to act constructively. However not all information modelling methods are suitable for rapid development of information systems. As practitioners we have performed several projects based on the Rapid Application Development (RAD) methodology and advanced tools, in which RAD has proven to be a key factor in delivering the information systems within the given time frame. As businesses keep changing the products and markets, continuous application development seems inevitable. The combination of RAD and the use of standard components, such as Business Objects or Enterprise Resource Planning software, has in past times overcome this obstacle. But fundamental changes, like redefining Strategic Management objectives or Business Process Redesign (BPR) often require more than the Rapid Development of information systems. In this article we discuss a case of a dynamic organisation in which RAD and the fundamental new approach of Dynamic Essential Modelling of Organisations (DEMO) are applied.

Keywords. Business Modelling, Dynamic Essential Modelling of Organisations, Rapid Application Development

1 Introduction The rules of competition and of organisations changed in the 1980’s by two major trends: Market turbulence and IT developments [Sco91][Don94][McF83]. Many of the constraints imposed by these market forces cannot be anticipated, and thus enormous uncertainties and ambiguities arise concerning the appropriate responses to these forces. In the field of Information Systems Engineering one of the responses has been the Rapid Application Development (RAD) approach, in which high user involvement and productivity tools reduce the time-to-implementation [Mar91] and thus allowing a quick market response of the organisation, which is supported by information systems. As practitioners we have performed several projects in which the RAD methodology has proven to be a key factor in delivering the information systems within the given, tight, time frame. 1

When businesses keep changing their products and markets, continuous application development seems inevitable. Currently, the needed flexibility to overcome this problem is achieved with the combination of RAD and the use of standard components, such as Business Objects or Enterprise Resource Planning software. Fundamental changes, like redefining Strategic Management Objectives or Business Process Redesign (BPR) often require redesign and renewed implementation of information systems. From experience we hypothesise that altering the business definition and processes requires more than the flexibility that is offered by Rapid Application Development, because the margins are determined by the users in the Joint Requirement Planning rather than a verifiable model of the business. A thorough and sound understanding of the core processes in a business is needed for achieving flexibility on the level of redefining or redesigning the business. In this paper we will demonstrate, by using an extract of a larger case study, the possibilities and limitations of a RAD approach to dynamic organisations operating in turbulent markets. By introducing a business modelling approach we will show that the hypothesised limitations of the RAD approach are compensated. In section 2 we discuss the case study in which a RAD approach was followed and we conclude by elaborating on the limitations of the followed approach. In section 3 we introduce the business modelling approach DEMO, and in section 4 we will reconsider the case study and highlight the improved insights that were achieved with this approach. In section 5 we conclude with some general remarks on the advantages of using business modelling approaches in combination with rapid application development approaches in dynamic organisations.

2 Promo Results: A RAD approach In spring of 1995 Promo Results, a marketing and promotion agency of about 600 employees, started a special project with the aim to establish a new distribution channel for snacks and beverages in the Netherlands. The special project was funded by two large food companies, for whom the so called grey distribution channel promised a new market in addition to the supermarkets, wholesales and retail organisations. About 55.000 new outlets, such as gasoline stations, schools and sport clubs, were targeted for the first year. The employees of Promo Results were to visit outlets in their neighbourhood and promote the products by offering free snacks and reduced prices. The ordered products would be delivered by wholesalers within two weeks. In the promotion process the employees perform a quick inventarisation of the available products of the outlet and the presence of competing snacks and beverages. The employees would send about 1200 reports weekly, to inform the agency of their promotion activities. Other, more standard, projects of Promo Results include the demonstrating of products, such as coffee and instant meals, in supermarkets, and providing hostesses for congresses and seminars. A software house was selected to develop an information system to support this project system within three months. Because of the innovative characteristics of the project and the limited time the method of working was based on RAD. According to [Mar91] a complete RAD project consists of the following phases: (1) Requirements Planning Phase, (2) User Design Phase, (3) Construction Phase and (4) the Cut Over Phase. Due to the nature of this paper only the first two phases are discussed below. 2.1 Joint Requirements Planning During the requirements planning a Joint Requirements Planning (JRP) was performed. The attendees of the JRP session were formed by the executive owner, the JRP leader (one of the consultants of the software house), IT personnel and employees. The executive owner was a high level manager of Promo Results responsible for the project. In line with the RAD approach the most important

2

precondition was that all users, despite their role in the organisation, should have the authority to make decisions about the design of the software application. Following [Mar91] the JRP team has a common goal, and all hidden agendas must be set aside by the JRP leader. Another task of the JRP leader is to keep the team together and motivated and to reach the expected goals within the pre-set time. Most of all, the JRP leader should act as the focal point for tying together the views of management, the end users and the IT professionals. The results of the session are recorded in the repository/data model, ready to be used directly in the user design phase. In the case of Promo Results the JRP phase was concluded with the following data model (Figure 1). The data model is represented with ERD’s as proposed in [Mar91][Mar89]. From this figure, one can see that the some tables in the system have no connection with other tables. These tables have been added, after which the developers discovered that there was no need for doing so.

Figure 1 The initial data-model of Promo Results 2.2 User Design Phase In RAD the executive owner has the responsibility to review the documentation produced by the joint requirements planning phase. Before continuing with the User Design Phase, the executive owner can decide to cancel the project. He can also conclude, that the results look promising, but they need to be 3

enhanced. In this case the requirements planning is repeated partially. The User Design Phase usually consists of two things: discussion and prototyping [Mar91][Cle94][Khe96]. The User Design Phase is a period of intense interaction, in a similar manner to the JRP, between end users, IT personnel, sometimes supported by external experts, and the executive owner. [Mar91] calls these discussions the Joint Application Design (JAD). The arrangement of attendees of these sessions is a little different from the JRP. The executive owner need not be present the entire time, for this phase is to design the system at the end users level. A JAD leader should be present. Furthermore, some IT personnel (one or more) should be present to ensure that the design is good technically. A part of this task is ensuring the correctness of the used models. The project manager, that is the manager appointed to lead the project from the organisation’s point of view, should, just like the JAD leader, also be present full-time. But the key players of the JAD sessions are the end users. The results of the JAD phase consist of screen and print layouts, reports and queries, and software procedures.

Figure 2 A data-entry form for Promo Results In the case of Promo Results the JAD session resulted in the preliminary design of a system aimed at supporting a special project to establish a new distribution channel for snacks and beverages in the Netherlands. The system was built in a 4th dimension environment. This implied that the data model

4

from the JRP phase was used as a basis for writing the software procedures, and realising necessary screen layouts and user menus [Boy95]. Below we present one of these products of the JAD session of Promo Results, namely the data-entry screen in which the reports of the visit to the outlet are stored in the system (see Figure 2). This screen shows the inflexibility that was programmed in the system, for the questions are programmed in constants, rather than variables. After this phase, the application was implemented by the software house in a client server environment. Developers choose to implement each project in a different module, in this way each project had its own data-entry form, own report-screens, etc. After formal approval by the executive owner the system became operational in summer 1995. 2.3 Experienced limitations of the RAD approach in Promo Results During the first four weeks of the project the input, approximately 5000 forms, was entered in the system by several data-typists. So far, the functionality seemed to be adequate. However, the output functionality, such as reports and management information, experienced some problems. There existed some data-inconsistencies between the different projects. Due to the inexperience in the special project, the requirements for the system fell short. However, these problems were accounted to the start-up problems every automation project has. Some weeks later, the data-model, that was sufficient for the initial requirements, displayed some flaws. For instance, if Promo Results wanted to add a new attribute, field or relation to their system, a developer had to program it. Perhaps the most striking example is when Promo Results wanted to add shoe-size (as a part of the uniform) to their personnel file. Furthermore, as Promo Results accepted new projects, new modules had to be implemented, for no flexibility was added to the data-model. This worsened data-inconsistencies between different projects. Also when new articles were added to the special project, the historical data became inconsistent or incorrect. The causes for these problems are the following: 1. Lack of experience in handling the special promotion project during the JRP-phase resulted in incomplete requirements for the information system; 2. New projects could not be supported because of the approach to develop modules for each project team. Each new project had to be build in the data-model after a separate joint requirements planning. This resulted in data-inconsistencies, overlap of software functions and consequently complications in the maintenance and further development of the application; 3. Due to the fixed characteristics of the data model, changes in requirements regarding relationships and attributes could not be implemented; 4. The resulting application did not offer the needed margins for flexibility with respect to changing layouts, adding new fields and labels to objects (i.e., employees, outlets etc.). Therefore a developer was needed for every adjustment to the program, due to this lack of flexibility. These problems grew even further until the management decided to terminate contract with the software house in December 1995. Promo Results approached the system house to which the authors are affiliated to for the maintenance of the software and analysis of the current problems. On the basis of prior experiences the authors have the impression that the RAD procedure was conducted properly, a thorough and critical report and evaluation of the followed procedure is outside the scope of this paper. However, we hypothesise that the problems of Promo Results resulted from a fundamental shortcoming of RAD. Because the first two phases of RAD do not provide a structured framework for evaluating the current organisational of business process situation and the results of the workshop participants, it overlooks the possibilities to alter the organisation by automation. Therefore RAD is not able to cope with business change and creates inflexibility in the resulting system. To overcome 5

and to understand the problems in Promo Results a structured analysis of the current situation with the DEMO business modelling approach was applied.

3 Business Modelling with DEMO DEMO (Dynamic Essential Modelling of Organisations) is a cross-disciplinary theory describing and explaining the communicational dynamics of organisations, as well as an analysis method based on this theory. A relevant set of fragments describing DEMO is constituted by [Die941][Die942] [Die961] [Die962][DiM96][Reij96][ReR95]. In DEMO, the functioning of organisations is viewed from three levels: the documental, the informational and the essential level. At the documental level, an organisation is viewed as a system of actors that produce, store, transport and destroy documents. At the informational level one abstracts from the substance (i.e. documents) and focuses on the actual meaning. The organisation is observed as a system of actors that send and receive information, and perform calculations on this information in order to create derived information. At the essential level an organisation is conceptualised as a system of actors that are engaged in the executions of transactions. At the essential level the core business processes of an organisation are described. The essential transaction is a core concept in DEMO. A transaction is a pattern of activity that is performed by two actors: the Initiator and the Executor. It is important to note that actors are roles in an organisation and not persons. A transaction is composed of three phases: the Order phase in which two actors come to an agreement about the execution of some future action; the Execution phase, in which the negotiated action is executed; and the Result phase in which the actors negotiate an agreement about the result as brought about in the execution phase. The successful execution of a transaction in the Subject World (the world of communication) results in a change in the Object World (Universe of Discourse) in which the actors exist. The basic pattern of the transaction is displayed in Figure 3. agreement on objective action P

transaction status

intersubjective action

request (actor 1; initiator)

objective action P is executed

promise (actor 2; executor)

state (actor 2; executor)

declare (actor 1; initiator)

Subject world order phase

transaction phase

t1

execution phase

t2

result phase

t3

t4

time

created facts

transaction result

Object world

Figure 3 The basic pattern of the DEMO transaction The execution of an transaction in an organisation can be described and consequently modelled at all three levels of abstraction. At the essential level the transaction is described as a pattern of performative communication. At the informational level the execution of a transaction is described as the exchange of information (information flows), and at the documental level the materialisation of the transaction in tangible objects (documents, files etc.) is described. The DEMO approach

6

hypothesises that the transaction at the essential level allows multiple instantiations at the informational level and the documental level. It is important to realise that these instantiations are ideally deliberate organisational choices. The principle idea is displayed in Figure 4. The transactional structure of an organisation in modelled in five partial models: the action model, the interaction model, the process model, the facts model and the interstriction model. The models are developed incrementally. The interaction model contains a description of the transaction types and the actors in an organisation. The actors are displayed as transaction initiating or transaction executing actors. The graphical notation used for the interaction model is the communication diagram. The process model is used for two purposes. In the first place to display the causal and conditional relationships between the transaction types, and in the second place display the course of individual transaction processes. The relationships between the transaction types is expressed in the process diagram, and the course of individual transaction processes in the transaction diagram. The facts model is the complete and precise specification of the state space of the object world. The facts diagram is used to represent the facts model. The interstriction model is a specification of the actors and the information that is needed by these actors to execute a transaction type. The interstriction model is also expressed in the communication diagram. Finally, DEMO describes the action model of an organisation. The action model is called the ‘mother of the models’ because it comprises the most detailed specification of the transaction structure of an organisation. It allows a specification of transactions at the essential, informational and documental level. The action model is expressed in the action diagram. Essential transaction design of the organisation Allows

Informational transaction design of the organisation Allows

Documental transaction design of the organisation

Figure 4 Transaction design and levels of abstraction In Figure 5 below the different models of the DEMO Business Modelling approach and examples of their representation technique are depicted. The drawing of the complete model of a business proceeds through the formulation of the interaction diagram, the process diagram, the interstriction diagram and the facts diagram. Together these diagram contain a complete description of the business at the essential level. In the final phase, the informational and documental instantiations of the essential transactions are added. This whole process is, of course, an iterative process. In the next section we continue the report of the case study Promo Results. In this section we will elaborate on the application of the DEMO Business modelling approach in combination with RAD.

7

1 Interaction m odel S1

T1

A3

A2

T2

0 S3

Start procedure Delivering_internally (T5)

Promise to comply to Delivering_internally (T5)

T3

Internal Order

3 Interstriction m odel

2 Process model

Is the ordered item in the owner’s stock?

T2

T3/O

T3/R

T3/E

EF 1

Request to Ordering_ supplies (T3)

Item

Item

T1

EF 4

NO

A1 T1 T3

YES

T2

A2

Wait for Ordering_ supplies to complete Price

EF 2

Deliver items to salesman Internal Order, standard price

4 Facts model Salesman

Item

End procedure Delivering_internally (T5)

Action m odel 5

l9

SI

R18 R19 orders D. W alker Jacket 32 Rose on shoulder Jim Bean Skirt 42 Laces in front

Figure 5 Structure and order of the essential model

4 Promo Results: A DEMO approach in RAD As was described in section 2, the RAD approach as is, does not meet the requirements practitioners set (and need). The limitations and problems of the design are a clear signal of this. To cope with this problem a Business Modelling approach was initiated as a preliminary investigation to the RAD process. In the case of Promo Results, DEMO was used to model the business processes. For the system was again developed with RAD, the choice was made to integrate this study in the Requirements Planning Phase. The attendees of this phase were instructed in the DEMO way of thinking before starting the sessions. During the sessions a DEMO study was done by the attendees, being supported by ITpersonnel to ensure correctness. This study resulted in the transactions that are displayed in figure 6. The figure displays the communication diagram exhibiting the transaction types constituting the core business processes. The transactions are represented with the combined disk and diamond symbol. The initiating and executing actors of the core business transactions are represented with a box. Since the DEMO communication model is a ‘timeless’ model, a process description was added. The business process of Promo Results was expressed in the DEMO business process model. This model is based on the transaction types that are identified in the communication model. The process diagram of the business process model is displayed in figure 7. Using the study, the developers were able to understand the essential business processes very quickly. For DEMO has a high level of abstraction, this study also allowed the developers to see similarities in the organisation, before focusing on differences. As an example one might think of the projects, which initially were each implemented in a different module. Due to the level of abstraction, developers noticed similarities between the projects. For instance, each project was done by 8

employees, each employee visited one (or several) locations and returned a report form to Promo Results. Transaction

Transaction result

Initiator

Executor

T1 Requesting offer T2 Hiring employees T3 Assigning employees

F1 Offer is sent and order is received F2 Employee is hired F3 Order is assigned to an employee F4 Outlet is selected F5 Article for use is sent F6 Article for promotion is sent F7 Employee is paid F8 Customer has paid F9 Project is planned F10 New project is created F11 Project leader is assigned F12 Project is executed F13 Employee is planned

Customer A2 Hire-employees A13 Assign-employees

A1 Offer Employee Employee

A12 Execute-project A12 Execute-project A12 Execute-project Employee A8 Request-payment A1 Offer A9 Plan-project A9 Plan-project A9 Plan-project A12 Execute-project

Outlet A5 Transp.-article-for-use A6 Transp.-article-for-prom. A7 Pay-employee Customer A9 Plan-project A10 Create-new-project A11 Assign-project-leader A12 Execute-project A13 Assign-employees

T4 Selecting outlet T5 Transporting article for use T6 Transporting article for promotion T7 Paying employee T8 Requesting pay T9 Planning project T10 Creating new project T11 Assigning project leader T12 Execute project T13 Planning employees

Customer T1

T8

A1

A9

T9

A8

T10

T12

T5

T11

A12

T13

T4

Outlet

T6

Symbol s An

A7

A2

A10

A11

A5

A13

Tn T7

T2

Actor

A6

T3

Transaction type Executor link Initiator link

Employee

Data link

Figure 6 The transaction table and communications diagram of Promo Results The study then was used as a starting point for the User Design Phase. During this phase the informational and documental content was given to the transactions, resulting in screens and software procedures. At this point, the differences in the organisation were highlighted. The users explained the subtleties of each project to the developers, which in turn adjusted their data-model to meet the new requirements. Note, that the developers changed the data-model and not the users, for it is very hard for users to understand such a model. Business models seem far more natural to them. This interaction resulted in a system which allows, amongst others, flexibility in projects, for each project has it’s own definition of a report form, allowing project leaders to create their own report forms. The screens which support this feature are displayed in figure 8.

9

T1

T9/O

T9/ E

T9/R

T8 T10

T2 T11

Initiation point

T1

T12/R

Transaction

T7 T12/O

T12/E T13 T3

T1/O

T1/E

T1/R

T4

Transaction phases T5 Causal relation T6

Conditional relation Optionality

Figure 7 Process-diagram of the business process-model of Promo Results

10

Figure 8 The new data-entry screens for Promo Results

5 Conclusion In the case of Promo Results we have observed that RAD alone can produce a system fairly adequately, however, satisfaction is not guaranteed. In the case of Promo Results, the system that was built with the RAD approach did not exhibit enough flexibility to handle corporate adaptations to the market turbulence. The system that was built on top of a DEMO analysis of the organisation showed more flexibility. From a practitioners’ point of view there are several reasons for the inclusion of a DEMO analysis in a RAD procedure for information systems development: • The DEMO study allows a quick (and thorough) investigation, allowing the developers a view of an organisation at the level of core business processes.

11

• Users seem to find Business models easier to understand than the ER models. Therefore these models allow a better evaluation of their correctness. • Due to the high level of abstraction, DEMO first converges to similarities in the Business Model before emphasising on the differences, thus allowing reuse of code and software functions (for example: all projects have definitions, and locations and people assigned to them). • The chronological or dynamics of processes are clearly visualised by the process and action diagram hereby offering training and instructions for usage before the system becomes operational, thus allowing easier acceptance and better training possibilities. In conclusion, one can say that by including a DEMO study in the Requirements Planning Phase of RAD, a better and more flexible information system can be made, for DEMO allows more abstraction, a better insight in similarities and differences and a very rapid way of marking out the system. The usage of a DEMO model provides a stable model of the core business processes. The positioning of the focus of the DEMO business modelling approach and the focus of the JAD phase in RAD is visualised in figure 9. This figure, that is based on figure 4, clearly illustrates the differences between the focus of the approaches, but it also shows how the two approaches can benefit from each other.

Essential transaction design of the organisation

DEMO Informational transaction design of the organisation

RAD documental transaction design of the organisation

Figure 9 The focus of DEMO and RAD

6 Bibliography [Boy95] [Cle94] [Die941]

[Die942]

[Die961]

Phil Boyer, Is RAD all Wet?, Datamation, September, 1, 1995. Dai Clegg, Richard Barker, Barbara Barker. CASE Method Fast-track - A RAD Approach, Addison-Wesley Publishing Company, Wokingham, 1994. Jan L.G. Dietz. Business Modelling for Business Redesign, Proceedings of the 27th Hawaii International Conference on System Sciences, IEEE Computer Society Press, Los Alamitos, CA, 1994. pp. 723-732. Jan L.G. Dietz. Modelling Business Processes for the Purpose of Redesign. Proceedings IFIP TC8 Open Conference on BPR, Australia, North-Holland, Amsterdam, 1994b, pp. 249-258. Jan L.G. Dietz, Introductie tot DEMO - van informatietechnologie naar organisatietechnologie, Samson, 1996 (in Dutch). 12

[Die962]

[DiM96]

[Don94] [Khe96] [Mar89] [Mar91] [McF83] [Reij96] [ReR95]

[Sco91]

Dietz, J.L.G. The What and the Why of Modelling Business Processes. In: R.M. van Es, A. Post (Eds.), Dynamic Enterprise Modeling. Kluwer Bedrijfsinformatie, Deventer 1996. Jan L.G. Dietz, Hans B.F. Mulder. Integrating the Strategic and Technical Approach to Business Process Engineering. In: Proceedings of the International Symposium on Business Process Modelling, Cottbus Germany, 10th October, 1996. Springer-Verlag London Ltd, 1996. John J. Donavan. Business Re-engineering with Information Technology, Prentice Hall, Englewood Cliffs, 1994. Sukhdev Khebbal, Chris Sharpington Rapid Application Generation of Business and Finance Software, Kluwer Academic Publishers, Deventer, 1996 James Martin, Joe Leben, Strategic Information Planning Methodologies.. Prentice Hall, Englewood Cliffs, 1989. James Martin, Rapid Application Development. Macmillan Publishing Company, New York, 1991. F.W. McFarlan, J.L. McKenney, Corporate Information Systems Management - The Issues Facing Senior Executives. Richard D. Irwin, inc., 1983 Reijswoud, V.E. van (). The Structure of Business Communication: Theory, Model and Application. PhD Dissertation Delft University of Technology, Delft, 1996. Reijswoud, V.E. van, N.B.J. van der Rijst. Modelling Business Communication as a Foundation for Business Process Redesign: A case of production logistics. In: Proceedings of the 28th Hawaii International Conference on Systems Sciences. IEEE Computer Society Press, Los Alamitos CA, 1995, pp. 841-850. Scott Morton M.S. (1991) The Corporation of the 1990’s: Information technology and organizational transformation, Sloan School of Management, Oxford University Press, New York.

13