How to Integrate or Disintegrate an Enterprise.
To integrate, or not to integrate? That is the question.
Enterprise integration has been an enduring issue for business and IT managers for at least thirty years. How can such a fundamental issue persist for so long? Perhaps it persists because:
- We don’t have a sound, shared definition of what we mean by enterprise integration or disintegration, and
- We do not fully understand the root causes of enterprise integration or disintegration.
I have some thoughts on what enterprise integration and disintegration is and what causes enterprise integration and disintegration to occur.
According to the dictionary, to “integrate” means to combine one thing with another so they become a whole and bring into equal participation in, or membership in, society or an institution or body.
Therefore, an enterprise is integrated if its parts are combined in a manner which provides for their participation and contribution in a cooperative, mutually supportive manner. This further means that there is an absence, or a minimization of discord, conflict, fragmentation, redundancy, or competition among the constituent parts of the enterprise.
The basis for enterprise integration should be the enterprise’s business processes, as opposed to its business functions (i.e. Accounting, Marketing, Engineering, Manufacturing, etc.) or its organizational units (i.e. Accounts Receivable, Accounts Payable, Eastern Sales Office, Western Sales Office, etc.)
The first barrier to integrating an enterprise is the obvious attention given to addressing the issue from either a functional or an organizational perspective. The functions of an enterprise are quite stable; however, a function may perform many processes, and a process may be performed by many functions, thereby creating inherent redundancy of processes. Organizations, on the other hand, are less stable than functions. Organizations may also perform many processes, and a process may be performed by many organizations, thereby creating inherent redundancy of processes.
I am of the belief that enterprise integration must be approached based on what I call the “logical business processes”, which, in my opinion, are the most fundamental, stable structure for establishing the foundation for an enterprise.
The following diagram shows the relationship between Function, Organization, and Process:
The above diagram, in the form of a relational data model, specifies the following:
- Organization, Function, and Process are separate, distinct, and independent of each other. This means that each of these business objects is independent variables. Therefore, none are subordinate to another and each must be identified and defined separately.
- Function Organizationspecifies the relationship between instances of a Function and an Organization:
- An Organization may perform one or more Function; and
- A Function may be performed by one or more Organization.
- Organization Process specifies the relationship between instances of an Organization and a Process:
- An Organization may perform one or more Process; and
- A Process may be performed by one or more Organization.
- Function Process specifies the relationship between instances of a Function and a Process.
- A Function may perform one or more Process; and
- A Process may be performed by one or more Function.
The critical point here is that Process is not a decomposition of Organization or Function.
The Root Cause of Enterprise Disintegration
Most people commonly define Process within the context of an Organization or a Function. This practice is the primary, root cause of redundancy in the identification of processes. This flawed practice leads to redundant Process specifications which get implemented in various applications, AND this, in turn, leads to redundant and inconsistent functionality across the entire portfolio of enterprise applications.
This very defective result happens because most analysis starts with IT Analysts asking people who work in an organization to identify and define their “business requirements” and they do so within the context of their organization. Another major contributor to this problem is the sponsorship of IT information systems projects by organizational or functional units of the enterprise which often restricts or constrains the project scope. Additionally, if management decides to change the organization structure—which they do!—the scope and context of a project, and the associated information system(s), will be subject to change more frequently and readily than if the project scope and context are defined by a logical business process. This situation lays a foundation which is guaranteed to result in enterprise disintegration.
Over time, gaps and redundancies in the implemented “systems” will occur, whether they are manual or automated, and this will cause the disintegration. Once “systems” become automated, it becomes increasingly expensive and time-consuming to try to overcome disintegration. The applications, and the business processes they support, will become inconsistent and data redundancy will become rampant. Then you will have to build data warehouses, cleanse the date, reconcile inconsistencies, and add additional maintenance resources to help deal with the disintegration!
A Path to Enterprise Integration
The product or service produced by the enterprise—its primary resource—dictates which business processes are required by the enterprise. It does not dictate how the business processes are to be performed. The product or service of the enterprise also dictates the supporting resources required to provide the product or service to the market. Logical business processes are the elementary set of business processes that must be performed to provide a product or service to a market. Logical business processes are identified and defined by analyzing how resources are managed through their life-cycle (i.e. requirements, acquisition, stewardship, and disposition). Consequently, the resulting logical business process architecture will be very stable, complete, and non-redundant, thereby eliminating the fundamental, root cause(s) of enterprise disintegration.
If we base the Enterprise Applications Architecture on the Enterprise Logical Business Process Architecture—and we design and build applications that conform to the scope and context of that architecture—we will not have the redundancies and inconsistencies that currently plague our business applications, and the application code will be much better suited for reuse. We will also be in a position to design and build databases that are non-redundant, shareable, and reusable across the whole enterprise.
To integrate, or not to integrate? We have the answer at hand.