General Endeavor Management (GEM) Approach
to
Enterprise Management Architecture (EMA)
Invented, Authored, and Maintained by Roy Roebuck, for the Public Domain
20080615
== Table of Contents ==
Table of Contents
Methodology_Section_1-_Solution_and_Technology_Architectures
Methodology_Section_2_-_Data_Architecture
Published Separately
=== Methodology Introduction ===
GEM is a "whole enterprise" or "enterprise as system" management approach, or EM for short. An Enterprise Architecture (EA) is the primary shared knowledge-model and knowledge base of the enterprise and of EM. However, to distinguish this EA approach from more-specialized EA approaches produced for IT Investment Management and IT Development, I call this an Enterprise Management Architecture (EMA).
While the term "enterprise" is defined as "a purposeful endeavor", for the purposes of this document, an enterprise is equivalent to the coherent and cohesive activities of a person, group, organization, or collections of these, to achieve a specified and measured outcome – the enterprise mission.
I hope you find these integrated Solution Architecture, Technology Architecture, Data Architecture, and Business Architecture development and refinement procedures (i.e., methodologies) useful to your understanding and efforts in implementing an EA from scratch.
These procedures can also be used to refine/extend/rebuild existing EA content and efforts, and to provide a mechanism for integrating, unifying, and federating (from-a-unified-view) your diverse value-chain and organization/subordinate enterprise architectures.
You might find it useful to build your own EA metamodels, in your own EA tools, to capture this EM methodology in your own repository, and to serve as a higher-level metamodel to which you can map any existing metamodels, and their model instances.
Over the years, I’ve been told this set of procedures is quite valuable, so I hope you benefit from using them. Contact me through my web site ([http://www.one-world-is.org]) if you need further assistance, advice.
If you are willing and able to contribute to my non-profit management education efforts, you may do so at [http://www.one-world-is.com/paypal/paypal-contribute1.htm], preferably in relation to the benefits such as cost savings and cost avoidance gained through studying and applying GEM. I am requesting a recurring $100 per year contribution from individual EA’s, $500 per year for small organizations, $1000 per year for medium-sized organizations, and $ 2500 per year from large organizations and government organizations. These funds, or equivalent services and materiel, will enable me to continue to provide this public access to GEM.
=== Methodology Sequence ===
It is reasonable and practical (but not optimal) that an Enterprise Architect would first work on the:
(I) solution architecture, and
(II) technology architecture first, because it is dealing with highly tangible, countable, identifiable, governable things.
The less tangible and more abstract:
(III) data architecture (structuring semantics/metadata/data, which I also call "Intelligence Architecture"), and
(IV) business architecture (structuring the organization’s overall and decomposed top-to-bottom process by arraying: functional-sequences of activities as in flow diagrams and IDEF0, and their ICOM resources, across organization-unit/organization/location "performer lanes", as in BPMN and IDEF3, built from the typical organization-chart and organization’s financial "chart of accounts", with each "performer" having their own distinctive corporate-mission-supporting functional mission/vision/goals/objectives/success-indicators, and functional assignments to organization units with performance targets, authority boundaries, and budgets) typically takes more communication, coordination, collaboration, and co-operation if done from scratch.
I have published, to the public domain, my own enterprise management (EM) spiral life-cycle approach, that I’ve assembled over my 33 years of management and analysis work. This EM approach includes planning, implementing, using, and maintaining an EA that is simultaneously top- down and bottom-up, in a spiraling continuous improvement and refinement process, i.e., top-down from Business to Data to Technology to Capability Architectures, with corresponding Bottom-up Capability to Technology to Data to Business inventorying, mapping, and change- tracking, typically meeting at the Data Architecture layer.
In my EM approach, the EA, when built or extended using the procedure below, serves both as the enterprise knowledge-model (i.e., ontology) and its knowledge-base (i.e., master data set).
You can read more on it at [http://www.one-world-is.org].
=== Methodology Section 1- Solution and Technology Architectures ===
1. Solution Architecture and Technology Architecture Build and Refine Procedure
To address a "Bottom-up" EA approach, you might consider using the following material as a checklist for building the I-Solution Architecture and then II-Technology Architecture. This is a common initial approach to EA, that I’ve seen as the primary order that most U.S. Federal Government organizations have taken in their approach to EA. Such a Bottom-up approach typically results in:
(I-1) an inventory of existing and planned IT ‘solution" capabilities (or IT physical and virtual assets) with their interface and scheduling dependencies, and
(II-1) a "technology reference catalog" of technologies that are:
current,
planned for phased insertion,
evaluated for phased insertion,
deprecated for phased replacement or removal, or
rejected.
Note that for the (II-1) Technology Reference Catalog, you want to identify:
(II-1-1) technology standards (with attributes for name, universally unique ID, taxonomy ID, authority, standard issuance date, organization authorization date, authorizing group/position/role with incumbent person),
(II-1-2) standard decomposition to lowest identified (i.e., distinctively named, numbered) part level,
(II-1-3) products and services (internal or external vendor/ manufacturer name, vendor unique ID, product/service brand name and universally unique ID, product/service version and universally unique ID, product/service release name and universally unique ID, product/service patch or service pack name and universally unique ID, product or service supplier name, supplier universally unique ID),
(II-1-3-1) product and service decomposition to lowest identified (i.e., distinctively named, numbered) part level, and
(II-1-4) mapping of product and service components and their inputs/ controls/outputs/mechanisms to supported standards, including the validation of full conformance and thus full interoperability with those standards.
The (I-1) IT capability inventory will typically enable identification of capability types and instances of:
(A) IT and other infrastructure,
(B) IT and other systems such as factory assembly lines or computing platforms or vehicle fleets or patient critical care or hospital waste disposal or sensor systems for patient vital signs or actuators to turn on air-conditioning or heating,
(C) software systems to support these systems and infrastructure,
(D) outsourced IT and other infrastructure/system/software mechanisms such as electrical power, Internet access for IP data/voice/fax communication, POTS telecommunication access for data/voice/fax communication, waste disposal, office/assembly-line/store-shelf resupply, software development and testing, IT operations management, coffee services, and
(E) consumable IT and other capability supplies such as paper, ink, cleaning supplies, replaceable components, etc.).
Each of the A-E IT capabilities out of the above, in turn, has their own distinctive combination of IT components such as:
(a) hardware,
(b) software,
(c) metadata,
(d) data,
(e) user interface information products,
(f) report information products,
(g) packaged data and procedure sets as information products - now often called services, as in web services, and
(h) input/control/output/mechanism interfaces to external capabilities.
These inventoried (I-1/A-E) IT capabilities, and (I-1/A-E/a-h) IT capability parts can be arrayed in comparison to each other and to the (II-1) Technology Reference Catalog for analysis, such as in a table with some row to column combinations of (A-E) capability, a-h capability part, and (II-1) Technology Reference Catalog product, standard, product-part, service-part, or standard-part entry, with IT capability/asset identifiers and names in the cells, or in various types of multidimensional arrays for analytical software such as Excel or Access Pivot Tables, or OLAP cubes for datamart use in business intelligence analytics.
Once these capabilities are:
(1) discovered,
(2) uniquely named,
(3) stored in a single information repository (e.g., a triple store in a metadata repository (MDR) built on ISAM, SQL, MOF, RDF/RDFS, or extended metadata repository - XMDR),
(4) given universally-unique identities,
(5) characterized/typed as in (a-h) above, and
(6) decomposed into their specific parts which are
(7) in turn characterized/typed using (a-h) above,
you"re positioned to
(8) array those capabilities by characteristic/type (e.g., a capability subject tree, or taxonomy) and then
(9) do analysis across those characteristics/types to compare then by any of the criteria (I, II, A-E, a-h) above, and analysis across (III and IV) when they are available.
=== Methodology Section 2 - Data Architecture ===
2. Data Architecture.
The more tangible and narrowly-focused (I) Solution Architecture and (II) Technology Architecture may seem to be the most practical and useful EA part to build first. And the higher order, more abstract (III) Data Architecture and (IV) Business Architecture parts to be least practical and useful, and thus often built last, if at all. Unfortunately for most efforts to implement and EA, the inverse is easier and more consistent, and optimal for the enterprise as a whole.
However, when considered from an broader/unitary enterprise perspective (e.g., the CEO, COO, Board/Legislature, Owner/Investor/Citizen viewpoints), it is more economical, effective, and faster to build the EA parts in the order: (III) Data, (IV) Business, (I) Solution and (II) Technology. Without having a controlled vocabulary, and its standard references, master metadata, and master data for the enterprise activities, all subsequent efforts that require communication, understanding, and agreement on terms and symbols used within and around the enterprise are largely slow, inefficient, and ineffective Babel.
To quantify this, I submit that 80% of the cost of any annual operation or a one-time capability development effort is caused by uncontrolled, or wild, vocabularies across the diverse individuals and groups participating in those efforts. Reduce the Babel and you reduce the effort’s cost and time, while increasing the effort’s resulting effectiveness and quality. So no Executive, Manager, Supervisor, Worker, or Contractor should operate a single day without a controlled vocabulary for their work scope and broader external environment.
Starting with the (III) Data Architecture first, to generate a "controlled vocabulary" of the enterprise, enables all subsequent EA and enterprise operation efforts to be performed with lessened "communication and agreement" costs.
Miscommunication and disagreement costs are common to "wild vocabulary" efforts in modeling the:
· (IV) Business Architecture ( with its interdependent strategic management efforts, its assignment of responsibility, the maturation of its guidance, and its formulation of its internal, boundary, and external security requirements and constraints),
· (I) Solution Architecture (with its inventory of capabilities and their composition and distribution across the business), and
· (II) Technology Architecture (with its inventory of technology standards, products and services that support those standards, and the mapping of the product and standard composition to each other).
To simplify and harmonize the overall EA effort, in parallel with the Bottom-up and Top-down EA activities, I therefore recommend that EA efforts go through the following (III) Data Architecture procedure first, before your (I) Solution, (II) Technology, and (IV) Business Architecture efforts, to reduce the inevitable costly and stultifying friction and rework that happen if everyone’s terms and symbols are not in harmony.
The Enterprise Architect will need to work closely with the organization to build the (III) Data Architecture independently of Business or Solution, to develop what I call an organization’s "intelligence inventory", which is also called a "controlled vocabulary". A controlled vocabulary builds intelligence capabilities also known as lexicons, glossaries, dictionaries, thesaurus, concept maps, ontologies, and axiologies. In direct relation to the speed and capacity of the communication media of the organization, this also provides the means for "lowest-detail to highest-detail " integration – starting with "human interoperability".
A controlled vocabulary can be used to add an individual’s personal intelligence into group intelligence, group intelligence into organization intelligence, organization intelligence into national intelligence, and national intelligence into the global intelligence, while simultaneously providing the mechanism for identifying/controlling appropriate access and sharing of that intelligence.
The procedure for this Data Architecture (intelligence inventory) is below.
==== Intelligence Inventory, Fusion, and Refinement Procedure ====
Subject: How to organize and share your information, awareness and learning, and to cooperate.
(A Procedure for Intelligence Fusion and Refinement)
There is a natural tendency of people with different vantage points and experiences to have ambiguous and divergent terms in their overlapping use of words, their vocabularies. An individual’s evolving vocabulary (i.e., the list of terms forming their "lexicon") is the basis for their joining and forming groups, communities of interest, communities of practice, etc. That is, people come together because of shared interests, a shared purpose, around a mutually-understandable vocabulary – their group’s "glossary". They control their glossary, and the definitions of the glossary terms, to maintain group cohesion, coherence, boundaries, and security. This is the ‘semantic analysis" part of their enterprise management architecture (EMA), within a broader general endeavor management (GEM) approach.
Below is a simple, and relatively easy, path to achieve shared group semantics - an understandable, and controlled group vocabulary – regardless of the size of the group. I submit that this procedure, while now using new technology and standards, has been applied by people throughout the history of our societies.
1. For each member seeking to join a group, have them collect a list of the words they typically use in the group or group-related activities, such as from their resume, their favorite books, and their local computer file system or favorite Internet web site.
2. Multiple individuals" lexicons, when merged into a group’s glossary, often have no definitions, or many, - they communicate based on non-validated, and thus often false, assumptions of understood meaning. So, for individuals joining or forming a group, a dictionary must be built for each individual’s lexicon. I recommend an online, and thus broadly accessible/sharable dictionary as the primary source of dictionary definitions, sense, etc.
3. These lexical dictionaries are then merged to build the group’s dictionary from its glossary (probably with multiple meanings per term).
4. Then, systematic efforts are pursued to build a minimized subject- tree (i.e., a taxonomy) of broader and narrow meanings (based on the definitions) about subjects of interest to the group.
5. Then a thesaurus is built to show the group’s preferred terms, and any subgroups" and individuals" alternate terms, along with abbreviations, acronyms, and alternate spellings for the terms.
6. Then subsequent "concept maps" are built from the terms to show how the subjects (i.e., same as SQL entities, XML Elements, or nouns) relate to each other (through verbs and verb phrases) from a given user’s, subgroup’s, and whole-group’s viewpoints.
7. Then data models (e.g., Object Role Models - ORM, or Entity/ Attribute Relationship Models) are built from the concept maps to show the attributes/behaviors/methods of a given defined subject in the concept map and of the relationships in the concept map.
8. Then process models (e.g., using the standard business process management notation - BPMN) representing the ‘sequence" relationships contained in the concept maps are extracted and organized to show the names of sequential activities arrayed across process-model "pools and lanes" representing the functional software applications, the application-owning organization units, and their parent organization, with each "pool or lane" also containing data on the physical/postal/ facility/geospatial or virtual/network/telephonic/radio-frequency location of the application, OU, or Organization.
9. Then, the now contextually-rich and content-rich process model and data model are diagrammed to provide a resultant dynamic model of knowledge (e.g., using the web ontology language - OWL) of the evolving viewpoints of the individuals, subgroups, and the full group.
10. Then, the ontology is populated with the data from individual, group, and organizational instances of the subject types and relationships between specific subjects, to provide an evolving/ adaptive sharable knowledge-base for the group to enable shared situational awareness and co-operation.
11. Repeat with each new group member, asking the new individual to use the group’s shared-knowledge-base as their online primary source of definitions, supplementing the group’s definitions as needed to evolve the group’s vocabulary using steps 3-10.
12. Repeat steps 3-10 when merging groups and establishing value- chains across individuals, groups, and organizations.
If you read the sequence above from an enterprise architecture (EA) perspective, you"ll see I"m talking about building a shared architecture for a group and its endeavors, based on building a controlled-vocabulary for the group. In the general endeavor management (GEM) approach, a full enterprise architecture is the above "knowledge-base" of the "enterprise", and the above "model of knowledge" (ontology) of the group is the "Metamodel" of the enterprise’s architecture. The above steps then provide a "methodology" for building both the Metamodel and shared knowledge- base called an enterprise architecture.
As to the technologies to use, the above steps can be performed with simple web pages, web tables, and a "lookup" mechanism for the tables" values, with a lot of procedural discipline and governance of the content. Alternately, you could use a ‘semantic wiki" tool like the one at [http://www.knoodl.com], in conjunction with concept mapping tools such as the CMap tool from [http://cmap.ihmc.us]. More automated and maintainable, you could use one of the extended metadata repository (XMDR) EA tools that have ontology management, knowledge-base (i.e., master data), and dynamic/semantic-application functionality such as the WebModeler from [http://www.Agilense.com] in the US and its equivalent NetModeler from [http://www.Pro-MIS.com] in non-US environments. Preferred, use Knoodl and CMap as low cost modeling tools for all-users, and migrate the results into the XMDR or ontology metadata repository as the foundation for automated semantic (shared knowledge-based) applications.
== Methodology Section 3 - Business Architecture ==
3. (IV) Business Architecture
To build the Top-down (IV) Business Architecture, consider the procedure below. Feed all the collected responses to these questions into the EA repository, noting that items 30 and 31 related to actual infrastructure and system development, deployment, operation, and maintenance, not enterprise architecture. However, these items form the basis for measuring compliance with the architecture and the success/fit of the architecture to the enterprise/function mission.
0. Identify your enterprise, most typically your organization. For your enterprise, identify the following to the degree you consider economical and relevant. Store and maintain all of this information in a single data store to reduce enterprise operational and analytical fragmentation.
1. What locations are relevant to you? Where do you operate?
2. What is your organization’s name? What are the organization names of your value-chain stakeholders (i.e., customers, suppliers, authorities, your own performers, your subordinate organizations, public groups, and partners), and what are their locations which are relevant to you?
3. What are your organization’s internal units, as typically portrayed as blocks on an organization chart, or more formally identified by a budget, plan, or program within your organization’s aggregate financial management plan? What are the relevant organization units of the value-chain organizations within your organization unit?
4. What are the functions (i.e., assigned work) performed by your organization units? What are the relevant functions performed by their relevant organization unit value-chains?
5. What is the mission of each organizational unit’s function?
6. What policy (minimally the values and perspective per the Carver Policy Governance method) governs the function?
7. Which person, identified by name, unique identifier, and assigned position, is responsible for achieving the function’s mission?
8. What is the boundary of the functional mission’s authority in terms of function, functional interfaces, organization units, organizations, and locations?
9. What is the responsible person’s vision of perfect mission performance?
10. What measurable goals has the responsible person defined to achieve the vision of perfect mission performance?
11. What performance targets (e.g., objectives), specified in terms of schedule, cost, and quality, has the responsible person defined to attain these goals?
12. What quantitative performance success indicators give proof of reaching the objective on time, within budget, to the required quality specified?
13. What strategies, including executing portfolios of investments to organized and prioritized to achieve the success indicators, will enable the responsible person to quantitatively prove, through meeting the specified performance indicators, that they have attained their objectives, and thus goals, and thus mission?
14. What plans, either for recurring (e.g., steady-state) operations or new initiative projects, will be used to implement each strategy?
15. What process will be followed in performing the planned recurring operation or initiative project?
16. What specific procedure will be followed at each defined step of the process, by which Organization Unit, within which Organization, at which Location?
17. What template will be used to collect or present information used in the procedure, and is this template automated (e.g., online form, web service) or manual (paper)?
18. What constraints, rules, or principles must be complied with in using the template?
(Overlapping/interfacing with Data Architecture in items 19-21)
19. What metadata does the template and constraint contain, and what specific semantically-controlled term does the metadata represent?
20. What is the unique ID for each metadata item in each template and each constraint?
21. What is the procedural transaction data for each metadata item in the template or constraint?
(Overlapping/interfacing with Solution and Technology Architectures in items 22 - 24)
22. What equipment, infrastructure, systems, software systems, supplies, and/or service is required to complete the procedure, in what quantity, with what qualities, on what schedule?
23. What category describes each equipment, infrastructure, systems, software systems, supply, and service resource, and is this category approved by the enterprise’s architecture (i.e., component and interface) control authority to avoid wild variance in enterprise resources?
24. What are the item/product/vendor specifics of the equipment, supply or service required for the procedure, and is this technology ubiquitous, in early adoption, or in the research stage?
25. What are the collected requirements, defined in terms of procedural performance resources, in specific quantities, with specific qualities, at specific times, at specific cost, for fully implementing the plans?
26. What is the budget in the current and future years for filling the requirements of the plans, for the strategies, in accomplishing the function’s objectives, goals, and mission?
27. What budget line items, in the aggregate, fully describe the requirement?
28. What elements of expense (i.e., pre-established categories of resources) categorize each budget line?
29. As sub-functions, what programs, as collections of inter-related projects, and which program and project managers, are given responsibility for satisfying the requirements?
30. What capability technology insertion, development, and deployment projects are governed by the Program and Project Managers, and what are their detailed performance schedule, budget, and quality constraints? (I recommend you use ANSI 632 System Engineering Process, and ISO 12207 Software Life Cycle Management as guidelines here)
31. What initial and recurring capability prototyping, operations, and maintenance are governed by the Program or Functional Managers, and what are their detailed performance schedule, budget, and quality constraints? (I recommend you use ANSI 632 System Engineering Process, and ISO 12207 Software Life Cycle Management as guidelines here).
== GEM Metamodels ==
Published Separately
== Supporting Technology Specifications ==
Published Separately
== GEM Life Cycle Operation, Assessment, Improvement, and Closure Procedures ==
Published Separately