Background
Chapter 1 of Practical Guide to Project Management Information Systems, covering project management fundamentals, information systems, service-oriented architecture, and business process management as background concepts for PMIS.
1. Background
Project Management Framework
The Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a recognised standard for the project management profession worldwide. The fourth edition of this standard was published in 2008 by the Project Management Institute (PMI). In this standard, the evolved good practices of project management specialists who contributed to the development of this standard are presented. This standard provides guidance for managing individual projects, defines project management and the concepts related to it, and describes the project management life cycle and its processes. The contents of this section regarding project management have been adapted from this guide.
1.1.1 Project
According to the definition of the Guide to the Project Management Body of Knowledge, a project is a temporary endeavour undertaken to create a unique product, service, or result. The end of a project is achieved when the project objectives have been fulfilled, or when the project is terminated because its objectives cannot be achieved, or when the need for the further continuation of the project is no longer felt.
Every project produces a unique product, service, or result. Although repeatable components may exist in some of the project deliverables, this repetition does not change the fundamental uniqueness of a project.
1.1.2 Project Management
Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet the project requirements. Project management is accomplished through the appropriate application and integration of 42 project management processes, which are logically grouped into 5 process groups.
1.1.3 Project Management Processes
A process is a set of interrelated actions and activities performed to achieve a predetermined product, result, or service. Each process is characterised by inputs, tools and techniques, and outputs.
Project processes are performed by the project team and are generally categorised into the following two categories:
Project management processes: These processes encompass the tools and techniques for applying the skills and capabilities described in the project management knowledge areas.
Product-based processes: These processes define and create the project product. Product-based processes are typically defined by the project life cycle and vary by application area.
The PMBOK® Guide only describes project management processes and states that the product processes and project processes should be appropriately aligned and integrated with other processes by the project manager.
Project management processes are classified into five groups under the title of project management process groups:
- Initiating Process Group: Processes that are performed for defining a new project or a new phase of an existing project.
- Planning Process Group: Processes required for developing the project scope, refining the objectives, and defining the course of action required to achieve the project objectives.
- Executing Process Group: Processes that are performed for completing the work defined in the project management plan in order to satisfy the project specifications.
- Monitoring and Controlling Process Group: Processes that are required for tracking, reviewing, and controlling the progress and performance of the project.
- Closing Process Group: Processes that are performed to bring all activities across all process groups to an end and close the project or phase.
1.1.4 Project Management Knowledge Areas
The PMBOK standard has introduced 9 knowledge areas for the mastery of the project management team in order to manage projects effectively. These knowledge areas are as follows:
- Project Integration Management
- Project Scope Management
- Project Time Management
- Project Cost Management
- Project Quality Management
- Project Human Resource Management
- Project Communication Management
- Project Risk Management
- Project Procurement Management
In 2003, the Project Management Institute (PMI) added four other areas to the previous nine knowledge areas specifically for construction projects. These areas are as follows:
- Project Safety Management
- Project Environmental Management
- Project Financial Management
- Project Claim Management
Project Integration Management: The set of processes and activities required to identify, define, combine, collect, and coordinate all project management processes and activities within the process groups. This knowledge area comprises 6 processes.
Project Scope Management: The processes required to ensure that the project includes the work required, and only the work required, for the successful completion of the project. This knowledge area comprises 5 processes.
Project Time Management: The processes required for managing the timely completion of project activities. This knowledge area comprises 6 processes.
Project Cost Management: The processes related to estimating, budgeting, and controlling costs so that the project can be completed within the approved budget. This knowledge area comprises 3 processes.
Project Quality Management: The processes and activities within the project executing organisation that determine quality responsibilities, objectives, and policies in order to satisfy the needs that the project has undertaken to meet. This knowledge area comprises 3 processes.
Project Human Resource Management: The processes that organise, manage, and lead the project team. This knowledge area comprises 4 processes.
Project Communication Management: The processes required to ensure that project information is generated, collected, distributed, stored, retrieved, and finally summarised in a timely and appropriate manner. This knowledge area comprises 5 processes.
Project Risk Management: The processes of planning, identification, analysis, response planning, and monitoring and control of project risks. This knowledge area comprises 6 processes.
Project Procurement Management: The processes of purchasing or obtaining the products, services, or results required from outside the project team. This knowledge area comprises 4 processes.
Project Safety Management: The activities and processes performed by project sponsors, owners, or the organisation to determine safety objectives and policies aimed at preventing accidents, personal injury, death, or damage to property in the project. This knowledge area comprises 3 processes.
Project Environmental Management: The set of activities and processes performed by project sponsors, owners, or the organisation to determine objectives and policies so that project activities have the least possible impact on the environment and nature. This knowledge area comprises 3 processes.
Project Financial Management: The set of activities and processes for managing the financial resources of the project and comparing them with budget management, with a focus on revenue sources and monitoring cash flow for the daily activities of the project executing section. This knowledge area comprises 3 processes.
Project Claim Management: The processes aimed at preventing claims during construction, reducing their impacts if they occur, and administering such claims quickly and effectively. This knowledge area comprises 4 processes.
The project management processes within each knowledge area are summarised in the following table:
1.1.5 Project Manager
A project manager is an individual appointed by the organisation to achieve the project’s objectives. The role of a project manager differs from that of a functional manager or an operations manager. In addition to the specific skills of each field and the general management expertise required for the project, a project manager must possess knowledge of project management and apply it in practice. Furthermore, a project manager requires personal characteristics including leadership, the ability to guide the project team, personal effectiveness, and an appropriate manner of dealing with people.
1.1.6 Enterprise Environmental Factors
Enterprise Environmental Factors (EEF) are external and internal environmental factors that influence the success of the project. These factors may originate from all business parties participating in the project. These factors may constrain or expand project management options and may have either a positive or negative effect on the project outcome. Enterprise Environmental Factors are considered as inputs in most planning processes.
Enterprise Environmental Factors, which are not limited to the following, include:
- Organisational structure, culture, and processes
- Industrial or governmental standards
- Infrastructures
- Available human resources
- Market conditions
- Political conditions
- Communication channels established within the organisation
- Project information systems
- Commercial databases
1.1.7 Project and Product Lifecycles
The project lifecycle is a set of phases in a project that are generally sequential and sometimes overlapping. The names and number of these phases are determined by the control and management needs of the organisation or organisations involved in the project, the inherent nature of the project, and its application domain. The lifecycle can be documented using a methodology. The project lifecycle can be defined or shaped according to the unique aspects of the organisation, the industry, or the technology being used. While every project has a clearly defined beginning and a clearly defined end, the specific activities and deliverables that occur between them vary widely from one project to another. The lifecycle provides a fundamental framework for project management, irrespective of the type of work involved.
The product lifecycle is a set of product phases that are generally sequential and non-overlapping and are determined based on the control and production needs of the organisation. The final phase of the product lifecycle is generally the death of the product. The project lifecycle is situated within one or more phases of the product lifecycle.
1.1.8 Organizational Process Assets
Organizational Process Assets (OPA) include all or part of the organisation’s process-related assets that exist within the project and can be used to influence the success of the project. These process assets include formal and informal plans, policies, procedures, and guidelines. Process assets also include the organisational knowledge base, such as lessons learned and historical information. Organizational Process Assets may include completed schedules, risk data, and earned value data. Organizational Process Assets are divided into the following two categories:
1- Processes and Procedures:
These include all standard organisational processes, work guidelines and instructions, templates, organisational communication requirements, defect management procedures, change control procedures, risk control procedures, and other organisational processes and procedures.
2- Shared Knowledge Base:
The organisational shared knowledge base is used for storing and retrieving organisational information, including process measurement databases, project files, the lessons learned knowledge base, problem management databases, the configuration management knowledge base, financial databases, and other shared organisational information.
Introduction to Information Systems
An information system can, from a technical point of view, be regarded as a set of interrelated components that collect or retrieve, store, process, and distribute information. In this way, it supports correct decision making and controls the organisation. In addition, besides supporting decision making, coordination, and control, an information system helps managers and employees analyse problems and properly resolve complex issues.
Information systems contain information about important people, places, and objects within the organisation or in its surrounding environment. Information refers to data that has been shaped in such a way that it becomes meaningful and useful to human beings. In contrast, data is a set of raw, unprocessed facts that represents events occurring in organisations or physical environments before being organised and arranged in a form that can be understood and used by humans.
To clarify the difference between information and data, the following simple example can be presented. You may be among those who, every day when entering or leaving your workplace, use what is commonly called a card to register your attendance. This is an identification card that recognises you by means of a barcode, magnetic card, or fingerprint and records your entry and exit information. Each time you register your attendance, only three pieces of data are stored:
1- Card number or employee number
2- Date and time of card registration
3- Card reader device number
These data by themselves do not provide useful information; however, when they are analysed and processed within a software application, they can generate reports on your working hours, overtime, and absences.
Three main activities exist in every information system. These activities are: input, processing, and output (Figure 1.4).
Input collects or receives raw data from the organisation or from its external environment. Processing converts this raw input into a meaningful and usable form. Output transfers the processed information to the individuals who are supposed to use it or to the activities in which it is supposed to be used. In addition, an information system also requires feedback. Feedback refers to output that is returned to the relevant members of the organisation in order to help them evaluate or correct the input stage. Environmental factors such as customers, suppliers, competitors, shareholders, and regulatory organisations interact reciprocally with the organisation and its information systems.
1.2.1 Dimensions of Information Systems
An information system is not merely technology. To gain a better understanding of information systems, one must become familiar with their different dimensions, namely organisation, people, and information technology (the figure below), and be aware of the power of these dimensions in providing solutions to business problems and challenges. An understanding of information systems is called Information Systems Literacy, and this differs from Computer Literacy, which is essentially based on knowledge of information technology.
Organisations:
Information systems form the central core of organisations. Although it is often assumed that information technology is what changes organisations and companies, this relationship is in fact a two-way relationship. The culture and maturity of organisations have a direct influence on the way technology is used. Organisations usually have a hierarchical and pyramid-shaped structure in which authority and responsibilities are defined and separated. The upper levels of this pyramid consist of managers and specialists, while the lower levels consist of operational employees. Organisations specify and organise work through this structure as well as through business processes. Business processes refer to tasks and behaviours that are logically interrelated and are used to complete work, such as recruiting a new employee, purchasing a product, and procuring materials and equipment.
Most business processes are usually formal procedures that have been developed over time to perform specific tasks. Some of these procedures have been compiled in written form, while others exist as informal work practices, such as negotiations conducted by employees of the purchasing department with vendors, which do not require written documentation. Information systems can automate a large portion of business processes. For example, an accounting document is automatically generated in the company’s financial system after the issuance of a sales invoice.
Every organisation has a unique culture, or a set of values, assumptions, and methods of performing work that are accepted by most members of that organisation. A large part of an organisation’s culture is embedded in its information systems.
People:
Every business depends on people who have experience in it and who carry out its activities. In the case of information systems as well, the role of skilled individuals who create and support these systems is very important and decisive. These systems are useless without people who know how to use information in order to achieve business objectives. The role of managers in each organisation is crucial in this regard. They must make use of knowledge, information, and modern technologies and employ creative approaches to use information technology as a competitive advantage in competing with other competitors. On the other hand, the support and understanding of organisational managers regarding the impact of information systems is considered one of the determining factors in the success of these systems. The level of participation of employees at different levels of the organisation is another influence that people can have on information systems and mechanisation. Without the cooperation and participation of employees, the implementation of information systems in organisations will be impossible and will only lead to the waste of organisational resources.
Technology:
Technology refers to the methods and techniques used for creating and applying tools, devices, materials, and processes that help solve human problems. On this basis, the term technology often refers to innovations and new tools that make use of newly discovered scientific principles and processes. Examples include computer hardware, data management technologies, network technologies, and telecommunications technologies. All these technologies, together with the human resources required to implement and manage them, constitute resources that can be shared throughout the organisation and thereby form the organisation’s information technology infrastructure. The information technology infrastructure provides the foundation upon which an organisation can build its specific information systems.
A very important point is that until the people within an organisation—at all levels, from top management to operational levels—develop and mature, organisational culture will not take shape and the organisation’s working routines, which are essentially the processes through which work is carried out, will not progress. This is because people drive process development, and until people and processes develop, information technology alone cannot foster organisational growth and advancement. Unfortunately, a common misconception among many organisations and individuals is that information technology alone can bring about transformation in an organisation.
1.2.2 Types of Information Systems
Information systems can be classified from different perspectives, such as the type of application, the type of information, or the components that constitute them. One type of classification is based on the components forming these systems, which clarifies how these systems relate to different levels of management and the types of decision-making associated with them.
Transaction Processing Systems (TPS):
A Transaction Processing System is a computer-based system that executes and records the routine daily transactions required to run a business. These systems usually support operational managers. The primary objective of systems at this level is to answer everyday questions and to track transaction routines within the organisation. For example, questions such as how many accounting documents exist in the accounting system, or what the current status of payments is. Answers to such questions can easily be obtained from current transaction data. Transaction Processing Systems are extremely important and vital, and even a few hours of malfunction in these systems may result in the stoppage of a company’s activities.
Management Information Systems (MIS):
These systems constitute a part of information systems that support the performance of middle managers. These systems prepare reports on the current performance of the organisation for middle managers. This information is used to monitor and control business performance and to forecast future performance. MIS summarises the basic operations of the organisation using data supplied by TPS and presents the results in the form of reports. Initial transaction data are condensed and are usually presented in lengthy reports prepared at regular intervals. MIS assists managers in reviewing weekly, monthly, and annual results through the relevant reports. Most MIS use simple routines such as summaries and comparisons rather than complex statistical techniques or mathematical models.
Decision Support Systems (DSS):
These systems are developed to respond to the unexpected and more complex questions of middle managers. These types of systems focus on problems that are unique and change rapidly, where the procedures for their solution have not been fully defined in advance. They attempt to answer questions such as: “If we double sales in the month of Bahman, what effect will this have on production scheduling in the previous months?” or “If there is a delay in the supply of raw materials, what impact will this have on sales scheduling in the following months?”
DSS utilize both internal information related to TPS and MIS and information obtained from external sources. External information includes items such as the current prices of stocks or foreign currencies, or the prices of competitors’ products. These systems employ various models to analyse data or compress large volumes of data in such a way that they can be analysed by decision makers. DSS are designed so that users can work with them directly. For this reason, they must be equipped with features that make their use very simple for users.
Executive Support Systems (ESS):
These systems help senior managers obtain information on strategic issues and long-term trends both within the company and in the external environment. Answering questions such as which products should be produced over the next five years, or what the employment levels will be in the coming five years, falls within the scope of ESS. These systems are effective for decisions that are not routine and require significant judgement, evaluation, and thought. In addition to external information, these systems can also extract summarised information from MIS and DSS. They filter, compress, and track critical data, and emphasise reducing the time and work required to obtain useful information for executive actions.
Relationship among the Systems:
The systems that were examined are interconnected. TPS serves as the primary source of data for the other systems, while ESS receives data from the lower levels beneath it.
1.2.3 Enterprise Applications
That all the different systems can work together in a company is a major challenge. Large companies are usually formed either through organisational growth or through the merger of smaller companies. Over time, large companies come to possess a collection of systems, most of which are old and can communicate with one another only with difficulty and can function as an integrated system only with difficulty. Several solutions exist to solve this problem. One solution is the implementation of Enterprise Applications (EA), which are systems distributed throughout all areas of the organisation, focus on the execution of business processes across the company, and include all levels of management. Enterprise applications help enterprises gain greater flexibility and creativity. These applications bring business processes closer together and integrate groups of processes in order to perform resource management and the delivery of services to customers more effectively.
Enterprise applications are of different types. Some of these types include Enterprise Systems (ES), Supply Chain Management Systems (SCM), Customer Relationship Management Systems (CRM), and Knowledge Management Systems (KM). Each of these enterprise applications integrates a set of functions and processes related to business in order to improve the performance of the organisation as a whole. Figure 1.8 shows the architecture of these enterprise applications. This architecture includes the processes of the entire organisation and, in some cases, even extends beyond the organisation to customers, suppliers, and other business partners.
Enterprise Systems
Large organisations usually have different types of information systems that are built from different functions, organisational levels, and business processes, and they cannot automatically exchange information. Managers face many difficulties in bringing together the data required to obtain an overall and comprehensive view of the organisation’s functions. For example, employees responsible for orders and purchasing in projects may not be able to determine whether an item required for a project exists as surplus in the company warehouse or in other projects. Requesters of goods cannot track the goods they have requested. This scattering of data across hundreds of separate systems will have a negative effect on organisational efficiency and business performance.
One of the types of enterprise systems is known as Enterprise Resource Planning (ERP) systems. In these systems, data from different business processes in the areas of manufacturing and production, finance and accounting, sales and marketing, and human resources are collected and stored in a central data repository. In this way, information that was previously scattered across different systems can be shared throughout the company and help different parts of the business work better together. Enterprise applications can automate processes that are scattered across business functions and organisational levels and may even extend beyond the organisation. Enterprise systems can integrate the core business processes of the entire company into a single software system so that they flow continuously throughout the organisation. These systems essentially focus on internal processes, but they may also include transactions with customers and suppliers.
Supply Chain Management (SCM) Systems
These systems help enterprises manage their relationships with suppliers. These systems provide information facilitating the sharing of information among suppliers, purchasing companies, distributors, and logistics companies regarding orders, production, warehousing, and the delivery of products and services. In this way, they can perform sourcing and produce and deliver products and services more efficiently. The ultimate objective is to receive the appropriate quantity of products from the source and deliver them to the point of consumption in the shortest possible time and at the lowest possible cost.
Customer Relationship Management (CRM) Systems
These systems help companies manage their relationships with customers. CRM systems provide information to coordinate all business processes related to the sales, marketing, and customer service departments and improve revenue, customer satisfaction, and customer relationships. This information helps companies identify their most profitable customers, attract more of them, and strive to retain them. They also provide better services to customers in order to increase sales. These systems are useful for organisations that have a large number of customers and for which maintaining and managing customers without tools is difficult. Industrial companies and executors of large projects usually make less use of such systems.
Knowledge Management (KM) Systems
The value of a company’s products and services is not based only on physical resources, but is also related to intangible knowledge assets. Some companies perform better than others because they possess better knowledge about the way of creating, producing, and delivering products and services. This knowledge is highly unique and cannot be reconstructed, and it can be used to achieve long-term strategic advantages. Knowledge Management Systems enable organisations to better manage the processes of acquiring and applying knowledge and expertise. These systems collect all knowledge and experiences related to the company and make them available at the appropriate time and place. In this way, business processes can be improved and better managerial decisions can be made. In addition, these systems connect the company to external sources of knowledge.
KMS use processes for the acquisition, storage, distribution, and application of knowledge, as well as processes for creating new knowledge and integrating it within the organisation. For example, systems for managing and distributing digital documents, systems for creating a company knowledge directory of all employees who possess specialised expertise, and systems for facilitating the creation of knowledge within the organisation are among such systems. Some systems codify knowledge for use by organisational members and use methods and tools that discover knowledge and manage important patterns and relationships within the organisation’s repositories.
Service-Oriented Architecture
Service-Oriented Architecture (SOA) is an approach for building distributed systems that provides software functions in the form of services. These services can be invoked by other software applications and can also be used for building new services. This approach is ideal for the integration of technologies in environments where different types of software and hardware platforms exist. The characteristics of Service-Oriented Architecture are as follows:
- The use of technology-independent and agreed-upon standards for providing software components in the form of services
- It is both a technical subject and a style of thinking
- It introduces a specific and agreed-upon method for defining and establishing communication between software components in the form of services
- It reinforces the approach of assembling pre-defined components for building software instead of redeveloping and reimplementing
- Quality-of-service indicators (security, performance, integration style, etc.) are clearly defined and measured for each service
- Systems can connect to services outside the organisation in the same way as to internal ones
Service-Oriented Architecture from Different Perspectives
Service-Oriented Architecture can be examined from different viewpoints. Each individual or stakeholder, according to their position, holds an image of Service-Oriented Architecture. The following three perspectives—those of Information Technology Managers, Business Managers, and System Designers and Implementers—are presented:
Information Technology Managers:
An architectural style that contains rules, patterns, and principles leading to the creation of characteristics such as modularity, encapsulation, loose coupling, reusability, and composability, and which, from a structural point of view, consists of a service provider and a service requester.
Business Managers:
A set of services that the organisation intends to offer to its customers or partners.
Designers and Implementers of Information Systems:
A programming style that uses agreed-upon, technology-independent standards and supports interoperability between software components, irrespective of the platform and technology of their implementation.
1.3.1 Definitions of Service-Oriented Architecture
Diverse and sometimes differing definitions have been proposed for Service-Oriented Architecture, each explaining its characteristics from a particular viewpoint. To better understand this concept and to be aware of all existing interpretations and perspectives, several of these definitions are presented below:
-
A broad and standard framework within which services are built, deployed, and managed, aiming to enhance the agility of information technology in order to respond rapidly to changes in business needs.
-
A style of information systems architecture whose goal is to achieve loose coupling in communications between software components. Loose coupling between software components leads to their reusability. A service, in this context, means the software implementation of a well-defined business function that can be used and invoked in various processes or software.
-
Service-Oriented Architecture is not a product but a bridge between profession and technology, facilitated by a set of technology-based services that possess distinct rules, standards, and design principles.
1.3.2 Characteristics of Service-Oriented Architecture
Table 1.1 presents a comparison between the service-oriented approach and previous approaches.
In summarising the points that were mentioned regarding the definition of Service-Oriented Architecture and its characteristics, the characteristics of Service-Oriented Architecture can be stated in a concise form in Table 1.2.
1.3.3 Principles of Service-Oriented Design
Service-Oriented Architecture is a design for connecting computing resources. These computing resources include data and application programs. Service-Oriented Architecture is used to organise capabilities and resources on a network. These resources and capabilities are located on independent and separate platforms and domains.
Service-Oriented Architecture emphasises the service as a coarse-grained, independent, and complete software unit, whereas in object-oriented architecture the emphasis is on objects. An object is a fine-grained software unit that is largely complete, and its implementation is separated from its interface, but its relationship with other objects is cohesive and strong. This strong relationship provides power in execution; however, it also causes complexity and prevents the easy expansion of programs. Moreover, the strong dependency of objects on one another and their dependence on communication code make software development difficult. These issues have been taken into consideration in service-oriented design.
The most important concepts and principles considered in service-oriented design are as follows:
- Service Encapsulation: emphasises concentrating operations related to data within a specific unit (capsule) and hiding the implementation and the mechanism within the software unit.
- Loose Coupling between Services: emphasises the independence of services and the reduction of dependencies among them. It is only necessary that services be aware of each other’s existence.
- Service Contract: communication between services is based on a defined contract that is explicitly stated in technical documentation.
- Service Abstraction: emphasises separating the implementation from the interface (the external world) and hiding the mechanism and the manner in which the work is performed within the service provider unit.
- Service Reusability: emphasises designing services in such a way that they can be used in different systems, with greater emphasis on reuse.
- Service Composability: means that services should be designed in such a way that, through the capability of composition, the creation of composite services becomes possible.
- Service Autonomy: refers to the capability and authority of a service to utilise and manage its own resources independently, as well as full control over its implementation logic.
- Statelessness: means that a service should retain the minimum possible information about past activities (previous invocations), and emphasises designing services in such a way that they have minimal dependence on past states.
- Service Discoverability: means that a service should be made visible within a network environment through appropriate mechanisms so that it can be discovered by other applications.
1.3.4 Web Services
The terms Service-Oriented Architecture and Web Services are usually mistakenly used in place of each other and as equivalents. Therefore, it is necessary that these two concepts be examined more precisely. Web Services should be considered a type of technology for realising the feature of platform independence in Service-Oriented Architecture.
Definition of a Web Service: A Web Service is a type of software system that is designed for machine-to-machine interaction at the network level and has a machine-processable definition called WSDL. Other systems will interact with the service provider according to this description prepared in advance. Messages are transferred by the SOAP protocol (the combination of HTTP with XML) or other similar protocols. A Web Service must have the following conditions:
- It must be accessible on the Web.
- It must use the XML standard for information exchange.
- It must not be dependent on any platform or operating system.
- It interacts with servers and systems, not users.
- It must be self-describing.
- It must be identifiable (for use by service consumers, it must first be registered and then identified).
1.3.5 Orchestration and Choreography in Service-Oriented Architecture
Two widely used terms in the field of Service-Oriented Architecture are Orchestration and Choreography.
Orchestration refers to the sequencing of services within a process. The orchestrator, which is responsible for leading the group, invokes a set of services so that the desired outcome is achieved and the process is completed. Services outside the organization may also be invoked and used for this purpose. This is achieved with the help of a process engine. Conversely, Choreography refers to processes that exchange messages without a process engine (conductor), in which the actors themselves record and control the order and sequence of the exchanged messages.
In Orchestration, a central controller distributes the workflows among several actors (services, users, systems, etc.). One of the applications of this concept is the decomposition of large processes into smaller components, such that these components operate under the supervision of the main orchestrator and their results are sent to that same orchestrator. This reduces the complexity of the work. Thus, the workflow logic is maintained separately in BPEL notation, and its extension and modification become easier. Service components should have no knowledge of the main workflow logic. They only respond to the orchestrator’s requests, and each component is considered a self-contained and independent unit.
Orchestration contributes to Information Technology agility in three ways:
- The workflow logic, which is maintained separately by the orchestrator, is more easily extensible and modifiable, and changing it will have no effect on the implementation of the invoked services.
- Performing orchestration causes the workflow logic and the related state to be removed from each component; therefore, these components have a greater chance of being reused in other orchestrations.
- The use of orchestration on a wide and pervasive scale for organizations whose type of business is federated (organizations that are not themselves directly responsible for providing services to customers, but instead distribute tasks among a set of companies or contractors) brings high alignment and flexibility to Information Technology.
1.3.6 Applications of Service-Oriented Architecture
- Integration of Information Systems: One of the applications of Service-Oriented Architecture for the integration of information systems is the communication between information systems by means of Web Services. Since the late 1990s, solutions have been proposed for the interoperability challenge of information systems, the most well-known of which are point-to-point connection and integration based on a central translator.
In the point-to-point mode (Figure 1.10), for every interaction between two information systems, a specific standard and communication path must be provided. Naturally, such a method would be very costly and cumbersome.
In the central translator mode as well, middleware acted as a translator among all information systems in such a way that, like a central hub, all messages sent were referred to this intermediary and, after being translated into the protocol and technology related to the second system, were transmitted to it (Figure 1.11).
This option was also accompanied by difficulties, the most important of which were heterogeneous protocols and lack of comprehensiveness. However, in Service-Oriented Architecture the principle is that all information systems interact through a standard and universally agreed-upon interface. This interface is called a service (Figure 1.12), and the protocols used for it include SOAP, WSDL, and XML. The exchange of services between information systems is carried out through the Enterprise Service Bus (ESB).
- Integration of Organizational Process Automation through Orchestration
Service-Oriented Architecture makes use of orchestration for the management and execution of organizational processes. In this method, the process logic and workflow are decoupled from its activities, in such a way that the process workflow is managed in the form of BPEL. However, each of the process activities can be implemented by different information systems. In this way, it becomes possible to change the workflow without the need to modify the supporting systems, which greatly contributes to technological flexibility in responding to business changes.
Figure 1.13 shows how a process that is connected to three information systems is implemented by the BizTalk Server tool. In this example, each system has its own technology and standards. An interesting point is that the information systems used for the automation of the said process are not aware of the existence of the process, its flow, and its rules. They merely respond to the messages that are sent. This separation of process logic from the automation of its activities makes the implementation of new processes and the modification of existing processes easier, which is of high value for organizations.
- Inter-organizational Interoperability
Although the communication and integration of an organization’s information systems is necessary, inter-organizational interoperability is even more important and more difficult. This is because the diversity of technologies and protocols across multiple organizations is far greater than that among the internal systems of an organization. Under new economic and business conditions, organizations need to effectively use one another’s information. On the other hand, inter-organizational processes are expanding. Trade, which in the past was organizational and domain-based, is now moving toward being global and ecosystem-based, and determining geographical boundaries and size for organizations has become difficult. Under such conditions, the need for the exchange of information among organizations is strongly felt.
The Service-Oriented Architecture solution for this domain is the use of standard Web Services that can be identified and invoked on the Internet network. In order to use these Web Services, they must first be identified by requesters. For this purpose, a directory for service registration and discovery (UDDI) has been created. Service providers register the specifications of their services in these directories, and requesters, by searching for their desired service—like web page search engines—can use these services in their organizations. The result of this is the possibility of effective interaction with other organizations (partners, competitors, and customers), which is provided through various services (Figure 1.14).
1.3.7 Benefits and Outcomes of Service-Oriented Architecture
Based on the preceding discussion, the advantages and benefits of Service-Oriented Architecture can be expressed in the following points:
- Agile systems: Service-Oriented Architecture enables an organization to rapidly modify its systems. This agility applies both to system functionalities and to geographical changes, platform upgrades, and even changes in technology providers.
- Reusability: The reuse of program code or systems has long been considered in software production and development methods. Service-Oriented Architecture provides the capability of reuse both at the service level and at the data level.
- Easy integration with internal and external partners: It can be stated that the capability of integrating systems and platforms is one of the key points addressed by Service-Oriented Architecture.
- Improved return on investment: Service-Oriented Architecture reduces the total amount of costs spent on information technology and business services in two ways. First, by eliminating the costs of middleware and proprietary technologies and replacing them with standard technologies such as Web Services; and second, by combining business functionalities in the form of services that can be used by different units.
- Alignment of information technology with business: The goal of Service-Oriented Architecture is the software implementation of a business service with the capability of reuse and flexibility. Therefore, software services in Service-Oriented Architecture are nothing more than the realization of those business services in the information technology platform.
- Flexibility and ease of switching from one service provider to another: Flexibility in Service-Oriented Architecture applies to services both inside and outside the organization.
Business Process Management
1.4.1 Definition of Business Process Management
- Gartner’s definition: Business Process Management (BPM) refers to the design, execution, and improvement of cross-functional activities that connect people, information systems, and business partners.
- BEA’s definition: A strategy for managing and improving business performance through the continuous optimization of business processes within a closed-loop cycle of modelling, execution, and measurement.
- From the perspective of Paul Harmon, BPM is: “a management discipline that focuses on improving organizational efficiency through the management of business processes.”
- From the perspective of Brocke and Rosemann: “BPM is a management approach based on the alignment of all aspects of an organization with customer demands and needs.” It is a comprehensive management approach that promotes business efficiency and productivity and uses technology for innovation, flexibility, and integration.
- Definition of the Association of BPM Professionals: Business Process Management is a systematic approach for identifying, designing, executing, documenting, monitoring, controlling, and measuring manual and automated business processes in order to achieve targeted results consistent with the organization’s strategic goals. BPM includes the definition, improvement, innovation, and management of end-to-end business processes in a deliberate, collaborative, and increasingly technology-driven manner; processes that lead to business results, create value, and enable the organization to achieve its business objectives with greater agility.
In general, a review of the literature on this subject shows that the term BPM is used in at least the following four meanings, each of which can be considered a distinct perspective on BPM:
- BPM as a managerial approach
- BPM as a software technology
- BPM as a method for developing application systems
- BPM as a pattern of enterprise application integration
The objective of BPM is the continuous improvement of organizational processes; from another perspective, it is the process of optimizing the organization’s processes. From this perspective, BPM manages changes far more capably, effectively, and efficiently than the traditional hierarchical organizational view.
A case study conducted by Cole Bakker in 2009 shows that BPM contributes to increased customer satisfaction, improved product quality, and accelerated product time-to-market.
Therefore, process management constitutes only a part of the general management of the organization, and it is important for the management and leadership of the organization to understand that there is no finish line in the improvement of business processes; BPM should therefore be regarded as a continuous programme.
BPM is not equivalent to a technological tool or an initiative for business processes. Experience shows that significant improvements in business processes can be achieved even without the use of technology. However, can BPM include technology, and is technology a suitable tool for BPM? The answer to this question is certainly positive, but only within an appropriate environment, under appropriate conditions, and at a justifiable time.
Are process modelling and managerial tools useful for improving processes without the use of technology? If by tools we mean process modelling tools, the answer is yes. These tools are very useful in the implementation of BPM, and it can be said that the completion of process improvement projects is not possible without the use of these tools at the appropriate time.
However, a danger that can befall all organizations is that an organization may mistakenly believe that by purchasing a process modelling tool, all problems will be solved and process improvement will occur automatically. Yet a process modelling tool is merely a part of a software system and, without a methodology, a framework, and skilled human resources capable of using this tool, it is useless.
Many vendors and providers of software solutions in the industry have defined BPM in such a way that technology (automation tools) is considered one of the essential components of Business Process Management. In other words, according to their view, BPM means technology. However, with a simple and logical view, it can certainly be concluded that BPM is related to the better management of processes and not to technology.
In general, it can be said that BPM:
- is more than merely software.
- is more than simply process improvement and process reengineering, and it is also related to managerial issues and challenges.
- is not merely an enthusiasm, and it is a part of the general management of the organization.
- is more than merely process modelling and also includes the implementation and execution of these processes after analysis.
1.4.2 Benefits of Business Process Management
BPM, in addition to automating workflow, provides other capabilities as well. These capabilities enable organizations to control a greater number of processes. Some of the benefits of using BPM are as follows:
- Documentation and definition of processes: Standards such as BPMN provide the possibility of documenting and defining processes.
- Automation of process execution: With BPM, all business rules and business logic of the organization are automated.
- Identification of opportunities and process improvement: BPM also provides metrics for measuring process costs and execution time, in which case optimization is based on real results.
- Elimination of unnecessary activities: In BPM, with the help of process modelling, organizations can obtain opportunities to eliminate unnecessary tasks.
- Control of the performance of running processes: Through monitoring tools, BPM makes it possible to monitor the status of processes. As a result, this control leads to the stability and consistency of processes in order to achieve higher quality and optimize them for greater efficiency. In addition, the ability to measure them provides a better managerial view.
- Collaboration of customers and business partners in business processes: BPM provides the possibility for the collaboration of customers and partners from outside the organization. Therefore, it is highly useful for processes that exist outside the organizational boundary.
- Reduction of required resources: Business processes require many people and resources in order to be executed. BPM can reduce the number of resources required for a process.
- Improvement of coordination: BPM improves coordination between different parts of a company from a geographical perspective.
- Increase in the speed of process cycle execution: By reducing process execution time and enabling their parallel execution, BPM improves the speed of business operations.
- Increase in customer satisfaction: By reducing execution time and ensuring correctness, customers can reach their requirements more quickly and easily.
- Organizational agility: BPM enables organizations to easily apply changes to processes when conditions change. In this way, it helps maintain the organization’s position in a competitive market.
1.4.3 BPMS Software
Historically, BPMS software has emerged from the integration of two families of software products. The first category, often referred to as Human-centric BPM, represents the evolution of software that was originally used for document management and the circulation of internal correspondence within organizations. These software systems have a long history, and the formation of their market dates back to the second half of the 1980s. With the addition of various collaboration capabilities to correspondence workflow software, and with the emergence of workflow management technology and its integration into these software systems, an independent market known as workflow management software emerged in the second half of the 1990s.
On the other hand, Enterprise Application Integration (EAI) technology, which was introduced in the mid-1990s and rapidly evolved toward the integration of automated processes, represents another source of BPMS software that is usually referred to as Integration-centric BPMS.
The difference between these two types of BPMS is that human-centric software is mainly used to automate manual processes and to establish communication among employees within an organization, whereas integration-centric software has been used to connect automated systems within process flows. Around 2002, these two approaches converged within the BPMS market and have grown significantly in recent years. Today, most leading companies in this field, regardless of whether their original approach was human-centric or integration-centric, attempt to cover all aspects of human and machine interaction in their solutions.
1.4.4 Architecture and Components of BPMS
Although there is still no uniform definition among BPMS software providers regarding the standard architecture and components of these systems, and each company proposes its own architecture, it is nevertheless possible, by synthesizing the characteristics of the software solutions offered by these companies, to identify a relatively comprehensive pattern of the components of a BPMS software system.
The components of a BPMS solution can be considered as illustrated in the following diagram:
Not all BPMS packages include all of the components mentioned. However, in general, the components that are usually provided in such packages are as follows:
- Process modeling tools – Process Modeling
- Process model repository – Process Repository
- Workflow engine – Workflow Engine
- Process monitoring and analysis tools – Process Analytics
- Business Rules Engine – Rule Engine
- Application integration tools – Legacy Connector (EAI)
- Process templates – Process Template
- Portal development tool – Portal
- Content management tools – Content Manager
PMIS Framework and Overview
Continue to Chapter 2 for PMIS definition, positioning, and framework concepts.