IT Today Catalog Auerbach Publications ITKnowledgebase IT Today Archives Book Proposal Guidelines IT Today Catalog Auerbach Publications ITKnowledgebase IT Today Archives Book Proposal Guidelines
IT Today is brought to you by Auerbach Publications

IT Performance Improvement



Networking and Telecommunications

Software Engineering

Project Management


Share This Article

Free Subscription to IT Today

Powered by VerticalResponse

ITIL: Service Management Implementation and Operation
Leadership Principles for Project Success
Process-Centric Architecture for Enterprise Software Systems
Mobile Device Security: A Comprehensive Guide to Securing Your Information in a Moving World
Scrum Project Management
Cloud Computing Strategies
Healthcare Informatics: Improving Efficiency and Productivity

Introduction to the Process-centric Architecture Paradigm

by Parameswaran Seshan

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 middleware, 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.

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.

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.

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.

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.

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 processing, and insurance claims processing.

Business processes are the core assets of any enterprise. They define the enterprise and determine how well the enterprise performs in the market. The business processes of an enterprise are unique to the enterprise and they differentiate the enterprise from its competition. They capture the way the enterprise works and how it goes about its business of providing products and services to its customers.

Typically in an enterprise, there are some roles that are directly concerned with the business processes. Business manager and business analyst are such roles. A business manager, also called process manager, is a role that is primarily concerned with the business processes that are in operation. This role monitors what is going on with the process at any point of time and takes actions to address issues related to the operation of the process, such as reassigning tasks to different users to manage load, taking decisions to scale up the process execution to meet extra load, handling exceptions in the process, forceful termination of processes if required, and resolving bottlenecks. A business analyst or a process analyst is an analyst role that is primarily concerned with design of business processes and how well the business processes have been performing or meeting their respective objectives. These roles take a long-term perspective and focus on how to improve the processes in the future by changing them or redesigning them.

Processes typically cut across departments in the organization. The enterprise is constantly subjected to change induced by the business environment, forcing its business processes to change as a response, and that too quickly. The pace of change has only been increasing. When responding to a change, the business analyst or manager would want to change the flow or order of activities, change conditions governing the process flow, remove activities, and so on. All these fundamentally indicate changes in the business process. Thus business processes in an enterprise do not remain static; they need to be adaptable.

Activities in Business Processes

A business process is composed of a set of activities. Here, an activity refers to a specific logical operation to be performed as part of the process. Each activity is a step in the process. When the process is running, activities are performed in the sequence specified in the process definition. Upon the process execution reaching an activity, the action associated with the activity is performed, and upon the activity's completion, the process progresses to the next step. Some examples of activities are "approve the loan request," "validate the loan application." Completion of an activity results in a change of the state of the process. For example, upon the completion of the "approve loan request" activity, which is part of loan process, the process assumes approved status if the result of performing the activity is approval. If the result of the activity is a reject, then the process state becomes rejected.

Thus, an activity ideally achieves a logically complete action in the process or the primary object that the process, say a loan application, is acting upon. In this sense, activities are atomic in nature, at the lowest level of granularity of the process. Activities themselves could consist of a set of tasks, where each task is a step while performing the activity. Thus, each activity could be expressed as a task flow where the tasks of the activity are ordered based on the logical sequence. Task flow for a specific activity in a process is a detailed graphical representation of that single activity. It details out the flow involved among the steps within the activity. A task flow is executed by a single user, and this granularity is what primarily contributes to its atomicity property. The user here could be either a human or a system. An example is the "place-order" activity in a purchase order process. Place-order activity can be expressed as the following ordered set of tasks:

  1. Select the option to place order.
  2. Select a product from the list of products.
  3. Enter the quantity.
  4. Validate the quantity entered.
  5. Validation failed?
  6. Enter corrected quantity.
  7. Confirm order.

An activity in a process can be said to have been performed (or normally completed) if and only if the tasks in the activity are completed in the correct logical sequence (from the start of the task flow to the end) by the user to which the activity is assigned to.

Importance of Business Processes to Enterprise

Any enterprise would have a set of business processes that it performs. Those processes exist in reality irrespective of whether they have been

  • Explicitly designed or just happened in the course of the company's business
  • Documented in any form
  • Modeled in any approach
  • Described in any format

In such cases where the business processes have not been documented in the enterprise, their presence can still be felt-from the way a specific product from the company is built and offered to the customers or from the way a service is delivered by the enterprise to the customers. In many cases, the people that are involved in the particular process would know partial flows of the processes. That is, each person that is part of the process would know at least the following:

  • What is the business function that he or she needs to perform.
  • How he or she would get to know when he or she is required to carry out that specific work.
  • To whom he or she needs to hand off the work item after completing that specific work.

The thing to note in such cases is that though each person knows the respective part (his or her specific job or part) of the process, typically few people would be aware of the entire process with its entire flow. Also, commonly, this process knowledge, whether in part or in full, remains largely in people's heads alone.

Business processes in any enterprise can be typically classified into core and non-core. Core processes make up the core competency of the business, and these are processes that directly lead to products and services offered by the enterprise. Core processes for a company are specific to the company or the industry that the company is part of. Let us take the example of a typical cargo transportation company. Its core processes would be those processes such as cargo management, container management, fleet management, and pickup and delivery.

