Legacy Issue Number: 18741
Source: MITRE ( Fatma Dandashi)
In UPDM it seems that the Service to OperationalActivity matrix is non-editable. The relations are established after one creates capability to OpAct relations and capability to service relations (in CV-6 and CV-7/NSOV-3 respectively). This may be how it is explained in DODAF/ MODAF? (no direct relation between ServiceInterface and OperationalActivity:
But it is not how it should be. Here is why: CV-7 is useful when considering how services that may already be available (internally to subject architecture scope, or provided by third party entities) can be leveraged to enable the required capabilities. However, a true model-based approach to capability development and analysis will include an operational view model that further delineates the capability (stated as a term and a definition) and describes the ways and means needed or provided to enable the capability. Such an analysis usually uncovers issues with the defined capability taxonomy such as overlapping or non-mutually exclusive capabilities, and will lead to a better formulation of the capability taxonomy. The operational model is also used as a guide to develop or identify needed services in a service model. Thus, it is good SE discipline not to try and develop CV-7 starting with two sets of taxonomies, one for capabilities and another for services, without conducting the necessary modelling of operational and service artifacts needed, conducting the analysis, and “discovering” the relationships between capabilities and the services needed to enable them. So I propose that the order is like this:
1. develop a Capability taxonomy (CV-2);
2. develop Operational views (especially the behavior diagrams)
3. iterate on capability taxonomy and op behavior until one is somewhat satisfied that the capability taxonomy and operational elements (as modeled) are consistent and capabilities are well delineated. At this time a CV-6, (Capabilities x Operational Activities) matrix may be generated;
4. develop a service view model that supports the operational model and evaluate the ability of the enterprise to offer each Capability and make a Build versus Buy/Outsource decision. Some more iterations on elements in CV, OV, and SOV may take place again, especially as the services taxonomy and service orchestration diagrams are developed. That is, the service model may cause Operational Activities as well as capability taxonomy to change again. Once things stabilize, an SvcV-5/NSOV-3 (Services x Operational Activities) matrix may be generated;
a. For those Capabilities that will continue to use existing systems within the Enterprise, model their As-Is Systems Views;
b. For those that are to be Built, or are to be Bought, model the the Services Views to identify (conduct an analysis on what is available within and outside enterprise), and identify the contractual Service-Level Agreements and indicate the Service orchestration with the Enterprise's Performers.
i. For services to be built, proceed to detail in systems view
ii. For services to be outsourced stop detail here (services view) but show they are used in systems view (via service request interfaces for system components.
5. when one feels that the operational and services models satisfy the updated capability taxonomy, one can generate (from the relationships already established), the Capabilities x Services (CV-7) matrix
6. Develop Systems Views and then map (system) Functions to Services and Functions to Operational Activities.
Reported: UPDM 2.1 — Wed, 29 May 2013 04:00 GMT
Updated: Mon, 27 Mar 2017 00:28 GMT