We tend to develop technology Standards at the Technology Component level, often listing several technology providers with an appropriate lifecycle status for each role.
We have the concept of an "enforcement level" for each documented component indicating the degree to which Standards compliance is checked - Guideline, Best Practice and Standard. Within our project governance it is forbidden to introduce a new technology provider if a Production alternative exists for a Component published as a Standard. If the component is a "Best Practice" then the Shall becomes a Should.
It's not immediately clear how the Essential meta-model might support this. The ratification of a component, and its providers, as a Standard is a formal process with a scheduled review frequency. Guildelines serve merely to document the "as-is" without picking a winner from potentially competing technologies, and Best Practices tend to precede the publication of a Standard, indicating the likely direction.
Suggestions welcome!
Standards compliance
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
The whole issue of a Technology Product being capable of being used for a certain purpose and whether or not that is something that the EA team approve of, tolerate, discourage or even ban(!) is an important concept.
To provide the capability to capture these issues, we use the Technology Product Role meta class.
This follows a similar pattern to the Actor To Role relation, and defines the relationship between a Technology Product and a Technology Component - that the Product can be used to provide a Component.
Importantly, this Technology Product Role class has an important attribute called 'Strategic Lifecycle Status' which defines the current status of this Product being used for that Component - e.g. production [approved, standard], pilot [can be used, but you need a waiver], off strategy.
This status attribute enables you to pick from a list of Lifecycle Status values, which is an enumeration that you can extend etc. to meet your requirements. For example, you might find that the names that we've used don't quite match, so you could change the 'Enumeration Value' field of these to fit your standardisation/compliance terms. This is the value that's used where ever the status is displayed, but the Essential Viewer views use the 'Enumeration Name' value. So, if you change Value field, all the supplied Views will continue to work as before but displaying your terms.
This concept of the Technology Components being delivered or provided by Products can also be applied to Technology Architectures (or builds), too. So, we can have logical component architectures defined in terms of Technology Components, and then have these architectures provided by 'builds' of Technology Products. So, we can define how certain standard technology product builds can be used in our architecture, using a similar meta class, called Technology Product Build Role.
You can find the Technology Product Build and Technology Product Build Roles under the Technology Provider Role super class in the Logical Technology view of the meta model.
In both the sample repository and the baseline repository, we've pre-defined a bunch of Technology Product Roles but note that none of them have any status associated with them, as that will vary from enterprise to enterprise.
Let me know how you get on or have any questions about tweaking the names of the Lifecycle Status instances to meet your needs
Jonathan
To provide the capability to capture these issues, we use the Technology Product Role meta class.
This follows a similar pattern to the Actor To Role relation, and defines the relationship between a Technology Product and a Technology Component - that the Product can be used to provide a Component.
Importantly, this Technology Product Role class has an important attribute called 'Strategic Lifecycle Status' which defines the current status of this Product being used for that Component - e.g. production [approved, standard], pilot [can be used, but you need a waiver], off strategy.
This status attribute enables you to pick from a list of Lifecycle Status values, which is an enumeration that you can extend etc. to meet your requirements. For example, you might find that the names that we've used don't quite match, so you could change the 'Enumeration Value' field of these to fit your standardisation/compliance terms. This is the value that's used where ever the status is displayed, but the Essential Viewer views use the 'Enumeration Name' value. So, if you change Value field, all the supplied Views will continue to work as before but displaying your terms.
This concept of the Technology Components being delivered or provided by Products can also be applied to Technology Architectures (or builds), too. So, we can have logical component architectures defined in terms of Technology Components, and then have these architectures provided by 'builds' of Technology Products. So, we can define how certain standard technology product builds can be used in our architecture, using a similar meta class, called Technology Product Build Role.
You can find the Technology Product Build and Technology Product Build Roles under the Technology Provider Role super class in the Logical Technology view of the meta model.
In both the sample repository and the baseline repository, we've pre-defined a bunch of Technology Product Roles but note that none of them have any status associated with them, as that will vary from enterprise to enterprise.
Let me know how you get on or have any questions about tweaking the names of the Lifecycle Status instances to meet your needs
Jonathan
Essential Project Team
-
Kevin Campbell
- Posts: 40
- Joined: 13 Sep 2010, 20:26
Thanks Jonathan
Here's the scenario: EA is a new function within the organization, which has a diverse "default" architecture. Throughout the enterprise technology products are providing functionality in production, today.
Our first task is to begin pragmatically documenting the as-is architecture, and to then look for opportunities to simplify by eliminating overlapping technologies. In the act of documenting the technology providers we are often able to classify their lifecycle status based on our knowledge of the product or its usage - and in the process begin to identify the "survivor" for ratification as a production Standard.
The challenge is that we view the ratification status as distinct from the lifecycle status of the technology provider. As a first cut I may identify Windows 7 as a Production Standard and Windows XP as retirement - but that categorization is itself subject to ratification. The entries on the Technology Component form, which is similar to the Standards "Brick" put forward by Gartner and others, are initially considered to be Guidelines until they are approved, at which point they become a Standard. So it's the status of the Technology Component instance itself that is Guideline, Best Practice or Standard - and that drives compliance and enforcement of the various lifecycle dispositions.
Does that make sense?
Here's the scenario: EA is a new function within the organization, which has a diverse "default" architecture. Throughout the enterprise technology products are providing functionality in production, today.
Our first task is to begin pragmatically documenting the as-is architecture, and to then look for opportunities to simplify by eliminating overlapping technologies. In the act of documenting the technology providers we are often able to classify their lifecycle status based on our knowledge of the product or its usage - and in the process begin to identify the "survivor" for ratification as a production Standard.
The challenge is that we view the ratification status as distinct from the lifecycle status of the technology provider. As a first cut I may identify Windows 7 as a Production Standard and Windows XP as retirement - but that categorization is itself subject to ratification. The entries on the Technology Component form, which is similar to the Standards "Brick" put forward by Gartner and others, are initially considered to be Guidelines until they are approved, at which point they become a Standard. So it's the status of the Technology Component instance itself that is Guideline, Best Practice or Standard - and that drives compliance and enforcement of the various lifecycle dispositions.
Does that make sense?
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Yes, makes sense.
What you need is the ability to manage and relate the ratification process for any changes to the 'lifecycle status' of a Technology Component - assuming that we agree that the lifecycle status against a Technology Product (via the Technology Product Role) reflects the standard(s) for the Technology Component.
The attributes on both the Technology Component and Technology Product reflect the status of these elements at this point in time. We view the Essential ontology as operating as a 'live' repository so that it always reflects the way things are in the enterprise right now.
As you say, this isn't going to help with managing any plans for how the standard might change - including where we are in the ratification process for that standard.
To capture things like this, we have what we call Strategic Plans in the EA_Support part of the meta model. The idea of these is that you can define plans (at the strategic rather than project level, if you see what I mean) for any element in the architecture. Each plan can be active, future or even historical (old) and has a Planning Action associated with it, which are managed in the same way as Lifecycle Status and you can add as many Planning Actions as you require. I've used this in the past to capture the fact that we are retiring an application (e.g. the current, ageing ERP) during a defined timescale (attributes of the Strategic Plan). Also, we can relate Strategic Plans to other Strategic Plans, and in my example of the ageing ERP, I created a new Strategic Plan to capture the introduction of the replacement ERP system.
We could define some Planning Actions to reflect the stages of the change to the standard (e.g. Standard Recommended, Standard Ratified) and relate these Plans to the Technology Product.
The out-of-the-box Views in Essential Viewer render any Strategic Plans that might be associated with a Technology Product, Application Provider etc.
There are some additional extensions to the Strategic Plans that are being introduced as part of ECP-4. These introduce explicit Roadmaps for strategy and the Strategic Plans can then be associated with specific Projects that will deliver this Plan. Also, ECP-7, which introduces constructs to help manage Business Objectives (which have relationships to the Roadmaps) in terms of organisations that they apply to (e.g. for federated or extended enterprises) introduces a new, better way or representing Time. I think we'll use this to update the valid from and valid to attributes of the Strategic Plans.
Having introduced the Roadmaps, it could be that these are also helpful in supporting what you need to achieve. The point of these is that they relate Architecture States, capturing (through the Strategic Plans) how we plan to move from one state to another.
Stepping back from those, I think it might be worth having a look at whether the Strategic Plans are sufficient to meet your current requirements. In essence, what these capture is what we plan to do with a specific element of the architecture in a specified timeframe. As I mentioned, you can easily extend the set of pre-supplied Planning Actions to cover the actions of moving a Technology element through the strategic standards process. Note that it's up to you to reflect the outcomes of that process, e.g. in terms of updating status of the relevant Strategic Plan ('active', to 'old' maybe?) or defining an active plan showing that a product is now 'the standard' over a specific, agreed timeframe. These plans will then show up by default in the Views - e.g. the Technology Product Details - showing what we plan to do with this product.
I think the key question is whether the standards management process is significantly different - that is, has truly different semantics - to any other process that is performance as part of managing our strategy for technology? Currently, I'm not sure that they are and so hopefully the Strategic Plans construct should work.
Let me know what your thoughts are on this.
Jonathan
What you need is the ability to manage and relate the ratification process for any changes to the 'lifecycle status' of a Technology Component - assuming that we agree that the lifecycle status against a Technology Product (via the Technology Product Role) reflects the standard(s) for the Technology Component.
The attributes on both the Technology Component and Technology Product reflect the status of these elements at this point in time. We view the Essential ontology as operating as a 'live' repository so that it always reflects the way things are in the enterprise right now.
As you say, this isn't going to help with managing any plans for how the standard might change - including where we are in the ratification process for that standard.
To capture things like this, we have what we call Strategic Plans in the EA_Support part of the meta model. The idea of these is that you can define plans (at the strategic rather than project level, if you see what I mean) for any element in the architecture. Each plan can be active, future or even historical (old) and has a Planning Action associated with it, which are managed in the same way as Lifecycle Status and you can add as many Planning Actions as you require. I've used this in the past to capture the fact that we are retiring an application (e.g. the current, ageing ERP) during a defined timescale (attributes of the Strategic Plan). Also, we can relate Strategic Plans to other Strategic Plans, and in my example of the ageing ERP, I created a new Strategic Plan to capture the introduction of the replacement ERP system.
We could define some Planning Actions to reflect the stages of the change to the standard (e.g. Standard Recommended, Standard Ratified) and relate these Plans to the Technology Product.
The out-of-the-box Views in Essential Viewer render any Strategic Plans that might be associated with a Technology Product, Application Provider etc.
There are some additional extensions to the Strategic Plans that are being introduced as part of ECP-4. These introduce explicit Roadmaps for strategy and the Strategic Plans can then be associated with specific Projects that will deliver this Plan. Also, ECP-7, which introduces constructs to help manage Business Objectives (which have relationships to the Roadmaps) in terms of organisations that they apply to (e.g. for federated or extended enterprises) introduces a new, better way or representing Time. I think we'll use this to update the valid from and valid to attributes of the Strategic Plans.
Having introduced the Roadmaps, it could be that these are also helpful in supporting what you need to achieve. The point of these is that they relate Architecture States, capturing (through the Strategic Plans) how we plan to move from one state to another.
Stepping back from those, I think it might be worth having a look at whether the Strategic Plans are sufficient to meet your current requirements. In essence, what these capture is what we plan to do with a specific element of the architecture in a specified timeframe. As I mentioned, you can easily extend the set of pre-supplied Planning Actions to cover the actions of moving a Technology element through the strategic standards process. Note that it's up to you to reflect the outcomes of that process, e.g. in terms of updating status of the relevant Strategic Plan ('active', to 'old' maybe?) or defining an active plan showing that a product is now 'the standard' over a specific, agreed timeframe. These plans will then show up by default in the Views - e.g. the Technology Product Details - showing what we plan to do with this product.
I think the key question is whether the standards management process is significantly different - that is, has truly different semantics - to any other process that is performance as part of managing our strategy for technology? Currently, I'm not sure that they are and so hopefully the Strategic Plans construct should work.
Let me know what your thoughts are on this.
Jonathan
Essential Project Team
