Process-Centric Architecture for Enterprise Software Systems

Parameswaran Seshan

• Publisher: Auerbach Publications
• Year: 2010
• eBook ISBN: 9781439857106
• Topic: Business
• Subtopic: Information Management
• Index: Business

The increasing adoption of Business Process Management (BPM) has inspired pioneering software architects and developers to effectively leverage BPM-based software and process-centric architecture (PCA) to create software systems that enable essential business processes. Reflecting this emerging trend and evolving field, Process-Centric Architecture for Enterprise Software Systems provides a complete and accessible introduction explaining this architecture. The text presents, in detail, the analysis and design principles used in process-centric architecture. Illustrative examples demonstrate how to architect and design enterprise systems based on the business processes central to your organization. It covers the architectural aspects of business process management, the evolution of IT systems in enterprises, the importance of a business process focus, the role of workflows, business rules, enterprise application integration, and business process modeling languages such as WS-BPEL and BPML. It also investigates: Fundamental concepts of process-centric architecture style The PCA approach to architecting enterprise IT systems Business process driven applications and integration Two case studies that illustrate how to architect and design enterprise applications based on PCA SOA in the context of process-centric architecture Standards, technologies, and infrastructure behind PCA Explaining how to architect enterprise systems using a BPMS technology platform, J2EE components, and Web services, this forward-looking book will empower you to create systems centered on business processes and make today's enterprise processes successful and agile.

I

THE PROCESS-CENTRIC ARCHITECTURE PARADIGM

Chapter 1

Introduction

1.1 Objectives

■ To get an overview of IT system architecture

■ To understand what business processes are, at a high level

1.2 Enterprise Software Systems

Enterprise software systems are software-intensive systems in an enterprise. They support business functionalities for the enterprise by performing business functions, and their scope is wider than a specific business function. They are also called information technology (IT) systems in the enterprise. We will be using these two terms (IT systems and enterprise software systems) interchangeably throughout the book and they should be taken to mean the same. These systems can be in-house developed ones or packaged software. The word enterprise as used here is regardless of the size of the enterprise—the word applies equally to small, medium, and large organizations.

An IT system comprises of applications, system software (including middle-ware), data, and hardware. Examples of IT systems in enterprises include transaction processing systems, supply chain management systems, manufacturing support systems, management information systems, customer relationship management systems, customer information management, billing, finance systems (or accounting systems), core banking systems, human resources (HR) management systems, trading systems, office systems, decision support systems, online shopping, enterprise resource planning systems, online payment processing, and knowledge management systems. The term “IT system” has a bigger scope than the term “application”—using the term we take a full system view of specific software such as a customer relationship system.

An IT system may comprise more than one application in its scope. Applications are software that support a specific business work or a user of the software. They refer to the usage of computer by users and the use of computer for various needs of the enterprise. Applications provide business functionality and their focus is only on making use of the capabilities of the computer to perform a function for users. Examples are travel expense management, IT helpdesk, word processors, web browsers, etc. Applications are written on top of system software.

Data refers to all the business data associated with the various business functions performed by the applications. Data is a separate entity since it has a separate existence and varied use beyond the application that created it. Examples of data are customer data, product data, employee data, sales data, etc.

Hardware is the physical aspect of the system or IT. Computing machines such as computers, servers, and mainframes, and networks and equipments such as routers, storage disks, etc., are all part of the hardware for the IT system.

1.3 Architecture for Systems

Architecture is a term that is growing in relevance in the computer software world. It has been a well-established concept in the civil engineering world though. While there is no common agreement on its definition, as of today, the following definition from IEEE 1471 has been adopted by many—“Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution.” Here, the system can be an information technology (IT) system, an enterprise, a division of an enterprise, and so on. In this book, we use the term “IT systems” to inclusively refer to software and information technology systems.

1.3.1 IT Architecture

IT architecture is a term that has an enterprise-wide or a department-wide scope and is associated with the organization. IT architecture is the architecture of IT in an organization. It is also referred to as the enterprise IT architecture, in the case of an enterprise scope. It is the structure of the enterprise organized purely in terms of the various IT systems in the enterprise, how those IT systems relate to each other, and how they relate to the business aspects of the enterprise. All the IT systems in the enterprise structurally fit into the IT architecture of the enterprise. IT architecture includes the structure of the data in the organization, both logical and physical, the infrastructure capabilities (such as hardware, middleware, networking, communications) that are required to support the various systems across the enterprise in a common and horizontal way.

1.3.2 IT System Architecture

