PLM & Semantics Part 3 - Requirements Taxonomies

One of the most obvious and easiest ways to see how Semantics or Semantic Integration drives Program Lifecycle Management (PLM) is through Requirements Management or Engineering and the development of taxonomies. It is often more likely that you will be faced with immediate project support tasks than a more global enterprise definition effort (either as part of a data standardization, COI or MDM initiative).

Every project though must have some level of requirements vetting in order to satisfy expectations for potential return on investment or affordability. These types of efforts are generally manual although some folks use models to help with cost estimation. At some point though, the high level or functional Requirements and Work Breakdown Structure (WBS) must be defined in order to set up project schedules.

With PLM, we can tackle this by developing a Semantic blueprint or foundation. The way I've approached this before is to use preliminary visualization tool (mind map or concept) to illustrate the functional requirements and the relationships between them. I then designate that as a Domain Taxonomy (or ontology depending on how detailed the relationship information is). The Domain Taxonomy then represents the pool of available terms groups and sub-groups with which to build logically relevant WBS segments. Then I build requirements taxonomy within my automation environment and extract the WBS from it. Thus I have elements of EA design, semantic correlation and project coordination all wrapped up within one activity. This makes it possible to track from:

• Strategy to EA
• EA to Functional Requirements (the 1st level or elementary taxonomy)
  
• Functional Requirements to WBS (abstraction of 1st level taxonomy)
  
• WBS to Technical Requirements (the 2nd level or detailed taxonomy)
• Technical Requirements (precise) to Project Schedules (schedule & detailed requirements taxonomy should map nearly one to one)
  
• Project Schedules to Roadmaps & What if Alternatives
• and everything back to Strategy
  

Understanding functional requirements implies domain knowledge, both in terms of domain entities and relationships.

Copyright 2008, Semantech Inc.

PLM & Semantics - Part 2: Ontologies

What are Ontologies and What do they have to do with Program Management? Well, they are the hidden 'maps' that link together all aspects of process, data and system architecture. An Ontology in our context, refers to characterization of conceptual hierarchies and their relationships within the enterprise. ITIL for example is an Ontology.

An Ontology fits within a spectrum of terms used to define various levels within a Semantic framework. Many people consider the Ontology or a Shared Upper Level Ontology to represent the pinnacle of Semantic constructs, however this is not the case. As we have experienced in many enterprises 'forced to integrate,' many Ontologies from diverse communities often come together in "Sets."




The Semantic Hierarchy or "Spectrum" - Most of us don't realize when we're viewing these...

So, what can organizing our information within these "spectra" do for us as managers? The 1st thing it will do is to abstract your program information from the systems and sources where it currently resides. This is a much bigger issue than it seems - if your framework for running a complex enterprise is dependent on a set of unreconciled COTs tools and MS Office documents, it is hardly likely that your enterprise can ever be truly run through unified Lifecycle Management approach. The Semantic layer that you develop serves as a foundation for both solution design and oversight thereby unifying them from the start. This is a powerful bit of synergy.

In the Department of Defense, many programs have used something referred to as a Community of Interest (COI) for the last few years to help define the data paradigms behind each "functional" area of their programs. At first, these were viewed more like traditional data standardization efforts but increasingly they are being managed using Semantic technologies and integrated with Enterprise Architecture initiatives.



This example illustrates how various taxonomies are typically mapped together in an EA -like analysis.


Copyright 2008, Semantech Inc.