A Taxonomy and Evaluation for Systems Analysis Methodologies in a
Workflow Context: Structured Systems Analysis Design Method (SSADM), Unified
Modelling Language (UML), Unified Process, Soft Systems Methodology (SSM) and
Organisation Process Modelling (OPM)
Fahad Al-Humaidan & B.N. Rossiter
Computing Science
Newcastle University
Newcastle upon Tyne
NE1 7RU
Abstract
Complex information systems
require a methodology for their development in a structured manner. Many different
methodologies exist, each suitable for a particular type of application. In
this report we develop a taxonomy covering 14 different classification features
for methodologies targeted at the workflow area. Features identified include
concerns, method structure, data gathering means, people involved, notations,
decomposition, policies, reuse, adaptability, flexibility, exception handling,
method output, CASE tool and quality assurance. The capabilities of a number of
methodologies are expressed in tabular form relative to this taxonomy for
workflow systems and to a more general taxonomy dealing with both hard- and
soft-system aspects. The results show that there is no methodology that covers
all of the taxonomic aspects identified. Organisational Process Modelling (OPM)
and Soft Systems Methodology (SSM) are relatively strong on soft aspects and
weak on hard aspects. Unified Modelling Language (UML) and Unified Process are
relatively strong on hard aspects and weak on soft aspects. Structured Systems
Analysis and Design Method (SSADM) is perhaps the most comprehensive but some
soft aspects are omitted. The combination of techniques such as UML and
Workflow is identified as a way forward.
1. Introduction
It is generally accepted that complex
information systems require a methodolgy to take their development forward from
the initial requirements of users to an implemented documented functioning
system, which satisfies the end-users in its functionality and interface (Beynon-Davies, 1998). Many kinds of methodologies
have been proposed since the 1970s in the area of systems analysis (Hawryszkiewycz, 1998). A glossary for some of the commonly-used acronyms is given at the
end of this report. The large number appears to result from different
procedures in the various software development houses and the varying
appropriateness of paradigms from application to application. It is probably true to say that every
methodology has a target area of application. For example Structured Systems
Analysis Design Method (SSADM) is suited to implementation in a
transaction-oriented relational database system. Unified Modelling Language
(UML) is suited to implementation in an object-oriented environment.
Initially methodologies concentrated on tangible aspects of user problems, that is concepts, which could be readily represented by program code and data structures. However, such aspects form only a part of the whole user problem. In effect any information system has two aspects namely hard system and soft system. The hard system part includes several elements such as data, events, processes and interfaces. The system also needs some resources (people, money and equipment) to achieve the required objectives that should possess certain qualities. On the other hand, the soft system part includes several elements such as the identification of the problem, the user involvement, the organisational structure, goals and policies, the employee job satisfaction, different points of view, the employee’s values, and the system acceptability and usability.
2. Characteristics of Particular
Approaches
2.1 OPM (1999)
The Organisation Process Modelling (OPM) method of Warboys (1999) deals with some elements of both hard and soft systems aspects. OPM covers two of the hard system elements, which are events and processes. It has a different approach to model the organisation or the system processes which is through identifying the interaction between the agents that carry out some activities (processes) to achieve their goals. We can consider the events as the necessary motivations to achieve the objectives of each agent. So the event is the agent’s motive to achieve its goal. The deficiency of the OPM method is the lack of data structure, which is important in an information system analysis and design. The main purpose of this approach is to process the data. Also the design of the interfaces is not considered and there is no identification of the required resource or quality assurance.
On the other hand, OPM covers most of the soft system elements. OPM defines the scope of the problem by using the system model. However, the process objectives might be usefully analysed through the decomposition of the different goals to establish a relationship between the objectives and the processes that will satisfy them. Also, OPM promotes the involvement of users to define the problem situation and gather many important aspects about it through interviews, discussions and workshops. Moreover, the OPM modeller communicates with the users to validate the models and the final system. It is necessary to carry out a reasonable evaluation of a process to define the values of the organisation. So if the organisation is considered to be an efficient utiliser of resources then a more Taylorist emphasis may be developed by the organisation. The Taylorist approach comes from Fredrick Taylor (Taylor, 1911) who is the pioneer of mechanistic models of an organisation. He tried to apply the principles of science to the organisational process. He broke down jobs into the smallest possible parts and used time and motion studies to identify the best way to do each and how to fit them together so that the whole task could be done efficiently. So Taylorism can be seen as reducing workers to parts of a machine. Modelling, in general, helps to develop a greater understanding of the organisation and its relationships with others. There will be inevitable conflicts and hidden agendas that have to be resolved if possible. However, if conflicts can not be reconciled, the approach of the process modeller will be the way that is acceptable to the process owner. If this is not possible the modeller needs to change the process in a way that may be at variance with the will of its owner. OPM is built around the idea of dialectics to resolve the differences between the models to encourage sharing of viewpoints between the problem stakeholders. The dialectic refers to the debate necessary to resolve the differences between the views. OPM models the different point of views for the problem situation by using the rich picture technique from the Soft System Methodology (SSM). In OPM, it is advisable to use the established techniques of Soft Systems Methodology (SSM) to specify the employees’ goals and views in the organisation. In addition, OPM supports the system acceptability (the system should not threaten the intended users to use it to achieve their desired work-related goals) and usability (the intended users should be able to use the system) by relating the software capabilities to the tasks that the users want to perform. This is done by matching the structure of the users’ task to the structure of the software system. Among the problems identified with OPM are:
· ‘The organisational goals and employee value, located in the social context of a system, are emergent and not objectively available. They have to be debated before they can be articulated and emerge as requirements’ (Warboys, 1999).
· ‘OPM does not attempt to deal with all aspects of the problem of developing software in an organisation but continually interfaces to those aspects just beyond its remit’ (Warboys, 1999).
· There is no facility in OPM for supporting the employee job satisfaction.
2.2 SSADM version 4 (1990)
Structured Systems Analysis and Design Method (SSADM) is a detailed method, which covers almost every element of the information system (Duncan, Rackley & Walker, 1995). It includes many techniques that deal with each aspect of the system. The logical data modelling presents the data structure of the system and the data flow modelling defines the system processes. Also, the entity-event modelling specifies the system events and dialogue design depicts the interface and dialogue of the system. Finally, the requirements catalogue holds all the requirement information about the development system including the required resources which are defined in the feasibility study or the business system option steps and the quality assurance which ensures that at each step the product satisfies certain quality standards.
SSADM also deals with some of the soft system aspects. The problem to be solved is identified at the strategic planning stage that studies the organisational requirements and defines the business areas that need to be improved and specifies their priorities to the organisation. So SSADM gets the result of the strategic planing regarding the system that needs to be developed or improved. SSADM starts by studying the feasibility of the system to define its operational, economical and technical feasibility. SSADM documents these decisions in the Requirements Catalogue (RC). The analyst also identifies other problems through detailed investigation of the current system. Moreover, SSADM supports the user involvement through the use of interviews and discussions in the identification of the system requirements. The users review the products at each stage in the development life cycle with the analyst available to identify any defects in the requirements. There is a new trend for the user to become a full member of the project team. Also, the organisational structure, goals and policies are investigated in the strategic planing. These are documented in the Project Initiation Document that is used as the starting point in developing the system.
In addition, the users interact with the analyst to choose appropriate options from Business System Option (BSO). BSO describes what the system should do. The analyst presents many options for the users to choose from. BSO includes some aspects about the impact of the system on customers and the need for training to increase employees job satisfaction, acceptability and usability of the system. Also SSADM documents the different views of the people regarding the system in the Requirements Catalogue. These views are documented as requirements for the new system. Finally, the involvement of the user in analysis and design will increase the acceptability of the new system. This is achieved by involving the user in reviewing the products of the development cycle stages. Prototyping is used to check the system requirements. The project management determines the prototype scope. The impact of the system on the staff is studied during the selection of Technical System Options, which will increase the usability of the system for the users. The users participate in choosing the options that will be implemented. The prototype helps the users to accept and use the new system. Also, the involvement of the users in the dialogue design increases the system usability level. The latest version of SSADM proposes the use of SSM (Soft Systems Methodology) in the early phases (CCTA, 1993).
2.3 UML version 1.3 (1998)
UML (Booch, 1999) is an expressive modelling language that covers every aspects of the system development process. It is extensible to include new features that will emerge in the development process through many mechanisms such as stereotypes, tagged values and constraints. UML can be used with any object-oriented development method. UML can be adapted with Business-Oriented Software Engineering process (BOE Process) to cover more fully the modelling of enterprises.
BOE Process and UML cover most of the hard system elements. In the object-oriented paradigm the data is encapsulated with the operations in the class, which is modelled in the class diagram. An activity diagram models the business process. The processes are described by ‘means of activities, which can be active sequentially or in parallel and for which branching and synchronisation can be defined’ (Oestereich, 1999: 61). An activity diagram has a swimlane feature, which is used to partition the activities into groups that represent business units that are responsible for these activities. However, the interface, ‘a collection of operations that are used to specify a service of a class or a component’ (Booch et al., 1999: 151), is modelled in class and component diagrams. The interface is modelled either as a class with stereotype of <<interface>> in the class or component diagram or as a lollipop icon positioned to one side of the class or component. Finally, the system quality is measured by using prototyping. During the analysis facet, there is explorative prototyping to define the application domain and the requirements of the users. During the design phase, an experimental prototyping is used to verify the proposed solutions.
UML does not have any components to model the resources but the developers can model them by using the stereotype feature. The resources can be modelled as classes with stereotype <<resource>>.
BOE Process also deals with the soft system elements. The problem is identified in response to take advantage of an opportunity or to eliminate any defects in the organisation. The strategic planning specifies the problems that need to be solved and assigns priorities to them to identify their importance to the organisation. The development process is used to solve the problem that has the highest priorities by gathering information about it. BOE Process also supports the user involvement during the system analysis to gather data through interviews with them and workshops. This data will be documented in some form such as use case models, CRC (Class-Responsibilities-Collaborators) cards or technical dictionaries. The users will be involved in the explorative prototypes to validate the system requirements and in the experimental prototypes to verify the usability of the final system. This will encourage the users to accept and use the system to perform their tasks and minimise their resistance. Moreover, the new system sometimes needs to be integrated in an application area. To achieve an efficient and reasonable integration, the points of contact with the surrounding process need to be analysed. UML uses the activity diagram to integrate the new system into the organisational structure. Through the modelling of the business processes, activities can be divided into sub-activities called swimlanes (responsibility lanes) which allow assignments to be represented for an organisational structure. Modelling of organisational structures, role concepts and privileges can be handled in trivial situations. The employee job satisfaction involves two aspects.
· First is for the employee in the development team who tries to solve the problem and implement the system in the organisation. His job satisfaction will be in achieving the goal that the project manager assigned to him. The project manager assigns goals to the employees who are suitable for their skills and responsibilities and lets them choose the way to achieve these goals. If any problem occurs, the project manager will try with the employees concerned to solve it. Also the project manager is responsible for evaluating the performance of the employees so as to monitor and identify their weaknesses and motivate their performance.
· Second is the employee who will use the final developed system. His satisfaction will be increased if the system helps him to perform his task in a suitable way without forcing him to follow restricted procedures. An analyst collects information about the problem and its domain through the interview with the users of the system and domain experts. He should consider the different views. If there is any contradiction in their views, the analyst should resolve them. The project manager should support the teamwork rather than the individuals.
As a weakness BOE does not include any support for the employee’s values.
2.4 Unified Process (1999)
The Unified Process method (Rational Software Corporation, 2000) covers most of the hard system elements. It supports object-oriented techniques as its models are based on object, class and relationship concepts. In the object-oriented paradigm the data is encapsulated with the operations in the class, Such data is modelled in the class diagram with the persistent data being stored in a database. An activity diagram models the business process. An activity diagram has the swimlane feature, which is used to partition the activities into groups that represent the business units, which are responsible for these activities. In addition, the events are depicted by using the interaction diagrams that are collaboration diagrams, sequence diagrams and activity diagrams. Which diagram is used depends on the required information and detail. For example the collaboration diagram is used in the analysis since the focus is then on the requirements and responsibilities of classes or objects and the sequence diagram is used to depict the chronological sequences of interactions in the design.
The interface has two types.
· The user interface, which presents the functions or operations that the system offers to its customers or users. This interface is considered in the requirement capture to specify and prototype the user interfaces of the use cases of the developed system to understand the interactions between actors and the system. These interfaces are presented by using screen sketches on paper or prototype tools.
· The internal interfaces between the classes or sub-systems. This interface, ‘a collection of operations that are used to specify a service of a class or a component’ (Booch et al., 1999), is modelled in class and component diagrams.
These interfaces specify the operations that are provided by the design classes and sub-systems. The design class that offers an interface must also offer methods that realise the operations of the interface. A sub-system offering an interface must also contain design classes or other sub-systems that offer the interface. The resources in the Unified Process include time, cost and the people who will develop the system (worker is a Unified Process term for a role) and the tools that will be used to help workers perform their tasks. The Unified Process provides guidelines that help the assigned people to do their tasks and produce the required artefacts and plan for the next phases and iterations. The project manager assigns people to workers depending on their skills. He should also provide the workers with suitable training on how to use the tools. He should consider the number of iterations in each phase, how long each iteration takes and the total cost of each phase and the final system. The Unified Process checks the system quality through performing some explorative prototypes in the inception and elaboration phases and several tests in the test phase to ensure that the system accomplishes the users requirements such as the integration, configuration, negative and stress tests. Finally, the Unified Process deals with the business issues through developing a business model that helps to understand the functionality of the business system. Business modelling is supported by two kinds of UML models namely use case models and object models (Rational Software Corporation , 1999). A business use case model defines the business processes of a company in terms of business use cases and business actors. A business object model defines how each business use case is realised by a set of workers, work units, business rules and other regulations imposed on the business. Each realisation of a business use case is modelled in interaction diagrams and activity diagrams.
The Unified Process method also deals with the soft system elements. The problem is defined as a response to taking advantage of an opportunity to eliminate any defects in the organisation. The strategic planning specifies the problems that need to be solved and assigns priorities to them to identify their importance to the organisation. The development process is used to solve the problem that has the highest priorities by gathering information about it. In addition the Unified Process encourages user involvement during the requirements capture by gathering data or requirements through interviews with them and participation in workshops. These requirements will be documented in use cases, business or domain models and supplementary requirements. The users will be involved in checking the artefacts of the iteration and phases. This will encourage the users to accept and use the system to perform their tasks and minimise their resistance. Moreover, the organisational structure, goals and policies are dealt with in requirement capture.
The Unified Process is a generic process that needs to be specialised depending on many factors such as organisational, domain, life cycle and technical. The organisational goals and policies are documented in the business model and supplementary requirements. The business model is ‘a technique for understanding the business processes of an organisation’ (Jacobson & et al., 1999). Business modelling is supported by two kinds of UML models: use case models and object models. The business use case model, which is depicted as use case diagrams, defines the business processes as business use cases and customers as business actors. A business object model specifies how each business use case is realised by a set of workers who use a set of business entities (orders or invoices) and work units. The business rules and other regulations imposed on the business are associated with these different objects. The supplementary requirements include non-functional needs such as interface and physical requirements and design and implementation constraints. The implementation constraints control the coding or construction of a system. Such constraints include, for example, required standards, policies for database integrity, resource limits and operation environments. There are many factors contributing to the employee’s satisfaction, for example, project feasibility, risk management, team structure, project schedule, project understandability and sense of accomplishment. Project feasibility and free risk project help employees to enjoy their works. Satisfaction is achieved through the iterative approach that allows the feasibility of a project to be assessed early and the mitigation of critical risks. The Unified Process approach recommends building a developing team in a small group to work effectively. The process structure (assessing a risk, developing a sub-system, performing an iteration) and the system architecture (including sub-systems and components and their interfaces) permit this and let the employees understand and obtain an overview of the system. The effective scheduling of a project assists in increasing the employees' satisfaction because they are involved with the end result of their work. In addition, the iterative approach helps the employees to get frequent feedback about their work and provides closure. Such factors increase the employees’ sense of accomplishment.
At the beginning of the life cycle, there is a little information about the required system. So an initial team may include the project manager, the architect, a developer experienced in analysis, a test engineer and representatives of the users. Such a team is constructed to develop detailed information about the system. The different views of the team members are integrated to give the best answers for help in developing the system. In the transition phase, the Unified Process ensures the acceptance of the system by performing the acceptance test. The acceptance test is done by releasing a beta version to the users for them to verify and report any problems, defects or observations to the developers for correction. The acceptance test concludes when the system meets the users requirements. The developers provide the users with documentation to use the system and to help them with any issues regarding the new system. This will help the users to accept and use the system in performing their tasks.
A weakness is that the Unified Process does not include any support for the employee’s values.
2.5 SSM (1990)
Soft Systems Methodology (SSM) deals with some elements of hard systems aspects. SSM (Checkland & Scholes, 1990) supports the activities and processes through using a conceptual model to represent the activities of the root definition. The resources can also be presented in the root definition and the activities modelled can be related to them in the conceptual models. SSM validates the quality through defining measures for activities in a conceptual model of the proposed system. Activities monitor these measures and take control action to improve matters in the proposed system. In addition the business issues are considered as a combination of the different perceptions in the conceptual models that help to identify business system options and define acceptance criteria for the delivered system.
As a weakness SSM does not support the other elements of the hard approach such as data, events and designing interfaces.
On the positive side,
SSM deals with all the elements of the soft approach. SSM may therefore be used
to improve our understanding of ill-structured problems. The rich picture model
is used to represent the complexity of the human affairs and the problem
situation. This helps to discuss the problem situation with the people involved
so as to get a clearer picture of it. The users are also involved in gathering
information about the problem situation through interviews and discussions in
the workshops. SSM provides the means for the analyst to discuss the situation
in the users’ own terms using the root definitions and conceptual models. The
users will be involved in choosing the activities to construct a consensus for
the primary task model required in defining information for a system that
accommodates the different users’ viewpoints. The technique also encourages
debate to define the required changes to improve the situation. Moreover SSM
uses the rich picture technique to model the organisational structure, goals
and policies in the problem situation. The primary task model is used to depict
the main role of the organisation. The job satisfaction of the employees is
achieved through their involvement in the debate to compare the conceptual
models and the real world and specify the differences and changes necessary to
match the scenarios more closely. In addition, SSM deals with different
perceptions of the problem by selecting the most relevant set of the
perceptions. Conceptual models of system activities are then developed to
depict these perceptions. These models are combined in ways that accommodate
the different perceptions and may extend to reconcile conflicting concerns or
needs. SSM documents the employee’s value in what is termed Analysis Two, which defines the roles,
norms, and values. A role is a ‘social position recognised as significant by
people in the problem situation’ (Checkland, 1990). A role is characterised by
the expected behaviours of objects, sometimes termed norms. Actual performance
in a role will be judged according to local standards or values. So after each
interview, discussion or examination of a document, an exchange of experiences
needs to be made and the roles, norms and values inferred. Finally, the
acceptance of the method depends on the result of a project. If the project
achieves the users’ requirements that will encourage the users to use the
system. The users’ involvement throughout the project encourages them to accept
the system and to use it.
3 The Workflow Approach (1996)
The workflow management
technology (Jablonski & Bussler, 1996) introduces new qualities into the
task of combining the people, organisation and processes to form a value chain. Such a chain is a
management terminology for a string of companies working together to satisfy
market demands. The value chain typically consists of one or a few primary
value (product or service) suppliers and many other suppliers that add on to
the value that is ultimately presented to the buying public. Workflow management is intended to
improve the quality of the service or product.
Workflow systems are used to ‘document and
control the transitions between tasks in a process and bring together the
resources (human and information) needed to complete each task’ (Stark and
Lachal, 1995). They bind and integrate
the critical factors of the enterprise such as people, organisation and processes.
Workflow management has taken functionality out of the application programs. It
provides a systematic approach to turn islands of automation into an effective
and efficient force with valuable commercial impact (Jablonski and Bussler,
1996).
The advantages of workflow systems are saving labour and paper, reducing
‘dead time’ in processes and improving their quality. Workflow systems should
provide process management facilities that allow changing processes either to
make the best use of available resources or to respond to changing needs (Stark
and Lachal, 1995).
Jablonski and Bussler (1996) cite three
definitions of workflow management systems. The first definition is from the
consulting area. and Lavery (1991) defines the workflow management as:
‘a
proactive computer system which manages the flow of work among participants,
according to a defined procedure consisting of a number of tasks. It
co-ordinates user and system participants, together with the appropriate data
resources, which may be accessible directly by the system or off-line, to
achieve defined objectives by set deadlines. The co-ordination involves passing
tasks from participant to participant in correct sequence, ensuring that all
fulfil their required contribution, taking default actions when necessary’.
This definition includes some of the
workflow management elements such as tasks, participants, data resources and
task procedures that control the performing of the tasks by the participants.
The second definition is from the research domain. Reinwald (1994)
defines the workflow management system as ’an active system that manages the
flow of business processes performed by multiple persons. It gets the right
data to the right people with the right tools at the right time’. This definition
adds other workflow management elements such as tools and the optimal execution
time.
The third definition is from the industrial
area. The Workflow Management Coalition (1993)
defines the workflow management system as ‘one which provides procedural
automation of a business process by management of the sequence of work
activities and the invocation of the appropriate human and/or IT resources
associated with the various activity steps’. This definition places emphasis on
the work and the agents that will perform it.
3.1 Workflow Management Origins
Some software technologies have affected the development of the workflow
management such as office automation, database management, e-mail and other
technologies. Office automation is considered the main origin of the workflow
management approach. There are some office information system requirements that
can be applied in the workflow management systems such as scheduling
activities, function integration, personnel assistance and task management. In
the early days of the workflow management, some systems were tailored for use
in office environment. In database management, some research has been done to
deal with the transactions in the workflow management systems.
·
First, it is
necessary to deal with Event-Condition-Action (ECA) in active databases to
handle tasks in workflow management systems.
·
Second, there
is the extended transaction model to handle the failure and execution atomicity
of the work tasks.
Workflow management systems share some
characteristics with e-mail such as actively using routing information.
Document management affects workflow management systems through managing the
work documents. There is little effect of software process management on the
workflow management system. In addition, the business process modelling
includes several aspects such as economy, technology and computer-orientation.
The scope of workflow management systems is also so wide that they can be
considered as an enactment infrastructure for business process modelling.
Finally, enterprise modelling and architecture requires a global and
process-centric view so workflow management systems should consider including
all aspects of application system rather than partial aspects (Jablonski and
Bussler, 1996).
3.2 Workflow Management Technology
Generation
The workflow management technology has several phases.
i.
The beginning
phase is where experiences with academic and commercial prototypes have to be
gained.
ii.
The conceptual
phase is where conceptual work is done. Conceptual models and architecture are
developed. Design methodologies are first established in this phase.
iii.
The
proliferation phase is where the workflow management tools are widely spread.
iv.
The
standardisation phase is where norms and standards are developed.
Also, there are three stages of the
development of the workflow management approach in a particular business:
i.
The home-grown
stage is where there is a lack of workflow model
ii.
The
rudimentary stage is where there is an autonomous workflow engine, which
executes the workflow models, but which is defined independently from the
application programs. Changes are restricted depending on the workflow model
and the execution engine.
iii.
The dynamic
stage is where the workflow model can be adjusted to new application
requirements. Also the workflow management system architecture can be adapted
to new hard-and-software infrastructures (Jablonski and Bussler, 1996).
Most of the workflow tools use one of the
following two architectures.
1)
Electronic
forms provide the interface for tasks. These forms are transported through task
stages using messages. This type of product supports the building of
applications, which are used to get the work done.
2)
External task
applications provide the interfaces for tasks. The process environment is controlled
by a workflow engine, which keeps track of the progress of each instance of the
process. This type of product provides sophisticated process management.
Workflow systems are used well when the five
conditions below hold.
1)
Processes have
explicit component tasks.
2)
Rules
determine the logic of transitions between tasks.
3)
Tasks use
digital information resources.
4)
Tasks need to
be communicated to workers.
5)
There is a
need for process control (Stark and Lachal, 1995).
Jablonski and Bussler (1996) also introduced
a comprehensive workflow model, which is called Mobile Workflow Model. It is a
comprehensive model, which is considered as a reference model for the
classification and assessment of other workflow models and architecture. It has
five essential perspectives and six additional perspectives for other purposes.
1)
Functional
perspective.
From this angle we define what has to be
done. This consists of either elementary or composite workflows.
2)
Operational
perspective.
From this angle we define the workflow operations
which are implemented by application programs.
3)
Behavioural
perspective (control flow).
From this angle we define the execution
order of workflows. It is optimal to specify only those execution order
dependencies, which are fundamental, even if only a partial ordering results.
An execution order specifies the control flow dependencies between the
sub-workflows of a workflow independent from data flow dependencies. At run
time both control flow and data flow have to be considered when execution order
of sub-workflows is determined.
4)
Informational
perspective.
From this angle we define the data
requirements in the workflow management system. There are two types of data.
First is control data, which is used by the workflow management system to
control the execution of the different workflows. Second is production data,
which is external data that can be used by workflow management system.
5)
Organisational
perspective.
From this
angle we specify who is responsible for performing the different tasks.
6)
Causality
perspective.
From this
angle we describe the rationales for
the specification of a workflow and for the execution of a workflow instance.
This area includes business policies, enterprise strategies and legal business
rules, which regulate the definition of the workflow types.
7)
Integrity and
failure recovery perspective.
From this angle we define two types of failures in workflow management systems: semantic and system:
i. Semantic Failures
They are application area dependent.
ii. System Failures
They are technical problems. They affect
the execution of the workflow instances, which could not proceed without
running a recovery mechanism. They are caused by erroneous program code, a
power failure, a hardware failure, a base service software failure or a network
failure. The workflow management system cannot model the system failures.
8)
Quality
perspective.
The quality
perspective includes several aspects. The cost and time will be restricted in
the quality perspective. A high quality workflow instance execution will not
consume excessive time and system resources. Data is needed to assess the
quality of a workflow type specification. One method is to compile workflow
instance executions as may be found in a log file. This data is analysed to
find execution bottleneck, resource intensive workflow steps and long-running
workflows.
9)
History
perspective.
From this
angle we build an audit trail for each
workflow instance. The audit trail has information about what happened while a
workflow was performed
10)
Security
perspective.
Security is concerned with the
responsibility to access an object. There are many issues that determine the
access right for the user such as his responsibility from the organisation
perspective, the security reasons and organisational policies. This does not
cause any problem as long as they agree on who is allowed to perform the
workflow operation.
11)
Autonomy
perspective.
This perspective is global. It has three aspects such as mobility, distribution and execution threads.
Jablonski and Bussler (1996) also presented the run time infrastructure, which consists of implementation model, implementation architecture and implementation. The implementation model includes the functional components, which form the conceptual basis for the run time part of a workflow management system. It describes the workflow components and the protocols between them. The implementation architecture, which is used to enact the functional components, has three aspects such as the functional components, databases and communication mechanisms. The implementation infrastructure is then implemented using the available techniques and tools.
4 Taxonomy for Workflow Systems
Table 1 identifies the workflow features that form
the basis of our taxonomy. The notes following the table provide further
details of each feature.
|
Features |
WORKFLOW |
|
1)
Concerns |
Workflow management systems aim to improve the efficiency and the
effectiveness of a company through the improvement of its business process. |
|
2)
Method structure |
An approach has two parts: A)
Business-oriented
part.
i.
Enterprise
planning.
ii.
Business
area analysis.
iii.
Reconstruction. B)
System-oriented
part.
i.
System
specification.
ii.
Module
programming and testing.
iii.
System
integration and testing. |
|
3)
Data
gathering means |
A)
Interviews
and discussions with the domain experts. B)
Interviews
and discussions with the users. C)
Examining
the organisation documents. |
|
4)
People
involved |
A)
Organisation
management. B)
Domain
experts. C)
Users. D)
Developers. |
|
5)
Notations |
There are no specific notations for describing the workflow management
system. |
|
6)
Decomposition |
A workflow management system supports a business process that can be
decomposed into tasks. |
|
7)
Policies |
They are stored in the organisation perspective in the comprehensive
workflow model. |
|
8)
Reuse |
It is necessary to support reusability in the workflow management
systems through the reuse of the existing information and artefacts in the
enterprise to describe the workflow specifications. Also, workflow management
system can reuse scripts, definition and sub-workflows that can be used in
different workflows. |
|
9)
Adaptability |
It is achieved through the use of dynamic modelling which specifies a
process during the runtime. |
|
10)
Flexibility |
Flexibility occurs on using control flow rather than concrete flow and
using a dynamic model rather than a static one. |
|
11)
Exception
handling |
It is done by using event-handler capabilities or the human
intervention. |
|
12)
Method
output |
The output is a workflow management system for a specific deployment
area or a comprehensive workflow management system that covers the entire
enterprise. |
|
13)
CASE tool |
There are two kinds of tools that are used with workflow management
system namely, build time tools and run time tools. |
|
14)
Quality
assurance |
Workflow
management systems support the quality of a process through identifying the
process rules and the weakest parts in it. Also, workflow systems reduce
redundant data entry and time consuming in data retrieval. |
Table 1: Features of the Workflow Approach
that form the Basis of our Taxonomy:
4.1
Notes on Taxonomy
1) Concerns
Workflow systems aim to improve the efficiency of a company through
lower costs, a higher capacity for workload, a greater effectiveness through
standardisation of procedures and the optimisation of performance in aspects
such as process control and process management Workflow systems provide
computer support for process logic.
2) Method
structure
Jablonski and Bussler (1996) introduce an approach for workflow
management systems. It consists of two realms. The first one is the
business-oriented realm, which domain experts deal with and the other is the
system-oriented realm which information technology experts deal with.
The business-oriented part constitutes enterprise planning, business
area analyses and reconstruction phases. The enterprise-planning phase
identifies goals, objectives, business strategies and business areas. The
business area analyses investigate the considered business process by using a
descriptive model. The reconstruction phase aims to detail and complete the
descriptive model to smooth the transition to the system-oriented part. It
needs support from both domain experts and information technology experts. The
result of this phase is a constructive model, which describes both
domain-oriented and system-oriented information using an
implementation-independent language. The entities of the constructive model are
defined and their relationships are outlined.
The system-oriented part consists of three phases: 1) system
specification, 2) module programming and testing and 3) system integration and
testing. In the system specification phase, the details about the selected
implementation method are specified. The result of this phase is an
implementation model, which describes how the application system will be
implemented. In the module programming and testing, the modules are coded by
using a specific computer language and each module is tested. The final phase
is the system integration and testing where the different system modules are
integrated and the final system is tested against its requirements.
3) Data
gathering means
There are many ways to collect data for the
workflow management system such as interviews and discussions with the domain
experts, interviews and discussions with the users and examining the
organisation documents.
4) People
involved
There can be many people involved in
developing a workflow management system such as organisation management, domain
experts, users and system developers.
5) Notations
There is no specific notation for describing the workflow management system.
6)
Decomposition
Workflow systems aim to support and improve the business process, which
contains several aspects such as its logic, its need to handle human and
information resources and to perform its tasks and to manage processes in an
overall manner. The process is decomposed to tasks. A task is ‘just a step or a
stage in a process’ (Ovum, 1995). Most
workflow systems have an implicit view of a task, which has three elements: the
use of application resource, a single person’s effort and one time interval.
7) Policies
Policies are stored in the organisation
perspective in the comprehensive workflow model.
8) Reuse
It is necessary to support reuse in workflow systems through reusing the
existing information and artefacts in the enterprise to specify the workflow
specifications and the reuse of scripts and definitions of other workflows.
Some workflow systems identify the repeated activities to form sub-workflows
that can be used in different main workflows.
9) Adaptability
The use of dynamic modelling, which specifies the tasks of a process
during the run time, help to design an adaptable system that can react to
events that occur when the process has started.
10)
Flexibility
One feature of the flexibility in workflow systems is the different
flows between tasks in a process. There are two kinds of flow namely concrete
flow and control flow. The concrete flows are used to transmit forms, data or
documents between tasks. In this type of flow, the tasks of the workflow use
the content resources with different states that change through the progress of
the tasks defined within the process. So it is inflexible to design workflows
in which different tasks use different content resources. It is difficult to
deal with parallelism that requires a split and join of the content resources
associated with the process. However, in the control flows the tasks can use
different content resources. So the control flows are more flexible than the
concrete flows.
There is flexibility in defining a process
by using a dynamic model instead of a static one. In the static model, the
tasks in a process, the resources they use and the rules that control the
transition between each task must be defined at design time. In the dynamic
model, the definition of a process and its tasks is done during the run time.
11) Exception handling
Some workflow systems use event-handling capabilities to deal with error
and exception situations. Otherwise the human user has to intervene during the
execution of the workflow instance and correct the failure.
12) Method output
The output is a working workflow management
system that can be used in a specific deployment area or a comprehensive
workflow management system that can be used by the enterprise to cover several
deployment areas such as accounting, human resources and other applications.
13) CASE
tool
A workflow management system has two stages: build time and run time. The build time part allows a modeller to specify all aspects of the workflows. Then the workflows are executed by the run time part of the system.
Build Time:
The conceptual part of the build time is the workflow model, which contains all information to describe a workflow. The tools that support the build time are as follow:
i. A workflow editor is used to define the workflow.
ii. A workflow language compiler is used to compile the language to check the integrity of the specified model.
iii. Simulator and animator tools are used to validate the specified workflows.
iv. Administration tools are used to manage the workflows and store their information in a database, library or repository.
Run Time:
The main purpose of the run time is the execution of workflows. There are some tools that support run time as follow:
i. Monitor tools are used to observe and control progress of workflow execution.
ii. Analysis tools are used to assess the effectiveness and efficiency of workflow execution.
iii. Administration and configuration tools are used to manage the execution infrastructure.
iv. The worklist manager offers worklists, which are the user interfaces to the workflow management system.
14) Quality Assurance
Workflow systems support the quality of a
process through identifying the rules that are enforced during the performing
of a process. The process management of the workflow systems supports the
process improvement by helping the managers to identify its weak aspects.
Workflow systems help to reduce redundant data entry and time consumed in data
retrieval.
5 Comparison of Workflow
Approach with Others
Workflow
systems support most of the hard system approach elements. They support data
through the use of the database. There are two architectures to design the
workflow systems. The first architecture is a form-based architecture where the
form is the essential part of the workflow system. The form is moved from one
user to another to perform the required tasks of the process. The data of the
form fields are connected to a database that stores and displays the data. The
second sort is an engine-based architecture where the workflow engine controls
and manages the process and its tasks. All data of the workflow management
system are stored in a database. Such data are passed by using parameters or
variables (Stark and Lachal, 1995). Workflow systems also support events. There
are two types of events: internal and external. These events trigger the
initiation or execution of the process instance to handle them. Some workflow
systems that support the dynamic model have an event-handler, which deals with
specifying the next task in the process path.
The process is the core of the workflow
system. The essential objective of the workflow systems is to support the
process and optimise its performance. In the form-based architecture the logic
of the process is attached with the form which is transmitted between users.
The logic of the process and its tasks are written in a script language. On the
other hand, the engine-based architecture stores process definitions and the
states of process instances in a database. In workflow systems, there are
different types of interfaces that help to communicate with their parts
variables (Stark and Lachal, 1995). The
Workflow System Coalition identifies five types of interfaces as follow:
i. Process definition tools interface.
ii. Workflow client application interface.
iii. Invoked application interface.
iv. Workflow interoperability interface.
v. Administration and monitoring tools
interface (Jablonski and Bussler, 1996).
These interfaces
can be used with the engine-based architecture. On the other hand, the user
interface in the form-based architecture is the form. Some workflow systems
provide Application Programming Interface (API) function libraries that are
used to develop a new interface for the workflow system to fit into the common
interface that is used in the organisation variables (Stark and Lachal, 1995).
In addition, workflow
systems have two types of resources: human and information. Workflow systems
support the quality of a process through identifying the rules that the
workflow systems are forced to follow in performing the process. Also the
process management of the workflow systems supports the process improvement by
helping the managers to identify the weak aspects in it. Workflow systems help
to reduce redundant data entry and the time consumed
in handling the data (Stark and Lachal, 1995). Workflow systems support
the business issues through the support of the processes of the organisation.
The organisation business depends on its processes that should be carried out
in optimal way to achieve the objectives of the organisation. In the form-based
architecture, the process logic is attached with the form. While in the
engine-based architecture the process logic is found in the workflow engine.
Workflow
management systems support all soft system aspects. The organisation problem is
identified in the enterprise planning and business area analysis. It is
necessary to identify if the problem needs a workflow system approach to solve
it or not. Workflow systems are suitable for processes that have the following
characteristics:
i.
Processes have
explicit component tasks.
ii.
Rules
determine the logic of transitions between tasks.
iii.
Tasks use
digital information resources.
iv.
Tasks need to
be communicated to workers.
v.
There is a
need for process control (Stark and Lachal, 1995).
The management of workflow systems should
support user involvement in developing the systems because workflow systems
have a profound effect on the users. The users should be consulted to implement
the workflow systems and develop a pilot system to discover the impact of the
system on them. Workflow systems also define the organisation through an
organisational structure and an organisational population. An organisation
structure defines all elements of the organisation. On the other hand, an
organisation population specifies the actual entities that hold the different
positions in the organisation. The enterprise planning and business area
analysis phases identify the area where the workflow management system can be
implemented to achieve the organisation goals and objectives. The organisation policy can be specified for
each workflow operation to define the eligible agent and the rules to perform
it. All these data are stored in a database to be used by workflow management
system (Jablonski and Bussler, 1996).
A workflow system uses one of two models to
assign work to the employees:
·
First is the
system-offer model in which the system offers tasks to employees who are then
free to accept them or not.
·
The other is
the system-deliver model in which the system assigns the tasks to users
directly.
The system-deliver model may provide ways in
which users reject, evade, delegate or otherwise transfer responsibilities of
which they are notified. The system-offer model is used to balance the workload
between users. Workflow systems may impact on the employees because one of the
objectives of implementing workflow systems is to reduce the staff and control
the way that the employees perform their work. But this does not occur every
time that a workflow system is introduced. More staff
may be required to deal with customer activities such as sales and
customer services and the improved operation may encourage the organisation to
take on an increased workload.
Furthermore, Workflow systems could support
different point of views through defining different paths to perform a process.
Employee’s value can be stored in the organisation population when specifying
the actual entities for each role in the organisation. Workflow Systems'
acceptability and usability will increase if the workflow systems solve
workers’ problems and the business problems such as work backlogs, lost
information and the difficulty of getting the right information (Stark and
Lachal, 1995). The services, which relate to user requests, must be efficient
to satisfy their users. So it is recommended to do a pilot design and try it to
see its effect on the users’ environment (Jablonski and Bussler, 1996).
6 Comparison of Different
Methodologies using the Workflow Taxonomy
Table
2 compares the different methodologies in terms of the taxonomy determined
earlier for workflows.
