Modeling the impact of a project

Post Reply
Posts: 26
Joined: 01 Jun 2018, 14:16


I am wondering how to model and visualize the following situation.
Assume the organization has a project called Project Ducky.

Project Ducky will have a lifecycle with one if its attributes (which I think you call slots) defining the state in its life cycle.

Project Ducky will impact several elements in the Business, Information, Application, and Technology layers, either creating, modifying, or deleting one or more component in those layers.

How do I...

1) model and visualize the the many alternatives of scope that Project Ducky could have before its approval, contrasted to the different benefits that it would offer in each?

2) model and visualize the before, during, and after impact that executing a possible scope of Project Ducky would have on the elements in each of the 4 layers?

3) visualize the "deltas", in other words, the differences between the the before and after?

Many thanks!

Posts: 71
Joined: 01 Jul 2017, 07:05

Hi Alex,

Although we do support the ability to map Projects to the elements that they impact in the ways that you describe (via Strategic Plans), we do not currently support comparative scenario analysis for Projects at the moment. However, we are considering enhancing our "roadmap-enablement" capabilities such that, within a given view, users will be able to select/deselect Projects, or specific planned architecture changes to see how the given view would change. The prioritisation and scheduling of this potential enhancement will depend on community demand.


Posts: 26
Joined: 01 Jun 2018, 14:16

Thank you, Jason.

I think that when time comes, it would be useful to consider a few aspects and incorporate them into the design.

a) Projects may have one or more candidate Solution Domains, of which one will be chosen (ideally before the project is approved) as the scope of the project.
b) Each Solution Domain typically requires Creating, Updating, or Deleting one or more components of the EA (from business capabilities down to technology components.
c) Being able to visualize the deltas between current and candidates would be a great functionality, particularly to understand implementation risks.
d) Candidate Solution Domains are "theoretical" (ignoring for I'll leave the discussion of whether they are logical or conceptual for another time) but at one point, one of the candidates becomes deployed by the project, changing the reality on the ground, and thus the EA. It would be great to have a function that "promotes" a Solution Architecture from Target to Deployed, so the repository is kept up to date with the changes.

Essential's Metamodel, albeit rather inclusive, does not seem to have coverage for the above. Without all this, Essential is somehow constrained to a static view of the EA, and imho, there's a lot of value in exposing and managing the dynamic aspects created by Projects.

Let me know if you want to discuss further.

Many thanks!!!


PS: I am curious about the prioritization process that you mentioned in your note. How does it work? Who is consulted?
Post Reply