vFunction
Architectural Observability Manager
Find and Fix Technical Debt
vFunction Architectural Observability Manager analyzes application architecture, identifies domains, pinpoints sources of cross domain pollution to manage technical debt and drive continuous modernization.
R&D Lead, Trend Micro
Manage Technical Debt and Analyze Architectures
Analyze
Application Architecture
Pinpoint
Architecture Issues
Observe
Architectural Drift
Analyze and Understand Your Architecture
Application, enterprise, and chief architects lack the observability, visibility, and tooling to assess, understand, track, and manage architectural technical debt in their applications today and as it grows over time. vFunction Architectural Observability Manager allows architects to shift left into Agile and DevOps lifecycles from an architectural perspective to manage, monitor, and fix application architecture drift issues on an iterative, continuous basis.
- Identify the sources of technical debt and address them immediately. Automatically discover and then refine domains, identifying cross domain pollution, high debt classes, and cross-domain database relationships to add to modernization to-do list.
- Establish a baseline, monitor, and alert on architectural drift issues such as new service detected, new common classes found, service exclusivity change, new dead code found, and new high debt classes identified.
- Get notified of architectural anomalies immediately through various alert systems including Slack, email, and vFunction Notifications Center.
- Once an architectural drift issue is pinpointed, address them directly with your development team or use the vFunction Refactoring Engine Module to resolve the issue
According to a Gartner® report
“By 2026, 80% of technical debt will be architectural technical debt.”
Source: Gartner, Measure and Monitor Technical Debt With 5 Types of Tools, Tigran Egiazarov, Thomas Murphy, 27 February 2023.
GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved
What is Architectural Observability?
Architectural Observability is a software engineering best practice that provides architects with detailed visibility and context into an existing application’s architecture to profile and baseline how an application is architected, identifying domains and cross domain pollution, collecting observable dynamic operational and static data to proactively fix issues, set baselines, detect drift, identify significant architectural events, and resolve architectural anomalies.
vFunction Architectural Observability Manager is a new product that introduces a breakthrough set of features to continuously find and fix architectural technical debt issues. This enables architects to fully understand their application architecture, catch and fix drift and debt issues early and often, and define technical debt metrics that the software architecture must meet.
Architectural observability lets you:
- Manage and remediate architectural technical debt
- Identify & visualize domains with dynamic analysis and AI
- See class & resource dependencies and cross-domain pollution
- Find & fix high-debt classes
- Improve modularity by adding common libraries
- Pinpoint dead code and dead flows based on production data
- Establish a baseline architecture
- Observe & detect architectural drift
- Refactor monoliths into microservices
(with the Refactoring Engine Module)
Architect Toolbox
Architectural Observability Manager: How Does It Work?
vFunction Architectural Observability Manager first analyzes Java and .NET applications and services to baseline the architecture through AI-enabled dynamic and static analysis. This analysis can run in test, staging, and/or production environments.
The platform calculates resource interdependencies and domain exclusivity (including class, transactions, files, beans, database tables, synchronization objects, sockets, and stored procedures relationships). vFunction identifies and graphs domains visually through call tree, class, spring bean, and jar dependencies views.
The architect can then set the desired architecture state as the basis for drift observation and monitor for critical architectural events and set triggers or schedules to scan and detect architectural events after each sprint, CI/CD, or test cycle, including:
- New Dead Code Found: vFunction will detect new dead code in applications indicating that new, unnecessary code was added to the application or the baseline architecture drifted and existing class or resource dependencies were changed.
- Database Table Exclusivity Events: Identifies database tables that were used exclusively from a specific domain and are now used by more than one domain.
- New Domain Introduced: Based on the observed baseline service topology, when a new domain has been detected vFunction will identify and alert that a new domain, service, 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 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 are notified of changes in the architecture through Slack, email, and vFunction Notifications Center. Through vFunction Architectural Observability Manager, architects will be able to configure schedules for learning, and analysis and the option to configure baseline measurements.
Trusted By
Related Resources
