Employing Enterprise Metadata to Effectively Deploy Enterprise Resource Planning Packages, Part 1

• Identify and understand the current legacy HR environment,
• Set out an ideal architecture for the target HR environment that is ERP independent,
• Engineer and deploy a commercially viable vendor’s HR ERP package based on the collected legacy and enterprise HR model metadata, and finally,
• Enable the integration and successful deployment of other functional-area based ERPs to support other enterprise areas. Included here would be, for example, finance and logistics.

To be truly valuable, these metadata collections need to:

• Represent all the critical work products across this effort’s methodology,
• Be accessible through commonly available SQL tools and report writers, and
• Support the entire effort’s community through the Internet.

This paper’s definition of metadata differs significantly from its traditional meaning, which is: Metadata is data about data. That definition is not only too cute, but also it is incomplete given the actual word, metadata. 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 more general sense so as to include structured and unstructured data. Unstructured data includes both text and diagrams.

The scope of metadata here is restricted to business information systems and to its contextual, enterprise-wide environments. The metadata is not just for one business information system, but for the entire collection of business information systems across the enterprise. To restrict a metadata collection to just one business information system is to presume complete encapsulation of mission, organization, function, data and process within well-defined orthogonal metadata collection sets. Simply put, such a restriction – if success is desired – is not practical, appropriate nor possible.

Metadata integration and interoperability are essential to a well ordered enterprise. Without integration and interoperability, non redundancy is not possible. Without all these three metadata characteristics, there can only be large, tightly bound, parochial stove pipes of enterprise functionality that ultimately are significant reasons for increasing inefficiency, reduced effectiveness, continually lowering profitability, and ultimately, enterprise demise.

Consequently, within the context of this paper, metadata are the materialized artifacts that define the requirements for, the specifications of, design of, or even executing characteristics of the enterprise suites of  business information systems, and component within those systems.

“System” here is used in a very broad context. Within the scope of systems are databases, application systems, and their technology environments. Therefore, metadata is all that which is one or more levels of abstraction removed from the actual databases, applications, and their technology environments. In a computing environment, metadata therefore includes:

• Requirements
• Mission, organizational, and functional descriptions
• Work plans
• Database designs through to schema DDL (data definition language)
• Application system work products possibly through to computer program source code libraries
• Technology environment designs through to actual installation artifacts

This metadata context, would not include, however:

•  Actual databases with data records of employees, invoices, products, and customers
• Executing application systems
• Operating systems and other systems software such as DBMS and Web browsers
• Telecommunications networks
• Computers

These are not metadata because they are “real,” while the previous list represents artifacts about the reality. But once the 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 in particular files
• Quantity of users by time of day for particular processes
• Job completion and/or error messages

The metadata management system and supporting metadata database is called the Metabase (i.e., metadata-database) System. An operational example of a Metabase System, including its software, demonstration databases, and user guides, is available from the Whitemarsh website. While it is not essential that the Metabase System functional data models be previously reviewed to understand this Short Paper, it helps. It is recommended that the Metabase Overview document be downloaded and the metadata data models at the end be printed and be reviewed to have a solid understanding of the extent of metadata that needs to be captured, interrelated and made non redundant. The link to the Metabase Overview document is: http://www.wiscorp.com/metabase/metabase.zip

This four-part paper, does not represent a totally detailed work plan for an enterprise HR ERP effort. Rather, it sets out the way ahead with the full and certain knowledge that the required enterprise metadata design, collection storage, reporting, and evolution software system and database already exist and can be employed on a multi-user Internet-based environment. There are a large collection of references that will be included at the end of Part 4.

This enterprise-level metadata environment is supported by a thoroughly documented data-centric methodology with courses, seminars, books, white papers, and a set of organizations that have been successfully using these strategies over the past 25+ years. Links to those materials will be provided in the References Section of Part 4.

It needs to be noted that this enterprise-centric metadata approach for deploying ERP does not address the following:

• Infrastructure software such as operating systems and database management systems.
• Hardware for either clients, servers or networks
• Telecommunication networks or the Internet

These other work products are all addressed by other well known methodologies and are easily integrated with the work products identified and/or referenced in this short paper. The approach to build an overall integrated work plan is described in Short Paper 12, Manufacturing Project Plans, that is available from the Whitemarsh website.

