A key task for an Enterprise Architect is to have a clear understanding of where the company is at (as-is), where they are going (to-be), and how to get there (transition architecture).
To meet this requirement, there are a few things you need to implement in the form of fields and potentially tags.
There are two real challenges that you would typically want to address in this type of use case depending on the phase in the process:
White-boarding: Looking at all potential architecture scenarios and compare.
Transitional Analysis: Picking one target architecture and see the transition over time and analyze the impact in the form of cost, complexity, etc.
The process of moving from As-Is to To-Be is not linear and depending on your progress you will likely need to jump back and forth between “whiteboard” scenario modeling and implementation. The following best practice is a generalized recommendation based on the average starting use case.
Building in complexity and granularity can be necessary for certain use cases and if you would like additional or advanced guidance, please contact your CSM or in-app chat for continued support.
Questions to Ask Yourself:
Where are we at a given date (past, present, future)?
What are the associated costs and dependencies at a given date?
What components and references are within the scope of a scenario?
What is the current life cycle of the components included in the given scope?
What is the cost of the components included in the given scope?
Data required:
The information below is included in many of the out-of-the-box templates but you have the ability to reuse the fields on existing data or build your model from scratch.
For this example, we will use our standard naming convention so that filtering and examples are consistent. You are able to use your own and simply replace the guide with your own custom-named fields.
Component Fields:
Lifecycle Dates (Date Range Field)
Lifecycle (List Field)
Cost (Number Field)
Tags:
Tag per Scenario
Example Model for Application Portfolio
Example with Application Portfolio Template:
Using the out-of-box template will include all necessary fields and components to do as-is / to-be modeling of your application portfolio.
Component:
Flat Flexible Hierarchy
Fields:
Lifecycle Dates: Date Range Field on Application Components
Total Direct Cost: Number Field on Application Components
Tags:
You need to create tags according to your needs. Examples often include scenario tags like scenario1, scenario2, etc.
Answering Some Key Questions
Where are we at a given date (past, present, future)?
To understand your architecture at a given date, you will simply need to apply a filter for that date and choose the view that you prefer.
Relative filters can be very valuable as saved perspectives as they are dynamic according to today’s date.
Example:
Looking at our portfolio 12 months ago:
Looking at our portfolio as it is today.
Looking at our portfolio 1 year from now.
2. What are the associated costs and dependencies at a given date?
After applying the appropriate filter set (see question 1), you will be able to look at your portfolio in any view to see its dependencies and key data.
Looking at the application portfolio in one year's time in the Block Diagram to see applications and their integrations.
The aggregating cost can best be done through the dashboard. In this case, the easiest way to do a cost overview of just your applications at a given date is to create a dashboard chart based on an advanced search.
For Today’s Cost:
Go to the Advanced Search and create a simple search following the same process as in Question 1 but add an additional filter based on the application workspace to ensure you are only looking at your applications, not everything else that is live.
Next, create a report from this search so that you can visualize the Total Direct Cost in a dashboard. You can do so by clicking on the "Create report" button at the top right corner of the screen.
To visualize your data in a dashboard chart:
Head over to Analytics > Dashboard Overview > Create new
Give your dashboard a name and a description (optional)
Click "Add new chart"
Select your report from the "Select report or survey" dropdown
Select the "Total Direct Cost" field from the "Select field" dropdown
Creating charts to visualize current cost and target costs will create an application cost dashboard.
3. What components and references are within the scope of a scenario?
For this question, we are making the assumption that you are looking at multiple scenarios. You may define scope by relationships to other components, by field values like cost, or by tags. For this case, we will follow the idea of tagging scenarios.
In the example, we have duplicate CRM systems and data flows from our webshop due to a merger of two portfolios. We have documented both in the same workspace and tagged each flow to highlight the two options we have with the objective of choosing one. Ideally, we would also want to combine this with other fields to continue our analysis.
Scenario 1: Filter from the perspective menu
Output in Block Diagram:
Scenario 2: Filter is the same process, but the output is adjusted:
4. What is the current life cycle of the components included in the given scope?
Following Question 3, we can then look at the life cycles for these components by looking at a filtered table view or but combining grouping or conditional formatting.
Example of using grouping by field:
5. What is the current cost of the components included in the given scope?
You can follow the process in Question 3 and 4 to come to visual and table like representations, calculating and aggregating larger data sets are better suited to a dashboard.
In this case, we will follow the same process as Question 2 however, instead of looking at the time, we are highlighting tagged components.
After saving the search as a report, we can then go back to the dashboards to create charts to sum up the cost, complexity, etc. so that you can present your Scenarios at more of a KPI comparison than just visual diagrams. Keep in mind that you can also combine the views and the dashboards in the living presentations.
Increasing Granularity
If you need greater granularity, for example looking at multiple integrations, deployment options, or product portfolio support, you may need to add some granularity to the data to improve your insight and analysis.
As an example, if we look at moving our applications to the cloud, we may have moments in time in which we have multiple redundant infrastructure supporting applications as you are not able to turn off on-prem before the cloud is fully supporting the application. To appropriately capture this, we need to add fields to references.
Cloud Migration Example
Components:
Applications
On-Premise Databases
Cloud Database
On-Premise Servers
Cloud Servers.
References:
Stores data
Runs on
Fields:
Date Range (References and Components)
Looking at an Example of moving our CRM from on-prem to the cloud:
On each of the references and components, we have a start and end date, allowing us to then look at the deployment at any given point. To achieve a point in time snapshots, we need to simply follow the steps above to add the appropriate filters in the perspectives menu.
Today:
Notice we are only running on-premise even though in the total model we have multiple deployments modeled in different points in time. We recommend saving the “Today” perspective and applying it as a default set perspective so that users jumping into this workspace will, by default, only see the as-is and not the historical or future data.
In Mid-December (Mid Delivery in the Future)
Notice we are running the app on-prem, but we are duplicating data on two databases, one on-prem and one in the cloud.
End of December (Target Delivery Date)
Notice that the App is now both running in the cloud and storing the data only in the cloud. There are no associated on-prem infrastructure components.
We can combine this modeling with cost fields as in the intro case and create dashboards using gremlin queries to calculate the infrastructure costs based on dependencies and their associated dates. In addition, we can create strategies and transitional architecture plans highlighting why it is more important to remove all dependencies on one piece of infrastructure instead of a few across multiple as you are not able to “turn off” the components until all dependencies are removed.
Gremlin Queries for this case:
Today (Relative Date):
today= new Date().format('YYYY-MM-dd')g.V().hasLabel("Application").has("name", "Microsoft Dynamics CRM").outE().has("lifecycle_dates_start_date", lt(today)).has("lifecycle_dates_end_date", gt(today)).inV().values("operating_cost").sum()Mid-November 2019:
date="2019-11-15T22:00:00.000Z"g.V().hasLabel("Application").has("name", "Microsoft Dynamics CRM").outE().has("lifecycle_dates_start_date", lt(date)).has("lifecycle_dates_end_date", gt(date)).inV().values("operating_cost").sum()Target (End of 2019):
date="2019-12-31T22:00:00.000Z"g.V().hasLabel("Application").has("name", "Microsoft Dynamics CRM").outE().has("lifecycle_dates_start_date", lt(date)).has("lifecycle_dates_end_date", gt(date)).inV().values("operating_cost").sum()If you're still left with questions, browse our Knowledge Base or just reach out to us! You can start a chat from our website or by using the in-app chat. 💬