In the two previous installments, we discussed planning and roadmapping in the context of enterprise architecture, and how you can use the concepts of the ArchiMate language to model your roadmaps. We showed how you can model the evolution of your enterprise at coarse-grained level, using concepts such as ArchiMate’s ‘plateau’. In this installment, we will discuss more fine-grained modeling of change in BiZZdesign Enterprise Studio. Specifically, we will show you how you can model the lifecycles of individual elements of your architecture. Moreover, our platform supports analysis based on life cycles and the dependencies between elements, for instance, to find conflicts in your transition plans.
In Enterprise Studio, you can add timed properties to elements in you model. As the name says, the value of such a property may change over time. Think for example of properties that represent the version of an application component or the maturity level of a capability. Timed properties can be used for all kinds of purposes in BiZZdesign Enterprise Studio, but here we use them for lifecycle modeling. Enterprise Studio comes with several built-in lifecycles for different types of elements, such as applications and projects, to name a couple; next to these, you can also define your own lifecycles. Below, you can see a lifecycle view of a set of applications, all individual lifecycles being plotted on a timeline.
In this view, you may also notice the red bars below two applications. These denote lifecycle conflicts, e.g. they may be exchanging data or using each other’s functionality. Clicking on the red bar will highlight the ‘offending’ application.
In the ArchiMate view below you can see exactly how the applications in this example are related to each other in the architecture. We have highlighted the relationships that cause the lifecycle conflicts shown above: ‘Ramadera’ serves ‘Crystal Ball’, which in turn serves ‘Backbase CXP’. So, if Ramadera goes offline because it is in maintenance, Crystal Ball cannot do its job. How different relationships in your architecture affect the dependencies of lifecycle stages is fully configurable. This may also include ‘cross-layer’ dependencies, for example business processes that use application services and components; applications that use certain technology, like operating systems, interfaces, or database platforms; or projects that realize various parts of the architecture.
Partial application landscape highlighting dependencies that cause lifecycle conflicts
More advanced lifecycle analysis
You can also run this analysis for more complex cases, such as relating the stages of a project to the lifecycle of the application it builds, or determining what happens if an agile team decides to postpone a feature to the next sprint. This can help you assess which business-relevant functionality will have to be delayed and which customers might be affected. Based on that information, you can then decide on priorities in development.
The figure below shows a more elaborate example. At the top, we see how a set of work packages depend on each other’s outputs. In this scenario, these work packages reflect different projects, but they could also be used to model, for instance, sprints in an agile context. The warning sign in the picture and the table on the left show that if project P428 finishes too late a conflict occurs since P473 needs the former’s results. Moreover, there are potential issues with an overlap in scope, as shown in the right-hand table: Projects P431 and P473 both work on the application New Relic Insights. If they also overlap in time, they may step on each other’s toes.
Project planning and dependencies.
The information on the scope of projects is in turn taken from another part of the model. The view below shows the high-level roadmap of this application rationalization program. The pink boxes represent the same projects as above, moving data from old to new applications. If a project touches an application, that application is in scope for that project.
This roadmap uses ArchiMate’s ‘plateau’ concept to model the main stages in the transition of the application landscape, in a way similar to what we showed in our earlier blog post. Thus, you can connect your high-level, coarse-grained planning to detailed information on the lifecycles of individual applications, projects, or other elements.