Frequently Asked Questions

vFunction is the first AI-driven Architectural Observability Platform for software architects. It continuously observes your application so you can find, fix, manage, and prevent architectural technical debt to improve modularity, scalability, and engineering velocity.

vFunction supports Java applications (1.6+) and .NET applications (4.0+) A wide variety of application servers including Oracle WebLogic, IBM WebSphere, Tomcat, Red Hat JBoss, and more are supported along with a large number of JVMs and JDKs – see the support matrix document.

Architecture Technical Debt (ATD) is technical debt caused by architectural drift, suboptimal architectural decisions, violations of defined target product architecture and established industry architectural best practices, and architectural trade-offs for faster software delivery. While expedient in the short term, the collection of design or implementation constructs sets up a technical context that can make future changes more costly or impossible.

Watch Video

Gartner Quick Answer: How to Manage Architecture Technical Debt, Tigran Egiazarov, Aaron Harrison, Anne Thomas, Howard Dodd, Stefan Van Der Zijden, Thomas Murphy, 22 September 2023.

Krutchen, P., Lago, P., Verdecchia, R. (2021). Building and evaluating a theory of architectural technical debt in software-intensive systems. The Journal of Systems & Software. 176. P.6.

vFunction Architectural Observability Platform combines the capabilities of three previously standalone products: vFunction Assessment Hub, vFunction Modernization Hub, and vFunction Extraction Engine. This enables software architects to fully understand their architecture, identify architectural drift, and find, fix, and prevent technical debt issues. The extraction features of Modernization Hub are available in the Code Copy feature of the platform.

Architectural observability is the ability to analyze an application statically and dynamically to understand its architecture, observe drift, and find and fix architectural technical debt.

Architectural observability enables the understanding of software architecture, helping teams to:

- Define domains with dynamic analysis and AI and understand their modularity
- See class and resource dependencies and cross-domain pollution
- Find high-debt classes
- Improve modularity by adding common libraries
- Identify dead code and dead flows based on production data
- Identify circular JavaARchive (JAR) dependencies
- Understand and improve the cloud suitability of the architecture

Architectural observability uncovers complex class entanglements, zombie dead code, and long dependency chains across resources, classes, database tables, and more.

Watch video: “What is Architectural Observability”

Software architects lack the tools and visibility to continuously monitor, find, and fix application architectural drift issues from release to release, sprint to sprint. While the following tools help identify issues in performance, code, and component interdependencies, they do not provide visibility into business logic architecture:

- Application performance monitoring (APM) and other DevOps observability tools enable performance monitoring and fault or outage early detection.
- Code quality tools address source code quality, bugs and code smells, usually through static analysis. Static application security testing (SAST) and Dynamic Application Security Testing (DAST) solutions provide static & dynamic security & vulnerability analysis.
- Software Composition Analysis (SCA) tools identify open-source components and map services, components, interdependencies, and 3rd party vulnerabilities and aging frameworks.

Addressing only performance issues, code smells, or faulty service connections during fixed periods in delivery cycles may give leaders a false sense of progress and fails to address technical debt accumulating in the architecture.

Architectural observability provides architects and engineering teams visibility into their application’s business logic layer to address higher impact and harder to solve issues, such as overall product quality, feature delivery lead time, developer productivity, and scalability.

The version of IIS does not make much of a difference as long as it runs the correct .NET version. Thus far, vFunction has been tested on IIS 10. For complete Java and .NET, see the vFunction support matrix.

Any application running on the supported versions of the .NET runtime. This includes (but not limited to) batch processes, ASP.NET applications, Windows Services.

No. All analysis is conducted independently by the vFunction Architectural Observability Platform based on dynamic code analysis and static analysis of the bytecode and requires no source code access. Suppose you need to extract a domain using the vFunction Code Copy feature. In that case, vFunction generates a “Service Spec,” which lists all classes, configuration files, and dependent JARs that compose the service. It then, and only then, requires access to the source code to copy the relevant sources and configuration files with their package structure and tests (if available). So, at this point, access to the code repository and build systems is required. vFunction then creates a pom.xml for the service. From there, you can compile and deploy that new service on AWS, Azure, OpenShift, Google Cloud, or any other cloud platform you choose.

vFunction analyzes and modernizes the application layer business logic within the Java virtual machine (JVM) and common language runtime (CLR) for .NET apps. However, it also examines transactions, stored procedures, connections, and database table access and considers these to be constraints that impact service separation. vFunction relies on analyzing traffic to/from the databases via Java database connectivity (JDBC), so it sees, for instance, calls to stored procedures. It also conducts static analysis of the database stored procedures (currently for Oracle databases) to map their dependencies and presents those as well.

This way, vFunction can help you identify domains with high exclusivity to improve modularity and eventual microservice extraction, if desired. Additionally, vFunction helps identify portions of business logic in the database stored procedures that you may want to extract and bring into the business logic layer, into specific domains.

