«Sharam Hekmat PragSoft Corporation Contents 1. INTRODUCTION 1.1 PURPOSE 1.2 SCOPE 1.3 SOFTWARE TOOL 1.4 GLOSSARY OF TERMS 2. ...»
2.3 Architectural Reference Models 2.3.1 Architectural Domains Reference Model The following reference model illustrates the key architectural domains of an information system and their relationships.
The primary aim of this model is to achieve a clear separation between the technical and nontechnical, and between the technology dependent and technology independent. This ensures that technical changes do not invalidate the business architecture, and that technological changes do not impact the business and software architectures.
A business architecture models the key elements of a business, their relationships, and interactions. Its main focus is analysis. Given that business processes provide the most reliable and relevant foundation for articulating the desired behaviour of an information system, a process-centric approach to business modelling would be ideal.
A software architecture (including data architecture and security architecture) models a software system in terms of its key layers, components, and interfaces between them. Its main focuses are design and ease of maintenance. A component-based approach is now the industry-wide standard for this purpose.
A technology architecture models the technological framework for building information systems (including: tools, languages, middleware, operating systems, standards, protocols, third-party components, etc.). Its main focus is construction. The technology architecture needs to continuously evolve to keep up with the relevant and mature offerings that gain acceptance in the industry.
A system architecture maps a software architecture to a network architecture using a given technology architecture. Its main focus is operation. One of the key objectives of a system architecture is to provide a tiering model that best fits the operational requirements of the system (e.g., scalability, physical distribution, and fault tolerance).
2.3.2 Layered Architecture Reference Model The following reference model illustrates the key software architecture layers of a process-centric information system. This model is suitable for information systems used in the finance industry because the great majority of such systems support specific business processes.
The presentation layer is concerned with the displaying of data to and accepting input from the user. This layer contains no business functionality.
The process layer defines the end-to-end business processes of the organisation (e.g., ‘open bank account’). A process typically involves a number of persons and is specified in terms of activities and queues (a queue is a place where an activity may deposit data for other activities to withdraw from later).
The activity layer defines the activities that comprise the processes. Each activity is a process segment that is performed by one person. For example, the ‘open bank account’ process may have an activity called ‘setup account information’.
The business object layer specifies the business objects that ultimately realise the business functionalities behind the business processes. Each business object represents a key entity in the business domain. When an action is performed, it affects one or more business objects. For example, the ‘enter customer details’ action will affect the ‘Customer’ business object.
The data services layer handles the querying and updating of external data sources. The data sources provide persistent storage for the business objects (e.g., for ‘Customer’).
The process, activity, and action layers are collectively called the workflow layer. These layers can be supported using a workflow engine.
The process, activity, action, and business object layers are collectively called the business logic layer. All of the business logic of the application (e.g., validation, sequencing, and updating rules) are contained by these layers. Consequently, the implementation of a transaction may encompass all these layers.
3.1 Introduction to Business Processes 3.1.1 What Constitutes a Business Process?
A business process is simply a set of well-defined and inter-related activities that collectively transform a set of inputs into a set of outputs (goods or services) using people and tools. Business processes can be observed at many levels in an organisation: within a business unit, across business units, or across the whole organisation.
Of particular importance are end-to-end business processes. These go right across the business units and are typically triggered by external sources (e.g., a customer requesting a service).
To appreciate the importance of end-to-end processes, consider the way information solutions are often used in the finance industry.
Business units generally have an internal focus that narrows their view to the local processes that exist within the unit. As a consequence, these local processes drive their requirements for information solutions, and this results in applications that are built to specifically support them. This gives them what they want: solutions that are tailored to their needs, and solutions that they can exercise control over.
The problem with this approach is that it results in a silo-style organisation that is too rigid in its boundaries. A business never stays stationary. Business opportunities change, markets change, customers change, technologies change, and so on. Given that change is always present, an organisation’s success will largely depend on its ability to accommodate change and to use it to its advantage. The way an organisation designs its business processes and the information systems that support them will, to a large degree, determine its ability to deal with change. Under the silo approach, there is very little scope for moving the boundaries between the business units. Moving a boundary too much will break the local processes and even split applications (as illustrated by the above diagram).
Over time, however, boundaries must move so that the business can adapt itself to change. The accumulated effect of these changes is that processes become patchy and applications deteriorate under pressure to conform to conflicting requirements. In other words, the more change takes place, the less the organisation is able to cope with it.
3.1.2 Business Process Improvement Rising customer demand for better and cheaper products and services has forced most businesses to seriously consider process improvement in order to stay competitive. Most companies that have embarked on process improvement have adopted the continuous improvement model, as illustrated below.
This method is effective in generating gradual, incremental process improvements. Over the last decade, however, several factors have accelerated the need to improve processes faster; most
UML Process 21 Copyright © 2005 PragSoft
• New technologies (e.g., Internet) are rapidly bringing new capabilities to businesses, and hence raising the competitive bar.
• The opening of world markets and increased free trade are bringing more companies into the marketplace, which is in turn increasing competition.
As a result, most companies that are hard-squeezed are no longer content with gradual improvement, but are looking for breakthrough performance leaps. This demand has led to the emergence of a more radical approach called Business Process Re-engineering (BPR).
3.1.3 Business Process Re-engineering (BPR) BPR takes a different approach to process improvement which, at the extreme, assumes that the current process is irrelevant and should be redesigned from scratch. BPR proponents argue that we should disassociate ourselves from the present, project ourselves into the future, and ask some
• What should the process look like?
• What do our customers want it to look like?
• What do other employees want it to look like?
• How do the best-in-class companies do it?
• What benefit can we get by using new technology?
The following diagram illustrates the BPR approach. It begins with defining the scope and objectives of the BPR project. A learning process next follows that involves customers, employees, competitors, non-competitors, and the use of new technology. Based on this improved understanding, a new set of ‘to-be’ processes are designed. A transition plan is then formulated which aims to close the gap between the ‘to-be’ processes and present. This plan is then implemented.
Because of its clean slate approach, BPR offers a far greater potential for realising breakthrough improvements.
3.2 Business Modelling Concepts 3.2.1 Abstraction versus Instance Those with an understanding of object-orientation concepts would be familiar with the distinction between an abstraction (e.g., class) and its instances (i.e., objects). An abstraction depicts a general concept that has no physical existence, whereas an instance is a specific manifestation of the abstraction that has physical existence. For example, ‘book’ is an abstraction that may be www.pragsoft.com 22 UML Process defined as ‘a collection of pages with text printed on them’, whereas “my copy of ‘A Brief History of Time’ by Stephen Hawkins” is an instance of the book concept.
This distinction is equally important when dealing with business processes, and allows us to
• a process definition, which is provided as a recipe that describes the process in terms of its constituent parts, and
• a process instance, which represents a specific case of performing the process.
The distinction is similar to that between a cuisine recipe and someone’s specific attempt of following the recipe to produce a dish. It is important to note that any given unique abstraction may have many (potentially infinite) instances. Abstractions used in an information system (e.g., classes, business processes) are defined only once, during the development of the system. Subsequently, these abstractions are instantiated numerous times during the operational lifetime of the system.
3.2.2 Business Process Definition
A business process is defined in terms of these abstractions:
• Triggers. These are events outside the process that cause the process to be instantiated (i.e., kick-off the process).
• Activities. These are the building blocks of the process. The key difference between an activity and a process is that, whereas multiple individuals typically perform a process, only one person performs an activity. Therefore, it requires no further collaboration.
• Queues. As a process progresses from one activity to the next, there is a need to hold the work somewhere, until the person doing the next activity is free to pick it up. This is very similar to the concept of in-trays in an office. You receive new work in your in-tray, where it piles up until you can pick it up, do your bit to it, and put it in someone else’s in-tray. Queues enable a process to be performed in an asynchronous fashion.
We will use the following symbols to depict these abstractions:
The ubiquitous arrow depicts the flow between these abstractions. Process and Activity symbols
may have one of the following stereotypes:
• Manual, implying that the process/activity is totally manual (i.e., is done by the user and involves no interaction with a system).
• Automatic, implying that it is totally automatic (i.e., is done by the system and involves no further interaction).
• Semi-auto, implying that it is partially done by the user (e.g., checking paper forms) and partially by the system (e.g., the system checking certain calculations).
UML Process 23 Copyright © 2005 PragSoft
• Generated, implying that it is automatically generated by the system.
If no stereotype is specified then this means that the process/activity is performed through the interaction of the user with the system.