Continuous Modernization Cycle Overview
Overview
The process of modernizing an Application is a continuous cycle: analyze, adjust the baseline as needed, observe, inform and fix.
Analyze
vFunction uses AI driven algorithms to analyze the application and to enable you to understand the architecture, see all the Domains in the Application, and see the connections and Dependencies between the Domains.
Baseline
vFunction enables the software architect to further analyze the Application, to set a desired reference architecture as a baseline.
Observe Drift
The platform continuously observes the Application by conducting Scheduled Learning on the Application. The cadence of the Scheduled Learning is configurable and will be adjusted to the frequency of the organization’s sprints cadence. It is best practice to align the Scheduled Learning to New Features releases.
Inform
vFunction will inform the architect of any changes by comparing the latest Measurement with the Baseline Measurement. That comparison will result in TODOs being created. Those TODOs will alert to the backlog of technical debt that existed in the original monolith, as well as new technical debt issues created by the latest build. Examples for new architectural drift alerts include:
- Domain Changes: Identify and visualize business logic domains, indicate change in domain topology compared to the observed baseline
- Common Library: Monitor when new common classes are introduced or existing ones are removed. Common classes are those used across multiple domains or functions. The misuse or overuse of common classes can lead to tight coupling and decreased modularity
- Class and Resource Exclusivity: Monitor when dynamic and static class exclusivity changes, i.e., when a class is used across multiple domains or when a resource (database table, beans, sync objects, transactions) previously used by a single domain which are now accessed by more than one
- Dead Code: Monitor when unnecessary code surfaces in the application
- High Debt Classes: Monitor when a new “high-debt” class is found pinpointing a critical software component to be refactored
- Architectural Complexity: Monitor the architectural compolexity score of the application which is indicative to the amount of effort required to make architectural changes to the application
Fix
The TODOs are shared with the application development team as part of their development tasks via the vFunction Azure Devops or via the vFunction JIRA integrations. Their corresponding fixes and feature implementations are observed by the platform as part of the next Scheduled Learning. The vFunction platform enables the software architect to prioritize the TODOs in line with domain priority
Analyze Again
After running Scheduled Learning on a new build that includes new features and TODOs remediation fixes, the vFunction platform runs full analysis and compares the results to the baseline. Old TODOs that were fixed are marked as done and new architectural drift alerts will create new TODOs.