Non-core processes are processes that support the core processes. They indirectly contribute to the business of the enterprise. The processes such as finance accounting, billing and payments, and human resources are non-core processes to this cargo transportation company or enterprise; they are rather enabler processes. Non-core processes are typically not specific to any industry or company; they are rather generic and apply to most enterprises. They are necessary to carry on the business of the enterprise though they do not directly lead to a product or service.

Innovation activities such as research, generating new products, and strategies come under the category of core processes because they are unique to the company. They are important for the business' future growth and, in many cases, its survival itself.

How well the business processes of an enterprise run and what activities the processes perform determines the success of the enterprise in the market. Efficient business processes provide competitive differentiation to the enterprise from the others competing in the same area. Processes are thus the blueprint of how the enterprise conducts its business and makes available its products and services to its customers.

When it comes to how the business processes are actually enabled in the enterprise, IT plays a significant role. The IT systems that exist in the enterprise support the business processes of the enterprise-a business process is realized by the underlying applications that are part of the IT system.

A Quick Introduction to Process-Centric Architecture

IT systems in the enterprise essentially support the business of the enterprise. This means they support the business processes of the enterprise by both enabling the business users to carry out business functions or tasks, and also performing specific business functionalities by themselves. And toward enabling this better and better, architectures for the systems have been evolving over the decades. Their architectures have moved from monolithic to n-tier ones. Still, IT systems have been found to be not as well-aligned to business as they should have been-the business-IT system gap still exists. The systems still appear to be inflexible to support, effectively and quickly, the changes that frequently occur in the business processes. This has remained a perennial problem that software architects or IT architects have been trying to address.

Architectural styles or approaches for IT systems, such as component-based architecture, e.g., EJB in JEE and business tier, and business rules-based architecture have the objective of making the IT systems more agile and they have introduced higher abstractions in the system architecture. The former abstracted out the business logic of the application into a dedicated business tier in the architecture, while the latter abstracted out the business rules logic from the application into the rules engine (or a business rules management system, BRMS). This made the business logic and rules separately manageable from the other logic in the application. While they were in the right direction, systems still exhibited inflexibility-the IT systems were not reflecting the real business process of the enterprise faithfully. Other recent styles such as services-oriented architecture (SOA) continued take the bottom-up approach to architecture by creating reusable services from business components that could be used to support different business needs. While the concept of the services is valuable, the approach is more strongly technique-driven and technique-focused than business-driven, and thus by itself is not sufficient to bridge the business-IT gap in systems.

Process-centric architecture (PCA) is an architecture style that directly addresses this problem by moving the abstraction level further up to the process logic and the process tier. It provides an architecture for IT systems where the entire IT system is conceptualized and centrally organized by the concept of the business process that is supported by the system and the business process component is the central component in the system.

Instead of the conventional architectural approaches for IT systems, where the IT system was always just a derivative of the business process, in PCA the business process becomes the driving force of the IT system in architecture as well as in the implemented system. In the previous software design approaches, the system was built bottom-up to meet the business specifications, and the business process as captured by IT personnel, was coded (tightly/rigidly) into the IT system.

Unlike this, in PCA the business process definition specified by the business analyst or manager directly becomes part of the architecture of the system and is a component of the system itself. And this component directs the entire behavior of the system at run-time. This makes the IT system more flexible to the frequent changes in business processes and it allows those changes to be directly made into the system by just changing the business process definition rather than requiring programmers to change code. PCA owes its origins primarily to the ideas and outputs from research work in process-thinking and BPM. Process-thinking brought in the formalism for business processes. BPM contributed the approach for handling business processes and the rigor for that approach to make them effective.

Here is a brief look at the benefits of PCA:

  • Better business-IT alignment. The gap between the business process and the IT system gets reduced.
  • Better control for the business over the IT system and the supported business process.
  • Reuse of business processes, their steps, and business components of the architecture across the enterprise.
  • Enables a central store of business processes for the enterprise.
  • Facilitates effective process management.
  • Mergers and acquisitions (M&A)-related integrations are enabled.
  • Much improved flexibility to the IT systems.
  • Leads to agile IT.
  • Interoperability of IT systems is enhanced.
  • Better maintainability of IT systems.
  • Scalability of the IT system is improved.

The Book
Process-Centric Architecture for Enterprise Software Systems explains PCA in detail. It draws upon the author's research in the area and his experience in architecting and implementing IT systems based on this concept. It also picks from the author's experience in architecting and developing technology infrastructure in the area, especially a business process management system (BPMS).

As part of this, the book has drawn from the insights and learning that have come from the author's deep experience in architecting, designing, and building a BPMS process execution platform from scratch based on standards and process formalisms. The experience leveraged in the book also includes the author's experience with deploying the BPMS and implementing business processes on it for customers.

About the Author

Process-Centric Architecture for Enterprise Software Systems
From Process-Centric Architecture for Enterprise Software Systems, by Parameswaran Seshan. Auerbach Publications, 2010.

© Copyright 2010 Auerbach Publications