Common Environment

• A single, unified network of HR application software and databases that are accessible throughout the world.
• A single, unified set of IT development organizations for the development of HR application software systems and databases.
• A single unified set of HR reference data that accommodates the migration of all legacy HR data and proceeds into a unified set of HR data semantics in the future.
• The ability to accommodate both centralized and decentralized HR processes across the world for the enterprise including the ability to support a diversity of human processes and organizations that substantively conform to enterprise-wide HR policies and procedures.
• The ability to create, develop, deploy and maintain supplementary HR functions and data that are integrated with the overall set of enterprise HR functions and data.

Knowledge Worker Framework: Essential for Understanding

Table 1: Knowledge Worker Framework.

The errors cited by the GAO studies were counted and turned into percent values. These percents set within the Knowledge Worker Framework’s rows and columns are set out in Table 2.

The bottom line message for all these percent values is that if the work products identified in a cell are accomplished and if these work products are created such that they are integrated, interoperable and non redundant with all the other work products, the cell’s percent of failure is eliminated. So, if the first row is accomplished acceptably, there is an 18% reduced chance of IT system failure.

The implications from Table 2 are summarized and presented in Table 3. The message is clear and compelling: create the work products, cause them to be integrated, interoperable, and non-redundant or IT system failure is sure to occur.

Table 2: GAO IT System Errors expressed as percent values

These error percent summaries, and their occurrence across the Zachman rows mirrors John Zachman’s famous saying that he’s stated to hundreds of conferences since the late 1980s. That is:

Someday you are going to wish you had all those models, Enterprise-wide, horizontally and vertically integrated at an excruciating level of detail.

That “someday” probably occurred about 25 years ago when it first became possible to have a unified database of infrastructure work products. And that “someday you are going to wish” also probably occurred about 25 years ago when it became possible to have enterprise-wide IT systems and databases. Enterprises that acted on Zachman’s admonition often succeeded at their IT efforts, and those that do not almost always failed. The United States Government’s General Accounting Office’s library is a graveyard of failure tombstones (a.k.a., “GAO Reports”).

Figure 1 shows the overall interrelationship among the Knowledge Worker Framework work products accomplished across all its six columns and down its six rows. The way to understand the diagram is to first understand that the knowledge worker columns (Mission, …, Business Organization Model) are all related to each other through many-to-many relationships. The basis of the relationship is the “box” that is directly above the Knowledge Worker Framework column.

Figure 1: Interrelationships among Knowledge Worker Framework columns and rows

Examples are:

• Database objects represent the persistent memory necessary to fulfill one or more enterprise missions. Similarly, a mission can be fulfilled by one or more database objects. These are defined within the context of idealized enterprise missions that are long lasting apolitical, and independent of the ever-changing business functions and organizations. These are defined in the context of database objects. Database objects are defined within the context of missions, they too are long lasting and apolitical because they are also independent of ever-changing business functions and organizations.
• Business information systems are the application information systems necessary to collect, store, report, and update the data necessary for the database objects. These are defined within the context of  like database objects and so, for the very same reasons, these are both long lasting and apolitical.
• Business event models are the interface events that enable one or more business functions to employ business information systems. In turn, a business event may be fulfilled through the employment of multiple business information systems. The business event models are tactically and operationally based because they are designed to reflect the changing needs of business functions.
• Business functions, which are human processes, are accomplished by business organizations in the use of business information systems to collect et al the data necessary to accomplish enterprise missions. The business functions are both tactical and operational and also ever changing and political. Needless to say, organizations too are both tactical and operational and are thus ever changing and political.

Because the first three columns (down through their rows) work products are long-lasting and a political and the last two columns (business function and business organization) are tactical and operational and are thus ever changing and political, the first three columns are accomplished first. The last two columns are accomplished second, and the business event column is accomplished last.

ERP Migration Alternatives Analysis

The alternatives from migrating legacy HR stovepipe system and database environments to ERP migration efforts are just three:

• Replace legacy systems with HR-ERP
• Direct connect legacy systems with HR-ERP
• Indirectly connect legacy systems through an Enterprise HR Model to HR ERP

These will be described and contrasted in Part 2 of this paper.