2. GEM Methodology

2.    GEM Methodology (Implementation and Refinement Procedures)


=== 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) to support Enterprise Engineering (EE). 

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-stream, value-chain, value-lattice, 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 (e.g., DoDAF SVs/TVs), and

            (II) technology architecture (e.g., DoDAF SVs)
first, because these tend to deal with highly tangible, countable, identifiable, governable things such as implemented systems (e.g., IT, Transportation, Weapons, Infrastructure, Facilities).

The less tangible and more abstract:

          (III) data architecture
  • structuring semantics/metadata/data, which I also call "Intelligence Architecture" (as extended from of DoDAF OV2, OV7, and AV2)
(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) and DoDAF OV3 and OV6c,
    • across organization-unit by organization (e.g., DoDAF OV1, OV2, OV4) by location "performer lanes", as in BPMN, IDEF3, and DoDAF OV3, OV5, OV6c,
    • built from the typical organization-chart and organization’s financial "chart of accounts" (e.g., DoDAF OV4),
    • with each "performer" having their own distinctive corporate-mission-supporting functional mission/vision/goals/objectives/success-indicators (DoDAF AV1, OV1, OV2, OV3, OV4, OV5, OV6a, OV6b, OV6c, OV7), and
    • functional assignments to organization units with performance targets, authority boundaries, and budgets (DoDAF AV1 added detail, OV3 added detail, OV6c added detail)
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].