vFunction today launched the Continuous Modernization Manager (CMM), a new product for architects and developers to continuously monitor, detect, and pinpoint application architecture drift issues before they cause technical debt meltdowns. vFunction CMM enables software architects to shift left and prevent technical debt disasters by baselining, observing, pinpointing, and alerting on application architecture drift issues before they result in business catastrophes like we’ve seen with Southwest Airlines, Twitter, FAA, and countless, unnamed others. Read the full press release.
Architectural Technical Debt
Architectural technical debt accumulates unobserved in the shadows until disaster strikes – literally a silent killer for business. Application architects, up to this point, have lacked the architectural observability, visibility, tooling to understand, track, and manage architectural technical debt. This has resulted in not only technical problems such as architectural drift and erosion but numerous large and small disasters.
So what is architectural technical debt? It’s the accumulation of architectural components, decisions, and drift that results in “a big ball of mud” that architects are unable to see or track – making it essentially an opaque “black box.” Architectural technical debt consists of class entanglements, deep dependencies, dead-code, long dependency chains, dense topologies, and lack of common code libraries. Architectural debt is NOT source code quality or cyclomatic complexity, although these are critical technical debt elements to track and manage.
Architectural technical debt is hard to find and harder to fix. It affects product quality, feature delivery lead time, testing times, and very importantly it is the primary predictor of modernization complexity – how hard will it be to modernize (refactor or re-architect) this application. Peter Drucker established one of the most basic business principles when he stated, “You can’t improve what you can’t measure.” He also emphasized that you can’t stop at measurement, you need to also manage it. Architectural debt has been hard to measure thus hard to find and fix. Your need to observe the architecture, baseline, and detect architectural drift and then apply intelligent modernization tooling & techniques to manage the architectural anomalies.
“One of the most critical risks facing organizations today is architectural technical debt,” said Jason Bloomberg, Managing Partner of analyst firm Intellyx. “The best way to keep such debt from building up over time is to adopt Continuous Modernization as an essential best practice. By measuring and managing architectural technical debt, software engineering teams can catch architectural drift early and target modernization efforts more precisely and efficiently.”
Architectural Observability
Observable architecture is the goal. Today, architects lack the observability, visibility, tooling to understand, track, and manage architectural technical debt. They are looking to answer questions like:
- What is the actual architecture of my monolith?
- How is it behaving in production?
- What’s my architectural baseline?
- Has the app architecture drifted from the norm?
- Do I have a major architecture issue I need to fix now?
- Where is it and how do I fix it?
If I can’t identify my core services, their key dependencies, my common classes, or my highest debt classes, and the relevant service exclusivity, I’m running blind to the software development lifecycle from an architectural perspective.
Shift Left for Architects
vFunction Continuous Modernization Manager lights up the application black boxes and ball of mud apps – making the opaque transparent – so architects can shift left into the ongoing software development lifecycle from an architectural perspective. This allows them to manage, monitor, and fix application architecture anomalies on an iterative, continuous basis before they blow up into bigger issues. CMM observes Java and .NET applications and services to first baseline the architecture, set baselines, and monitor for architectural drift and erosion to detect critical architectural anomalies including:
- New Dead Code Found: detect emerging dead code in applications indicating that unnecessary code has surfaced in the application or the baseline architecture drifted and existing class or resource dependencies were changed.
- New Service Introduced: Based on the observed baseline service topology, when a new service has been detected vFunction will identify and alert that a new domain or major architectural event has occurred.
- New Common Classes Found: Building a stable, shared common library is a critical modernization best practice to reduce duplicate code and dependencies. Newly identified common classes can be added to a common library to prevent further technical debt from building up.
- Service Exclusivity Dropped: vFunction measures and baselines service exclusivity to determine the the percentage of independent classes and resources of a service, alerting when new dependencies are introduced that expand architectural technical debt.
- New High-Debt Classes Identified: vFunction identifies the highest technical debt classes that are the highest contributors to application complexity. A “high-debt” class score is determined by its dependents, dependencies, and size and pinpoints a critical software component that should be refactored or re-architected.
Users will be notified of changes in the architecture through Slack, email, and vFunction Notifications Center. Through vFunction Continuous Modernization Manager, architects will be able to configure schedules for learning, analysis and the option to configure baseline measurements.
New in Modernization Hub and Assessment Hub
In addition, the newest release of vFunction Modernization Hub has added advanced collaboration capabilities to enable modernization architects and teams to more easily work together. New analytics also pinpoint the highest technical debt classes to focus the refactoring priorities. vFunction Assessment Hub has added a new Multi-Application Assessment Dashboard to analyze technical debt across a broad application portfolio.
Newly announced, vFunction Assessment Hub now includes a Multi-Application Assessment Dashboard that tracks and compares different parameters for 100’s of applications. Multiple applications can be analyzed at a glance for technical debt, aging frameworks, complexity, state, and additional architectural factors.
Also new in vFunction Modernization Hub 3.0 are a set of collaboration features for modernization teams to more effectively collaborate to avoid conflicts and improve clarity, working in parallel on different measurements, and then later merging them into one measurement. A user can protect services they wish to keep unmodified, preventing conflicts when multiple teams are working on the same measurement, especially when adding or removing classes to common areas.
Modernization is Not Linear: It’s a Continuous Best Practice
The most important takeaway from this announcement is that modernization is not a one-and-done project. It needs to be an iterative, cyclical best practice process that requires teams to adopt and commit to a culture of continuous measurement and improvement – led by architects shifting-left into their development processes and taking firm ownership of their actual architectures. Create observable architecture through architectural observability and tooling that catches architectural drift before it leads to greater issues. We’ve all seen what can happen if you let the silent killer of architectural technical debt continue to lurk in the shadows. Shine a light on it, find it, fix it, and prevent future monoliths from ever forming again.
