=== 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, e.g., DoDAF Acquisition Programs)) with their interface and scheduling dependencies, and

            (II-1) a "technology reference catalog" (i.e., DoDAF TV1) 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  (DoDAF TV1), 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 (e.g., DoDAF Acq Programs) 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 (i.e., DoDAF SVs) 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 (DoDAF Acq Programs), and (I-1/A-E/a-h) IT capability parts (DoDAF SVs) can be arrayed in comparison to each other and to the (II-1) Technology Reference Catalog (DoDAF TV1) 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) (e.g., DoD DISR),

            (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