ECP-4 Strategy Management

Post Reply
User avatar
jonathan.carter
Posts: 946
Joined: 04 Feb 2009, 15:44

09 Sep 2009, 16:48

ECP-4 upgrades the Strategy Management part of the Essential Meta Model to provide support for defining and managing Architecture States in the repository.
An Architecture State is a grouping of elements from the Essential Repository that are linked in that they all exist in a particular state of the architecture. Obvious examples would be current state or future state but Architecture States are also used to capture roadmap states that exist as steps in the evolution of the architecture from one state to another.

In practice, it is expected that many architecture states will be defined in the repository, each capturing the development of particular areas of the architecture. e.g. Architecture States for the technology architecture roadmap, business process improvement or application rationalisation plans.

Constructs for defining and managing the architectural roadmaps are also included as part of this extension to the Strategy Management area. Roadmaps provide the capability to define how architecture states are related in terms of the development of the architecture. Timeline milestones can be related to each state in the roadmap and the dependencies between architecture states not only define the link from, e.g. current state to roadmap state A, but also capture the Strategic Plans that support this transition. e.g. Retiring a particular application or introducing a new business process.

As this set of meta classes and relationships have already been developed by the Essential Project team (but did not make it into the first release of the meta model), this ECP will fast-track the delivery of these classes and relationships as a meta model extension, using a sample Essential Repository to review and test the existing capability. Therefore, a UML class model for this extension will not be produced. Rather, the first deliverable will be an Essential Repository (Protege project files) for review and further development.

Jonathan
Essential Project Team

User avatar
jonathan.carter
Posts: 946
Joined: 04 Feb 2009, 15:44

20 Oct 2009, 14:46

As described above, to move ECP-4 forward, rather than post a UML description of the meta model extensions, I've created a sample repository based on the Essential Sample Repository, with all the latest ECP updates applied. Note that these updates will not be pre-requisites for using the Strategy Management meta model components. In this post, I describe the proposed meta model for Strategy Management.

Strategy Management connected to Change Management
This ECP builds on and re-works some existing meta classes for Strategy Management, providing the capability to define groupings of architectural elements into states use these to define strategic roadmaps to move the organisation from state to state. While re-working existing meta classes to fully support the definition of states and roadmaps, an understanding of how the elements of Strategy Management connect to Change Management has been crystallised. The strategic plans that move the organisation from state to state in a roadmap are delivered through Projects (Change Management), all of which are related to the Objectives that they are meeting.

Key Concepts
New meta classes are introduced to provide the components for Strategy Management, as follows:

Architecture State, which groups together a set of architecture 'elements' across all of the '12 boxes' of the Essential Meta Model. Think of it as drawing a line around an arbitrary bunch of things (processes, application services, technology nodes, anything else.). A state should be named to reflect what it is that the grouping represents, avoiding temporal terms such as 'Current State', 'Future State'. Rather, we believe it is far more useful to have many states defined in the repository, e.g. the Straight-through-processing architecture state, the operational infrastructure architecture. Each State has fields for including elements from each of the '12 boxes' and this collection defines the Architecture State. The architecture state is just a grouping or 'configuration' of part of the overall enterprise architecture. It could be a configuration of the entire enterprise architecture but I think it's more useful/pragmatic/useable to break it down into manageable chunks. This state could be used in the context of a Project (and it is as the start and goal states) as well as as a Milestone in a Roadmap and as such you won't always be defining states in the context of meeting objectives. 

Roadmap Milestone, which are the nodes/boxes on the roadmap model and each Milestone is a usage of an architecture state in the context of that roadmap model. It has very few attributes just the architecture state that's being used, a link to the roadmap that it is used in and the set of Objectives (Business, Information Architecture, Application Architecture and Technology Architecture Objectives) that are being met by reaching this milestone. That is, which objectives to we expect to have met when we reach this Milestone? Why are we moving to it? We can then compare these with the objectives met by the Strategic Plans on the transitions (there can be many transitions between 2 Milestones or 2 Milestones may transition to a single Milestone.) and see what's missing.

Roadmap Model, which defines how you move from one Milestone (usage of an architecture state) to another. Timeline points can be defined on the roadmap to provide some rough timeline (temporal framework) for when the milestones are aimed to be met. The Roadmap Model is defined graphically with the Milestones and Timeline points as nodes and the transitions between Milestones defined using arcs on the diagram. Each of these relations - the Roadmap Transitions - has a field to capture the Strategic Plans that are used to make the transition happen.