vFunction learns your application and creates a large meta-model representing class and resource interdependencies, enabling you to analyze its architecture. It allows you to impose your architectural view (current or future) on it to understand its health – how modular it is, the interdependencies (e.g. class, db), sources of technical debt, dead code, etc., as well as measure drift against that architecture.

The spheres represent domains and serve as vFunction’s suggested starting point to create your desired architecture. Domains are identified based on mathematical optimization of class and resource exclusivity across the application. If your application is well-architected (i.e., highly modular) the spheres will likely resemble your application’s logical domains. However, keep in mind that a domain is a subjective business representation of an application functionality. Therefore, you will need to impose your architectural view of the domains to let vFunction analyze it and enable you to understand the health of that architecture – its modularity, interdependencies (e.g. class, db), sources of technical debt, dead code, etc.

Yes. In cases where there are no existing endpoints for the service, vFunction will automatically create these endpoints as RESTful endpoints using Spring REST or Java API for RESTful Web Services(JAX-RS). You just need to add a call to the service from the monolith and re-run the analysis.

Download the related ebook: Application Modernization Patterns and Anti-Patterns.

Service exclusivity within the vFunction platform means the degree to which classes, resources, methods, database calls, and variables are exclusive to that service. It is basically the degree of modularity of that domain. If you have 100% class exclusivity, those classes exist only within that service domain. This lack of tight coupling between services makes separating and extracting that service comparatively easier.

Yes. Code Copy extracts the domain code at the user’s request. The higher the modularity the less code duplication will be needed. For example, accessing a read-only database table from two different domains may impact the exclusivity of those domains. Yet a read-only table shouldn’t prevent extraction of those domains. In some cases, a manual intervention may be required, for example, if you need to break up a database transaction. These cases require a developer to break up the dependency, or an architect can make an informed decision to alter the architecture and circumvent the dependence.

Non-exclusive classes left at the analysis’s end are effectively your refactoring to-do (TODO) list. They serve more than a single service, but are not a utility used by many. In this case, the recommendation is to start by duplicating the class between the services (which vFunction does automatically) and then extracting and refactoring them later.

Yes. vFunction tracks access to database tables, JDBC transactions, and Java Transaction API (JTA) and Extended Architecture (XA) transactions related to relational databases.

It depends on which target platform is required. vFunction mitigates risk and unknown variables by keeping the same Java container for the microservice as a first step (e.g., from WebSphere to WebSphere). Since vFunction extracts a lightweight service in terms of the required context, it enables you to migrate to a lighter container such as Apache Tomcat, Spring Boot, Quarkus, and others. If the starting platform is Spring, vFunction can automatically generate microservices configured for Spring Boot.

Installing vFunction is simple, depending on your network configuration and security constraints. There has to be a connection between the JVM agent and the vFunction server (all installed locally). A vFunction engineer can remotely support you during the installation.

Once installed, run the application in production or perform automatic testing in a QA or staging environment to cover as many system flows as possible. If no automatic testing is available, perform manual testing. This can take a few hours to one or two days until you meet sufficient coverage to achieve the starting point. Subsequently, we recommend installing vFunction in production and tying the observability intervals to your release cycles.

The vFunction value proposition to continuously monitor and manage the application remains consistent, regardless of the type of project.

If you are tasked with rewriting a complex Java/.Net application with high ATD that resembles a “big ball of mud,” the following statements may resonate:

- The application is significant from an operational perspective, and changing it is risky and expensive.
- There is a decision to create a new generation of this application, but the team is reluctant to “deal with” the existing code.
- The team is not developing the app daily and has some knowledge gaps.
- The team has some understanding of the domains involved and even has a domain model, either “mentally” or explicitly after doing some Domain Driven Design (DDD) analysis.

The insights provided into the software architecture of an existing application are crucial regardless of whether improving the architecture is done as part of the same codebase or a new one. Moreover, vFunction can provide insights on a new application from day one to ensure it is designed and implemented according to the desired design, and monitor throughout its entire life cycle.

Yes!. Like other observability tools, the value of vFunction is closely related to its ability to understand the real architecture of an application. That requires learning the application in production. All customers deploy vFunction in production and leave their agents to collect data for hours to days, with overheads similar to an APM performance monitoring solution (1-2%). The vFunction dashboard and UI allow the architect to continuously monitor and manage the entire application estate, create a modernization pipeline, and set observability triggers tied to the CI/CD or to some preconfigured schedule.

In this case, you can install the vFunction JVM agent on multiple JVMs, run serial measurements on them, and then merge the results to get a unified view of the system on the vFunction platform.

vFunction tracks information in a fundamental way (native JVM agent, memory interactions, etc.) and, therefore, works for any Java application. See support matrix.

Install vFunction locally behind your organization’s firewall or cloud provider’s security – whether on-premises or on your secure cloud tenancy, so no data leaves your secure environment.

Contact info@vfunction.com for our security whitepaper.

Contact us at info@vfunction.com and we will be happy to provide you access to our installation guides.