The following is an extract from Chapter 2 of Michael M. Gorman’s new book Enterprise Governance Community of Interest Handbook available at:
http://wiscorp.com/printedbooks.html.
Key Reasons for Governance
To put forward a good rationale, the purpose or value of an Enterprise Governance Community of Interest must be set down. From the point of view of this book the reasons are to:
- Increase the level of conflict free policy execution.
- Increase the level of confidence in decision making.
- Reduce the risk in decision making.
- Reduce the cost of preparation and research prior to decision making.
The first section of Chapter 1 clearly states the mission of governance: the ability to make collective decisions faster and with greater confidence. Chapter 2 states that there is a need for governance because of shared missions. Chapter 2 also presents the metadata models used to capture the complete specifications necessary to know exactly what data can and should be shared. Simply put, the data subset representations of shared missions need to be exchanged. Since mission descriptions can be 50 pages or more in length, a more precise identification of what is to be shared and the basis for sharing needs to be specified.
Chapter 1 infers that it is not the fixed, random, or even ad hoc exchanges of data between business information systems, or between end-users and business information systems, that are ultimately critical and important. Rather, it is the common, shared, and consensus-based understanding of data that must be set out in each of the systems that ultimately control the data that is captured, stored in databases, and then shared. If such an environment exists, then not only will the routine business process drive data exchanges to be improved, but so also will be the random and ad hoc access of data through business information systems because semantics and value domains will be reliable and repeatable. Given common, shared, and integrated metadata, business managers and decision makers can integrate databases through traditional or service oriented architecture environments with the confidence that the responses come from a network of non-redundant, integrated, synchronized, and semantically homogeneous databases and business information systems.
Shared Policy is Basis for Common Understanding
The basis for the common, shared, and consensus-based understanding of data is policy. After all, data is the “what” that remains after policy is executed. Thus, Data is Executed Policy. When an organization creates policies, it necessarily creates as its companion, procedures. Together, policy and procedures are set into place to run the business. As the business runs, data, the consequence of policy execution, is created and stored in databases. These databases become the persistent memory of the organization.
“Data” specifications are thus policy definitions. Similarly, process specifications are procedure definitions. Consequently, all data (i.e. policy) specifications are metadata. All process (i.e. procedure) specifications are also metadata. A metadata database is a database within which all enterprise Policy and Procedure Specifications are captured, stored, and managed. The metadata model diagrams in Figures 7 through 24 (in the book) are high level graphical depictions of shared policies and procedures. Any policies and procedures that are not specified or transformed to metadata, and do not result in database data, are not only just anecdotes, they also cannot lead to trustworthy enterprise persistent memory. Similarly, these non-specified policies and procedures cannot lead to trustworthy governance.
Policies exist in meaningful configurations that map onto the common sense based transactions of the business. These transactions are all tied to one or more of the resource life cycle nodes. The processes that support the capture, storage, modification, and access of data are accomplished by the business information systems.
Comprehensive Definition of Metadata
A quick response to the question “what is Metadata,” is that it is data about data. However, that’s too cute. More formally, the string, metadata, is divided into meta and data. “Meta” in the Oxford Dictionary means, “something of a higher or second-order kind.” The word, data, however, is not employed within this paper in its strictest sense, that is, a data item like Birth date = 03/22/1941, but in a more general sense to include unstructured data like text and diagrams.
For the purposes of this book, the scope of metadata is set within the entire context of the enterprise. Consequently, metadata are the materialized artifacts that define the enterprise and the requirements for, the specifications of, design of, or even executing characteristics of an IT system, or component of that system. “System” here is used in a very broad context. Thus, included within the scope of systems are databases, business information systems, and their technology environments. Therefore, metadata is what is one or more levels of abstraction removed from the actual databases, business information systems, or their technology environments. In a computing environment, metadata would therefore include:
- Functional descriptions.
- Work plans.
- Database designs through to schema DDL (data definition language).
- Business information system designs possibly through to computer program source code libraries.
- Technology environment designs through to actual installation artifacts.
But within this context, metadata would not include:
- Actual databases with data records of employees, invoices, products, and customers.
- Executing business information systems.
- Operating systems and other systems software such as DBMS and Web browsers.
- Telecommunications Networks.
These are not metadata because they are “real,” while the previous list represents artifacts in the “about the reality” domain. But once the business information system is executing, metadata may be created that describes the characteristics of the operating environment. That class of metadata would include, for example:
- Computer system execution schedules.
- Computing resource consumption requirements.
- Quantity of records files.
- Quantity of users by time of day for processes.
- Job completion and/or error messages.
Database Objects: Foundation Stones for Shared Policy
The data specifications within which transactions are created and exist are database object classes. The domain of data of a database object class should relate perfectly to the domain of data of a coherent policy existing within the enterprise. It is on the foundation of a quality database that there can be quality shared data. That is because:
- Each database object class’s data structure (typically database tables) is the data representation of a policy’s definition.
- The database object class’s processes through which data rows are added, deleted, and modified are the mechanisms necessary for policy execution; that is, the policy’s procedures through which database objects are transformed from one valid state to another.
- A fully defined policy that includes both its complete definition and its necessary steps for coherent execution.
- Interrelated collections of rows across multiple tables of one database object class and across multiple collections of rows across multiple database object classes form more comprehensive policies.
When data is executed policy, and is realized through database objects, then quality databases support the following within the enterprise:
- Business information systems that are a coherent union of the policy that, in turn, support the execution of procedures that represent the accomplishment of the policy. Because of shared policy, data can be more easily shared across systems whether in scheduled or ad hoc manners.
- Consistent collection and/or modification of policy instances through the life cycle of the policy. These policies, applied enterprise-wide, ensure that all systems and databases participating in a community of interest are similarly updated.
- Consistent execution of policies whenever, wherever, and however deployed as the essence of the policy, and the totality of its critical procedures are encapsulated within the database object class itself.
- Minimized redundancy and consistent policy implementations across distributed environments as the database object class can be distributed through encapsulated strategies.
- Comparable instances of deployed policies that are independent of hardware architectures and operating systems.
Engineering Database Objects
What forms the basis of a database object? Simply put, it is a business’ policies and procedures. While policies can exist without procedures, the converse is not true. This ontological priority dictates that procedure is dependent on policy. They go together like hand and glove. The glove (procedure) serves no useful purpose without the hand (policy).
A database object is a person, place, or thing that has internal consistency, and is transformed from one valid, predefined state to another through well-defined rules. The minimum value states are null and valued. The internal behavior of a database object class as its objects transform from one state to another is immaterial to its user. Database object classes conform to the requirements of business rather than the converse. Database objects are the corporate memory of the enterprise. All the rest are anecdotes.
Policies and procedures, that is, database object classes, bring order, consistency, and predictability. The larger the enterprise, the greater the dependence on policies and procedures. Data is the evidence of policy execution. An employee’s record is proof that policies have been carried out. Procedures are the techniques, methods, or processes by which policies are carried out. For example, if an enterprise’s policy is to be profitable, then its balance statement, produced by processing all the general and subsidiary journals, is the measure of adherence to the policy. If policy is met, the enterprise must be profitable.
The procedures are named, and their data actions are associated with specific subsets of the named data structure. The names of the procedure sets represent data structure transformations from one recognizable state to another. Each state represents a determined value set within the business. Procedures include, for example: establishing an employee requisition, accomplishing employee hiring, and performing employee assignment. Enterprise-database is an organizational operating condition in which there is defined policy coherence and integrity, as well as consistency in policy transformations throughout the enterprise irrespective of functional and organizational style and irrespective of policy transformation technology (that is, computers, operating systems, programming languages, and database management systems).
Enterprise-database is the expression, population, use, and manipulation of all database objects. Enterprise-database begins first with quality-database object classes founded upon the policies and procedures surrounding their specification, implementation, and evolution. Value proceeds not first from the database object, but from the database object class. The consequences of quality-database object classes are “real” database objects. The information technology assets of the enterprise are both its database objects and its database object classes.
Finally, an enterprise is interoperable only to the extent to which its metadata is non-redundant, non-conflicting, and integrated. To believe otherwise or to believe that, for example, the only thing that must happen to database objects is they are transformed to XML for an enterprise to be interoperable. This flies in the face of common sense and simple logic. Is it “record” or “record?” Is it seam or seem? Is it 2.79 MPH or 2.79 KPH? Is it rounded or precise? Is it a running total or an amount at that instant? Data alone doesn’t provide the answer. Data and semantics do, but only in context in an integrated, non-conflicting, and a non-redundant manner.
Impact of Governance
As stated above, governance is all about establishing and affecting integrity and correctness. While that is important within a single database and business information system, it is critical across an enterprise’s functionally-wide set of databases and business information systems.
There are two approaches to governance: Stovepipe and Community of Interest. The Stovepipe approach accomplishes governance completely within the context of a single database and business information system. Here the governance is defined, implemented, and maintained for each database and business information system and for each different interface across the databases and business information systems.
In contrast, Community of Interest governance accomplishes governance across the whole community of databases and business information systems.
While Stovepipe governance would be cheaper for one specific database and business information system, the sum of all the Stovepipe governances across all the databases and business information systems would greatly exceed the cost of Community of Interest governance.
There are several reasons for that. First, governances for each of the databases and business information systems must be created and managed. Second, an additional governance effort must exist to resolve the data semantic disparities across the individually governed databases and business information systems. And third – possibly the most expensive – governance efforts must be undertaken for each of the different shared data interfaces. And for these, there must be a governance effort for each side of the data exchanges.
In contrast, a Community of Interest governance enables shared missions et al. to be defined once and implemented many times.
