Page 1 of 1

Technology Provider Standards Management

Posted: 25 Jun 2013, 17:47
by Kevin Campbell
I'm trying to get to grips with the standards management classes, and find myself a bit stymied - any chance of some pointers?

We've adopted an approach very similar to that espoused by Gartner and implemented at the National Institutes of Health (https://enterprisearchitecture.nih.gov/ ... Brick.aspx). We publish a standards Brick for each technology component, showing all technology products which have that role and using the lifecycle status to place them in the appropriate section of the "brick". With that as a context I'm not quite sure how the new Standards Management classes are intended to be used - is it for the act of refreshing the standards themselves rather than capturing the content of the standard?

Re: Technology Provider Standards Management

Posted: 19 Jul 2013, 14:08
by jonathan.carter
Hi Kevin.

The approach you've taken is still supported and you can continue with that. However, we found that there are scenarios where this wasn't clear enough and in particular when we needed to define Lifecycle Models, having the lifecycle status being used to defined standards was overloading the semantics of lifecycle status.

The idea with the Standards Management classes is that we an define standards with a name for each standard and then define the standard in terms of which providers should be used. For example, we can define a technology standard that describes the use of a particular Technology Product to provide a Component and then define the context in which the standard applies (geographic, organisational). We also have a slot (Standard Usage) to relate the Technology Standard to an Application Service so that we can associate types of Application in which this standard applies.

This means that we can have different technology standards for different Applications - if we need to! The same pattern is used caroused the main EA layers, so we can defined business, information, application and technology standards, with scope for future additions within the 4 main subclasses of Standards_Management.

Finally, we can define a Lifecycle Model (another EMM 4.0 new addition) for the standard, meaning that we can have standards that are past, current, future.

If the approach that you've taken is still working for you - continue with it. Many of the out-of-the-box views will support this. However, if you need more complex / subtle standards, then the new Standards Management classes will help.

Jonathan