Strategic Management Interchange Architecture

One way to improve the degree of automation between currently non-integrated systems (within an organization or between organizations) is to use an enhanced Electronic Data Interchange (EDI) format that carries the full strategic context of a business transaction. The context would be defined in an Enterprise Catalog which provided data lookup tables at all organizational levels to ensure consistency of data entry, and would include local-source catalog submission and refinement routines. It would provide functionality far beyond the ANSI832 Catalog Interchange format.

The Enterprise Catalog would consist of the following classes (presented like File Folders) of objects and specific instances (presented as Lists) of those classes:

This Enterprise Catalog would be based on standard X.500/LDAP technology, with schema (Object Class) extensions to encompass the above.

Figure 1.  Enterprise Superclass Stewardship and Profiling roles

This multiple-association description would provide a "Profile" of each object, showing its "components" and "containers". Since the Catalog shows the object’s lineage (same class parentage and descendants), and the Profile shows the object’s associates, the resultant Catalog and Profile combination would provide the "Context" of each object (See Figure 2), to the degree it can be economically defined by the enterprise, multiple enterprises, or a Reference-Context source.

Figure 2.  Generalized Object Model

This combination of Catalog and Profile capabilities is called a "Context Engine". A context engine, implemented within an enterprise (on any scale from individual to national), or across multiple enterprises, or from a publicly accessible "reference" source, can serve as the synchronized and distributed centerpiece of a secure database, messaging, and collaboration environment, providing capabilities for dynamic online transactions and analysis, on any scale of the enterprise or inter-enterprise environment.

The movement of strategic, control, and operational data between organizations, functions, programs, and projects could be accomplished using the following proposed EDI format.

Each row of the above EDI set would contain values such as these shown for performance measures and strategies.

Figure 3.  System/Process Model

Figure 4.  System Definition Model (IDEF)

Functional improvements are most often the result of both process change and improved technical support. The guidelines of The DoD Framework for Managing Process Improvement (FMPI) can be used as a foundation to develop the improved capability. See Figure 5.

Figure 5.  Map of the Framework for Managing Improvement

Under this template, requirements and an organizational  assessment lead to a Strategic and various Program Plans (Activity 1), followed by a process reengineering phase (Activity 2), an organizational change management effort (Activity 3), a technical change management effort (Activity 4), an engineering effort (Activity 5), a capability implementation effort (Activity 6), and operation and maintenance of that new or improved capability (Activity 7). This requires corresponding efforts to identify and simplify the complexity of the organization and its interactions and policies (Activity 8) and the ongoing management of the overall operational and improvement efforts (Activity 9).  The required capability will be fully defined implemented, and subsequently refined and evolved through these efforts.

The various aspects of conducting an organizational Strength, Weakness, Opportunity, and Threat (SWOT ) assessment are shown in Figure 6.  The perceptions formed before and during this assessment help to identify overall requirements.

Figure 6.  SWOT Diagram

Who are our future customers?

What will they need based on their own direction/strategy?

Who is our future competition?

How can we differentiate our products/services from our present/future competition?

How should we position/brand ourselves and our products/services for the 21^st century?

Enterprise requirements are those that extend horizontally across multiple functions shown in the organization chart.  They drive the need for internal collaboration or partnerships with external organizations.

Whenever the term "access" is used, it seems to assume a mechanism to manage access. I suggest a mechanism here, which would apply to every situation that requires "access" control. This is standard, but fairly new and complex technology, and its use as I described here is not well understood in the IT arena.

Provide standard technologies to manage resource access definition, control, and update management. This would include industry standard Digital Certificates based on a robust corporate Directory.

A Certificate Authority (CA) server, based on commercial and DoD X.509 Certification standards, would allow a hierarchical tree of resource access Authorities, Groups, Roles, and individual person or process permissions to be defined, thus distributing the workload of assigning finely grained resource access to a person’s local organization or team authority rather than a central authority.

While the Certificate Authority would manage who can authorize access to resources and what information can be accessed, a corporate directory, based on standard X.500 Directory technology, would be used as a "Table of Contents" to the enterprise and its catalog of information. Using an X.500 directory structure (object schema) optimized for the corporate mission area, the corporate directory would provide a Directory Information Tree (DIT) of the resource catalog’s contents. From this standardized DIT, certified authorities throughout the enterprise could build a consistent profile for each resource user and producer, defining the context in which that person or process is to participate in corporate activities. In addition, by applying X.500 derived technologies (e.g., LDAP), existing and new enterprise and functional applications can be "directory-enabled", providing the same degree of access management for automated workflow via data interchange (i.e., EDI) between applications.

Reconciling and Integrating Life Cycles

DoD IT Program planning will include the integrated application of the DoD Framework for Managing Process Improvement and the DoD Guide for IT Investment and Measuring Performance as a process architecture for Information System development, shown below. Thus, the development program will detail the implementation of a series of planned, interdependent, incremental, and measurable steps. Each technical step will proceed in conjunction with appropriate process development, engineering, prototype development and testing phases to ensure and measure that targeted effectiveness and efficiencies are achieved.

CY=Current Year; BY=Budget Year; PY= Program Year; EPA=Extended Planning Annex; PPBS=Planning, Programming and Budgeting System; FMPI=Framework for Managing Process Improvement; GPRA=Government Performance and Results Act; TAFIM=Technical Architecture for Information Management; ITMRA=Information Technology Management Reform Act; SWOT=Strength, Weaknesses, Opportunities, and Threats.

See Rights Notice and Disclaimer