What the Modernization Vector Is
For every application you keep (lifecycle vector Keep, see Lifecycle Vector: Keep or Sunset), iDNA answers two questions per modernization topic: is the application ready for the target platform, and if not, what is the most efficient way to make it ready? The answer is the modernization vector.
iDNA decides it in two steps:
- Ready or not, based on code findings. If iDNA's code analysis finds nothing for the target, or only code that HCL itself ships in its current templates, the application is ready.
- The route, based on relationships. For an application that needs fixes, iDNA does not just count findings. It looks at how the application relates to templates and to similar applications in your environment, the way an experienced Notes developer would triage an estate.
The relationships matter because of how Notes applications work: most applications inherit their design from a master template. Fix the code once in the master, refresh the design, and every application that inherits from it is fixed too. Many estates also grew by copying: someone copied a standard template, changed a few things, and the copy became "our own" template. The modernization vector finds these multipliers, so that one piece of work fixes as many applications as possible.
Two things to keep in mind:
- A finding is not a crash. A finding marks code that needs review for the target, not code that is certain to break. HCL's own mail template, for example, carries Nomad code findings for features that are guarded by design features so that they never run on Nomad.
- Readiness is per topic. The same application can be ready for Notes 64-bit and still need work for Nomad. Always check which topic you are looking at.
The Routes
iDNA checks the routes in this order and assigns the first that applies. The dashboards use two sets of labels: the Modernization Overview shows the route as track: action, Modernization Readiness and Modernization Planning use shorter names.
| Modernization Overview | Readiness and Planning | What it means |
|---|---|---|
| Ready: No Critical Issues Identified | Ready (No Fix Needed) | Nothing to fix. Either the analysis found nothing for the target (Target Compatible As Is), or every finding sits in code of the current HCL template version (Attention Notes Available): HCL's code, not yours, so the findings stay visible as notes. |
| Template: Remediate Master | Fix Master Template | The application inherits from a master template in your environment. Fix the findings once in the master; a design refresh carries the fix to every application that inherits from it. |
| Template: Upgrade Standard | Upgrade Standard Template | The master is an unmodified HCL standard template. Don't edit it: upgrade it to the current HCL version, which already contains the fixes. |
| Template: Rebase Ancestor | Rebase Master Template | The master carries its own name but was copied from an HCL standard template, and the link was lost. Rather than fixing the old copied code, replace the master's design with the current version of that standard template and re-apply your customizations. See Template Lineage. |
| Template: Investigate Inheritance | Similar to Estate Master, Similar to Standard Template | The application inherits from no template, but its design is nearly identical (95 % similar by default) to a master in your environment or to an HCL standard template. Restoring the inheritance may fix it without touching its code. |
| Template: Unify Similar | Unify Similar Apps | The application belongs to a family of similar applications without a shared master. Unify them under one new template, so the findings are fixed once instead of per application. |
| Direct: Remediate Code | Individual Code Fixes | A genuine one-off: no template route applies, and the findings are fixed in the application itself. |
Details of the Template Routes
With [Show Details] on, the template routes show a detail that tells you how far the master's fix goes for this application:
- Fully Covered By Master: the master's fix covers everything; nothing else to watch.
- Unscanned Master Template: iDNA has never scanned the master's design, so its work is unknown. The first step is a scan: have the template placed on a server that iDNA collects designs from.
- Diverging Code Blocks: the application has its own version of code that the master also contains. A design refresh overwrites these changes, so review them before you refresh.
- Surplus Code Blocks: the application has code that the master does not have. Fixing the master alone does not make it fully ready.
Design families of the Unify route are numbered (Design Family #7, ...); the applications with the same number belong together.
Where to Find It
In the iDNA Portal: [App Lifecycle] → [Modernization Overview].
How to Read It
First choose the target in the [Modernization Topic] filter; the dashboard opens with Notes 64-bit (Notes 64bit Readiness). The examples on these pages use Notes 64-bit; Nomad works the same way.
Overview Tab
The Sankey chart reads from left to right: all kept applications, split by lifecycle vector (Keep: Modernize, Keep: Qualify), then into the three tracks Ready, Template and Direct, and finally into the routes. The numbers are applications. Set [Show Details] on the chart to True to see the details of each route:
Click a node to narrow the dashboard to it.
Replica Set List Tab
One row per kept application with its lifecycle vector, modernization vector and a sentence that says in plain words what the route means for this application, for example Remediate master Process Management: 9 of 9 blocks clear with the master. The item counts show how many code blocks need fixing and how many of them the application shares with other applications. Click a title or replica ID to open the application in Application Insights.
Filters
- [Modernization Topic]: the target platform.
- [Title or Replica ID]: narrows the dashboard to applications by title or replica ID.
- [Lifecycle Vector] and [Modernization Vector]: narrow the dashboard to one lifecycle disposition or one route.
- [Only Show Active Since]: limits the dashboard to applications last accessed since a date or within a period, so you can concentrate on what people work with.
- [Show Details]: adds the route details to the Sankey chart.
About Modernization with iDNA Tab
The product's own explanation: what the vector is, how it is calculated, what every label on the dashboard means and where the vector is used in iDNA.
Did you know?
The iDNA Applications Companion explains the route of any application. Ask, for example, "Why is this application on Fix Master Template for Notes 64-bit, and which other applications does fixing that master make ready?" or "Which of our most used applications still need fixes for Nomad?" The Companion reads the same vectors as this dashboard and adds what is behind them. See Setting up the iDNA Applications Companion.
What to Do Next
- For the big picture, how ready the estate is and whether the applications that need fixes are the ones people use: Modernization Readiness: The Estate at a Glance.
- To turn the routes into work: Modernization Planning: Work Sessions. Applications that are ready never appear there.
Related Topics
- [Design] → [Insights]: all code findings by ruleset, and the code behind them.
- [Design] → [Similarity]: the design similarity behind the Investigate and Unify routes.
- Custom Insights: the code analysis rules behind the findings.