General Enterprise Management and Context Management History
See Rights Notice and Disclaimer
In 1982, as part of my Master's degree program in Systems Management, in a Systems Analysis project, following insights I gained as a child and youth, I began defining the requirement and identifying the system specifications for a "whole-enterprise management system".
When I began, I was also working (during the period 1982 - 1989) in the role of Management Analyst for a 12,000 person Army Division-sized organization in Europe. During this period my duties grew into Management Officer (Organization, Manpower, Equipment, Financial, and Improvement Management), which then grew into Assistant Comptroller and then Information Resource Manager (now called a CIO) . I then worked in the role of Lead Information Engineer (IT Architecture, IT Standards, IT Requirements Assessment, and IT Plans/Budgets) for the U.S. European Theater Army of over 300,000 people. After leaving Europe, I subsequently had stateside assignments as Management Analyst in Customer Relations, TQM, Reengineering, Information Resources, and Performance Management up until 1995 when I left Government service. I have subsequently worked as a Contractor in the roles of Business Analyst, Notes Architect and Designer, BPR Practitioner, Strategic Planner, Systems Integrator, Principal Information Engineer, and now eBusiness/eCommerce Advisory Staff..
The systems analysis of "whole-enterprise management" I initially conducted beginning in 1982, with subsequent refinements and tracking of related fields and technology, has shown me one critical requirement for all of the "management" systems I've worked on. That one, consistent, unfilled requirement is for technology that provides a high degree of dynamically changing situational context awareness for people and processes as they operate in their various activities.
As part of the requirement analysis of this general unfulfilled requirement, I've found some common features of ALL management systems. First is the need to name, list, and identify things that are of interest to the system.
Second is a need to provide a means to decompose the categorization of the "managed things" to finer and finer levels of detail, that is, a need to manage what are now becoming known as "hierarchical namespaces" (i.e., tree structures) of classes/types of things and the instances of things themselves (nouns).
Built from this finely grained capability to uniquely named things, a third common feature was the ability to directly associate, using verbs phrases, the hierarchical namespace entries together in pairs (e.g., Alice to Bob, Bob to House). These paired-entries could then be combined into larger collections (e.g., Alice to Bob to House), and indirect associations (e.g., Alice to House), resulting in the formation of a "profile" (i.e., star data structures) of how the namespace entries related to each other along specific six dimensions of location, organization, workforce, function, process, and resource. [Note that star data structures are the foundation of dimensional data warehousing, Online Analytical Processing (OLAP), and Business Intelligence capabilities used in enterprise decision support activities.]
These six star dimensions are used, in this specific order, because of their typical natural "container/component" relations with each other. (If we used fewer, simpler, more fundamental categories like space, time, matter, energy and information, it would be difficult for people to relate to them. If we used more dimensions, adding more decomposition at the top of the namespace tree, then the complexity of the namespace associations would explode into infinity, known as a "data explosion" in data warehousing terms.) As is known from the data warehousing field, six dimensions is just about right for building a maintainable multidimensional database.
In regard to the container/component relations of the dimensions, if you envision a map of a state (e.g., California), the map would have location information in terms of map coordinates, zip codes, geographic features, etc., as well as having other information connected to the location information (e.g., the name and boundaries of an organization of type State, or type County). A person using a map for management purposes (e.g., a person managing the maintenance of a type of fuel pumping equipment) would overlay the location and organization details of the normal map with more detailed associated information like:
the names of the workforce elements (offices and positions, or teams and roles) in the area that uses, owns, or maintains the equipment, associated with
the business function names of the workforce roles (e.g., sales, maintenance, consumer) involving the equipment, associated with
the names of the processes used in maintaining the equipment (stopping the pumping equipment, repairing the equipment, testing the equipment, starting the equipment, monitoring the equipment, etc.), associated with
the names of any resources (i.e., people, funds, data/document, skill-set, materiel, facility, service, space, time, energy) used in installing, operating, maintaining, or replacing the equipment, and the life cycle status of those resources in relation to the associated process, function, workforce, organization, and location "containers".
The above is an example of the type of information being displayed using modern two and three dimensional Geographic Information Systems (GIS) and Spatial Information Systems, along with multidimensional (space, time, alternative-future/what-if) simulation systems, for purposes like visualization of enterprise management, military command and control, logistics management, economy management, community workforce education management, transportation management, etc.
For example, a common military command and control (C2) "track" would present information about the location, organizations workforce, functions, processes, and resources represented as a screen icon on a digital map, which is symbolizing a particular military item like an individual, team, aircraft, tank, ship, maneuvering unit, or other form of managed military entity.
The civilian equivalent of the typical military C2 representation would be the "control panel" type of "drill-down" decision support systems used by enterprise executives to plan, direct, check, and adjust enterprise direction and pace. The drill-down function is drilling into the details of the high level symbols, which predominately means they are drilling down into the hierarchical namespace dimensions of location, organization, workforce, function, process, and resource details. Common examples of this drilldown functionality is found in Microsoft Excel's Crosstab/Pivot-Table/Data-Grouping/Outlining functions.
As illustrated in the paragraph above, built on the tree and star structures was a fourth common feature of the ability to track and project both "changes over time" and "process sequentiality" (i.e. "Arrow of Time" structures) in the namespace/nouns and profiles/verb-phrases for historical, status, planning analysis/tracking/reporting, and for process modeling and simulation. This Arrow is also often referred to as "Flow" as in the "flow of events", a "flowing river", or a "flow diagram".
The above tree, star, and arrow features are what are today known as "Design Patterns". The unfulfilled requirement for combined tree+star+arrow patterned management structures has shown up over and over in my career, in every situation where "management" of something, especially complex things like an enterprise, is required.
From this long-running analysis of generalized management system requirements for the tree/star/arrow patterns, I've identified, designed, and refined a "General Enterprise Management" (GEM) model of how these tree/star/arrow management capabilities could be implemented as a "Context Management" system.
Over the years I've developed and refined designs for systems to provide this Context Management tree/star/arrow capability, and have seen more and more technologies become available that provides increasingly greater tree/star/arrow patterned Context Management functionality. The current technologies using the tree/star/arrow pattern in varying degrees are:
The problem with all of these technologies is that they are all focused on managing fragments of the enterprise and its components, not the "whole" enterprise. Using the GEM model, I have learned how to apply the tree/star/arrow patterned Context Management to the whole enteprise, and all of its human and other components, within it's larger environment, and the value-chains that flow into, out of, and within the enterprise. I've built operational prototypes, beginning in 1989, in dBase III and the IV, Borland Paradox, Lotus Notes, MS Access, and am now working on a Web-based SQL prototype. I'm also considering building a prototype with XML because of its inherent support for hierarchical namespace functionality.
I've continuously updated the GEM to encompass these technologies as they progress and reach closer to the levels of integration and capabilities I've demonstrated with GEM. The technology, and the cultural awareness of their capabilities, reached the point in 1998 that they can now economically satisfy the fundamental requirment for a "high degree of dynamically changing situational, context awareness for people and processes as they operate in their various activities" cited earlier.
Having said all of the above, I believe that a Context Management database application, implementing my General Enterprise Management model, using the tree/star/arrow patterned technologies available today, would be the most valuable and highly used database application ever built or that ever will be built.
It would give people situationally relevant omniscience.