IT system architecture is the architecture of an IT system. It is the organization of the IT system as functionality components, infrastructure components, and data components, their interactions with each other to realize the business objectives of the system, and reflects the principles and design decisions made on the system as a whole. It thus includes the data, infrastructure capability, and functionality parts of the system. It defines the structure of the IT system as comprised of its components, how they interact with each other, and the external properties they exhibit, and enables inferencing on the quality exhibited by the IT system as a whole in its behavior. It determines and specifies how multiple applications that are part of the IT system are to work together—how they would interact with each other.

IT system architecture is the key to realizing the functional requirements and quality attributes* of the system—it primarily determines whether and how well the system meets its stated business functionality and quality goals. “Quality attributes” are properties of the system such as usability, modifiability, maintainability, interoperability, performance, reliability, and availability. The stakeholders^† of the system have different concerns related to the IT system, and these become the properties that the system needs to guarantee. Properties here can be functional and quality based. The need of the system to meet or satisfy these properties primarily influences the design of the architecture of the IT system.

The architecture of a system is described in multiple views, each one from a different perspective. The views considered would need to cover the business perspective and the technical perspective of the IT system to make it more complete.

1.3.3 Architectural Styles and Patterns

An architect creating the architecture for an IT system is often faced with design problems to address, forces to handle, or constraints acting upon the system; for example, “how to ensure the system’s performance (time-efficiency)” or “how to enable it to become scalable” are some architectural design problems. There are patterns in the solutions to typical architectural design problems and they have collectively become architectural patterns. The idea is to reuse the solutions that have been applied in similar or other architectural design contexts and apply them to solve the current architectural design problem at hand. Patterns are template solutions to repeating problems occurring in a different space. Patterns are not full architectures of any system, but they are used in creating architectures for a system by applying the pattern to the context of the system. For example, pipes and filters is an architectural pattern that solves the problem of partitioning a big task to be performed by a system into smaller tasks that are performed in a sequence—it solves a partitioning problem. Publish and subscribe is another example of an architectural pattern—it solves a communication problem, that is, the communication between components of a system.

Architectural styles are slightly different from patterns. An architectural style is a predefined set of components or a set of elements of architecture with a set of architectural design decisions, which can be applied to a scenario. This is created by extracting a set of common elements and behavior from architectures that are already available. The design decisions that come with a style, influence or constrain further design decisions in the architecture of the system.

An example of an architectural style is client—server architecture style where the entire system is organized as client and server components. Yet another one is the layered architecture style—here the system is primarily divided into layers that depend on each other for specific functional needs. Each layer would make use of services provided by one or more layers to complete its responsibility. Thus, when applying the layered architecture style, all system elements would become part of some layer or the other in the architecture and thereby their responsibilities get associated with the responsibilities defined for the layer.

While patterns necessarily solve a generic problem, styles need not. A style is more of a central organizing concept in the architecture. Also, according to some, a pattern is described strictly as far as its constraints on the architectural components go and is widespread in the software world, and an architectural pattern addresses some aspect (problem) that is more concrete. A style is more leniently described: though there can be constraints, the constraints are at an overall level and more abstract—the structuring of the architecture is given more importance. It is less concrete than a pattern in what it addresses (the scenario or the context for the style). The architecture style dominates the overall architecture of the IT system among all the patterns used in the architecture.

When creating architecture for an IT system,* reference architectures are sometimes used. Reference architecture is typically created by using an architectural style or a pattern and mapping a set of components from a reference model to it. Here, a reference model is a model with functionality components in a specific business context. Its focus is business. On the other hand, the architecture style or pattern is not specific to the business domain. The resulting reference architecture is the architecture of a system for the specific business context. An example of a reference architecture is the IBM insurance application architecture—it is a reference architecture that applies to the insurance domain.

A common way to create architecture for a new system is by using relevant reference architecture and modifying it to suit the specificities of the problem at hand. Patterns, styles, and reference architectures all help avoid reinventing the wheel.

1.4 Introduction to Business Processes

Business process is an ordered set of activities performed to achieve a business objective. Here, the activity is either a system or manual activity and the business process is usually a mix of both. System activities are automatically performed by IT systems and manual activities are carried out by humans or, in other words, users. The users typically have interactions with an IT system through its user interface (UI).

Some examples of business processes* are loans processing, purchase order processing, customer account-opening process in a bank, credit card transaction processing, order-to-cash process...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Dedication
• Table of Contents
• Preface
• Acknowledgments
• Author
• Part I The Process-Centric Architecture Paradigm
• Part II Architecting it Systems, the Process-Centric Style (Designing PCA)
• Bibliography
• Index