Note that the Strategic Plans are not equivalent to Programmes (from Change Management), rather it is a strategic-level thing that states 'what' is going to be done and roughly when but has no actual plans for how this will be done. It enables you to define the dependencies between Strategic Plans (e.g. we have to do X before we do Y) but basically they make statements about what we plan to do. These Strategic Plans now have a relationship to the Objectives that are being 'supported'. i.e. "we are doing this thing [the Strategic Plan] to meet our Objective, X"
This relationship is new from ECP-4.
The Strategic Plans have Projects (this is the connection to Change Management) that are used to do the "how" and "implementation" of making it happen. Programmes are groups of related projects that need cross-project coordination.
The revised relationships for Strategic Plans are:

- Strategic Plan supports Objectives
- Strategic Plans are supported by/implemented by Projects
- Projects are grouped into Programmes. (this isn't implemented in the meta model at the moment - there is still a little work to do on Programmes as part of this ECP).

As mentioned above, the Project meta class has been extended such that it no longer has an associated Technology Architecture. Now the Project meta class has a starting state (a relationship to an Architecture State that defines the scope of elements from Business through to Technology) and a goal state that defines the configuration of the architecture (in scope) that will be delivered when the Project is completed. Again, the goal state is defined by an Architecture State.

What will all this enable us to do?
The Business, Application, Information and Technology Architecture Objectives are things that are high level and so make sense for Strategic Plans and Roadmaps which are equally high level (as opposed to more detailed Projects or even project plans). These then define the context and reason for all other work that goes on in the organisation and provides the grounding for "why" all change is happening. So, we can report on WHY we are doing a project from the Strategic Plans that it supports. We wouldn't relate the Project directly to objectives? If we had objectives associated with a start or goal state of a Project then the modelling will quickly get over-complex and potentially out of control. It is important and helpful to keep different levels of abstraction separate.

All this means that it is the Roadmaps where we work with how the organisation changes to meet its Objectives. As we talked about above, we can then report on any Objectives that are not being met by the transitions (Strategic Plans) defined in the Roadmap Model. Similarly, we can identify any Milestones that have no objectives. Why are we transitioning to that Milestone, if it does not meet any objectives?

Explore the sample repository
Download and explore the sample repository from the Share Area, which includes some very basic examples to start testing the meta classes and their relationships.
These examples need to be expanded and possibly re-worked to reflect more realistic scenarios. However, hopefully there is enough there to get started.
If there are additional capabilities that have been missed, please don't hesitate to post back in this topic with your needs and suggestions.

Next steps
As per the Essential Community Process, this extension is now open for review by the Community. Once the review has been completed and any further developments applied and reviewed, the extension will be released for 'production' use.

Jonathan
Essential Project Team

User avatar
jonathan.carter
Posts: 946
Joined: 04 Feb 2009, 15:44

12 Jan 2010, 14:43

Just a quick update on the progress of ECP-4.

Although this topic has been quiet for a little while, we are currently road-testing this in a real-world application. ECP-4 will move to the release status of the ECP process once this is complete.

The current release can be used in the meantime as we are finding that it supports our current real-world requirements.
Please let me know if you are doing so and I will create an upgrade pack to introduce any changes from the current version to the first full release when the ECP process completes.

Jonathan
Essential Project Team

Kevin Campbell
Posts: 41
Joined: 13 Sep 2010, 20:26

07 Oct 2010, 16:24

I'd like to register interest in this ECP. Any chance that the model extensions could be provided as a script rather than as a sample repository?

Kevin

User avatar
jonathan.carter
Posts: 946
Joined: 04 Feb 2009, 15:44

07 Oct 2010, 17:30

That would be great, Kevin.

I'm working on some update packs at the moment and I'll get the script for this included. I've actually added a couple of useful features into ECP-7 (e.g. a class to manage time values) that will update some of the classes - like the Strategic Plans and Roadmap Milestones in this ECP.
Fortunately, ECP-7 builds on ECP-4, so the pack for 7 will cover all this.

I'll get this released to this (and the ECP-7) ECP as soon as possible.

Jonathan
Essential Project Team

aba
Posts: 7
Joined: 14 Dec 2009, 20:38

02 Nov 2010, 15:34

Hi,
we need to define architecturals states, assigned to milestones of a roadmap. Perfect match with your meta model ...
But: We need to not only specify that an EA element is part of an architectural state, but also how it changed up to this point in time. We need to be able to show that e.g. an application provider has been retired when a state is reached. Or that another one has been build and is a new application in the IT landscape at a given milestone.
So my question is, how it is possible to assign change information rather than static "will be part of" information.

Regards,
aba

aba
Posts: 7
Joined: 14 Dec 2009, 20:38

08 Nov 2010, 17:51

Hi all,
we found the answer to our "problem" - it is the relationship object between two milestones, that gives us the required change information (by the reference to strategic plan objects).

Beside our question:
You asked for feedback regarding ECP-4 Strategic Planning. We plan to use it right now, and therefore had an in depth look on the model. We know pretty well what we need to model - and we could say that ECP-4 fits our needs very well.

Web Viewer question: It would be a great help to not "only" have a simple web navigation through the data model, but instead have a two dimensional matrix like "Application lifecycle over time/milestones", showing the applications involved in a roadmap and their planned life cylce status per milestone.
Do you plan to provide a similar web view?

ECP release plan question: Could you please help us to understand, if or when ECP-4 is released? Is it included in antoher ECP?

Thanks very much for your support,
aba

User avatar
jonathan.carter
Posts: 946
Joined: 04 Feb 2009, 15:44

09 Nov 2010, 11:09

Hi Aba,

Thanks very much for posting back - apologies for the delay in replying.
Glad to hear that you've found what you need and actually in answering your last post, we realised that there is something missing from the meta model, which we're going to add as part of this ECP - and then get this ECP out as an extension pack.

What your last post raised for us was that although the roadmaps have the relationships between architecture states and those relationships have the Strategic Plans associated with them (so we can capture how we plan to move from one state to another), the current meta model doesn't enable us to show how a new version of an element, e.g. an Application Provider supersedes an existing element. In the same way as you will see in the Technology Products, a new version of something is a new instance in its own right. So, if I create version 2 of MyApp, then I create an Application Provider, e.g. 'MyApp v2.0' which I want to have supersede version (e.g. 'MyApp').

All of the above is there in the meta model and we can use things like the Application meta class to group these - and probably better the new Taxonomies that we have coming as part of ECP-7. However, we can't currently capture the relationship that 'MyApp v2.0' is replacing/superseding 'MyApp'.

Therefore, to meet this requirement, we're going to add a new relationship field to every EA_Class in the meta model as part of this ECP (ECP-4). This enables us to capture the fact that one element supersedes another one. This is a different dimension to the planning view that Strategic Plans give us and also what the Lifecycle Status does. The idea is that this new relationship will enable us to capture that v2.0 is the new version of v1.0 and v3.0 is the new version of v2.0 whilst the Lifecycle Status can show that in the early stages, v2.0 might be in pilot while v1.0 is still production etc.

We will add this new field to ECP-4 and release an update pack so that all this strategy management capability can be introduced into existing repositories.

On the issue of understanding the changes between Architecture States (what's the difference between where we are and where we want to be?) or even the difference between versions of e.g. processes, applications, technology architectures, architecture states, roadmaps even, the approach is to create a view that shows the differences. The knowledge is available in the meta model, but a 'what's changed' view could quickly get so large that it's not easily viewed. Therefore, we'd suggest that it's best to produce specific 'differences' views for particular perspectives. e.g. What processes have changed between two Architecture States.

This is pretty much how we would approach a view along the lines that you have asked for in this post. The view you describe makes a lot of sense and would be valuable. I think the whole Strategy Management/Roadmaps/Architecture States area has the potential for a great number of really powerful views and we're working on some more 'general' ones to help provide the common requirements and help users with getting started on their own more specific views - and we'd be more than happy to help the Project Community with such views.
We haven't got the one you mention on our plan, yet, but we'll add it to the set - and I agree that adding the temporal or versions dimension to views of the roadmaps is very helpful and powerful.

Just to clarify your question on ECP-4 itself. This is still in the testing/enhancements phase - and your post came at a good time. We're going to add the new slot I described above and then release the meta model update pack, which will release ECP-4 as an extension to the baseline meta model. Hopefully, we'll get this out in the next week or so.

Jonathan
Essential Project Team

nmerricks
Posts: 4
Joined: 08 Sep 2010, 19:23

12 Nov 2010, 13:51

Jon, could you clarify (or consider to include) whether this would be applicable across technologies as well as applications. I have spent some time, outside of any EA tool, working out technology roadmaps for commercial products including software and hardware where I needed to consider pre-release or beta test products, general availability release, ‘release into production’ in our own environment, in-service support, patch updates, extended support, out-of-support, et al. Whilst I have seen these things catered for in ‘applications’, much of what I have worked with has been ‘technology’ in Essential-speak, but it still needs those same or similar considerations. Are you thinking along these lines, or is this already what you are saying above?

Keep up the good work

User avatar
jonathan.carter
Posts: 946
Joined: 04 Feb 2009, 15:44

12 Nov 2010, 15:41

Absolutely. This superseding version attribute that I'm sorting out right now will be available for all meta classes, and as you say will be particularly useful for Technology Products - enabling you to define that, e.g. Oracle 11g is a version that replaces / supersedes Oracle 10g. Currently, we don't have those specific semantics.
You will be able to use this to show how one Technology Product Build is the 'new version' of another build and so on.

This means that we will be able to define that Product B supersedes Product A and using the Lifecycle Status class show how initially B might be in pilot while A is still in production, then, over time, that B is now production while A is now in sunset etc.
Just to close this off, we can use the Strategic Plans to show how we plan to make this happen. The plans have timeframes associated with them, so in order to track how we're currently positioned with respect to the plans, we're looking at evolving the Lifecycle Status class to introduce a relationship class that enables us to capture WHEN that Lifecycle Status occurred. i.e. when did Product B move to "production"?
We will most likely introduce this as a separate update, though.

Thanks for the input!

Jonathan
Essential Project Team

aba
Posts: 7
Joined: 14 Dec 2009, 20:38

24 Nov 2010, 15:40

Hi Jonathan,
just wanted to ask if ECP-4 has been released now?

Regards

User avatar
jonathan.carter
Posts: 946
Joined: 04 Feb 2009, 15:44

24 Nov 2010, 16:09

Thanks for your post.

We're just making some final small adjustments to the meta model. There are some very useful things that have come out of ECP-7 that make ECP-4 work better and so I think we're likely to release these two together. Hopefully, we'll get it released this week.

Jonathan
Essential Project Team

aba
Posts: 7
Joined: 14 Dec 2009, 20:38

30 Nov 2010, 16:02

Hi Jonathan,
since we wön't wait to long for the release of ECP-4, we decided to start now based on your latest demo repository for Strategy Mgmt.

One additional point for the meta model: Allow EA_Relation classes for Strategic plans.
Background: We want to model an application roadmap, that reflects changes reagrding the specific support of an application for business processes (e.g. Application XY will continue to support Process A, but will no longer support Process B in the future). That means we want to assing Strategic_Plans to the transition relationship between roadmap milestones, where the plan instances refer to APP_PRO_TO_PHYS_BUS_RELATION instances. Therefore it would be helpful to allow EA_Relations for the slot "strategic_plan_for_element" on the level of class Strategic_Plan, and Application_Relationship on the level of class Application_Strategic_Plan.

It would be great to have your feedback on that issue.

Regards, aba

User avatar
jonathan.carter
Posts: 946
Joined: 04 Feb 2009, 15:44

07 Dec 2010, 12:57

Hi Aba,

Thanks very much for this posting. That's an excellent example - and another could be the Actor To Role Relation.

We've just finished the meta model update pack (there were a number of tricky migration scenarios to cover) and are working on a couple of basic views for the roadmaps. However, I want to make sure that we've covered this requirement.

I'll get back to you later today on how we take this forward.

Thanks

Jonathan
Essential Project Team

User avatar
jonathan.carter
Posts: 946
Joined: 04 Feb 2009, 15:44

07 Dec 2010, 15:57

Hi Aba,

Thanks again for pointing out this requirement.
We're going to add this to the Strategy Management Pack before we release it.

We're also going to apply this same capability to the Architecture States classes, so that we can track things like the Actor To Role, Application Provider to Business Process instances and how they may change across states.

These will be a quite simple extension to what we have already.

Thanks again

Jonathan
Essential Project Team

User avatar
jonathan.carter
Posts: 946
Joined: 04 Feb 2009, 15:44

21 Dec 2010, 15:58

Just a very short post to let you know that we have now released the Strategy Management Update pack.

Documentation about the pack and how to install it are available on The Essential Project website.

You can download the pack from the Share area.

If you have any questions or problems, please let us know via the forums.

Jonathan
Essential Project Team

Post Reply