Recently, vFunction released its new Assessment Hub which enables enterprises to prioritize app modernization efforts, in order to restore engineering velocity, boost scalability, and gain actionable insights on the impact of technical debt.  To learn more, VMblog reached out to Bob Quillin, Chief Ecosystem Officer for vFunction.

VMblog:  The vFunction Assessment Hub - your latest product - was just announced.  What new capabilities are customers most excited about?

Bob Quillin:  Customers have told us that the most difficult part of application modernization is building an accurate business case for these projects - the need and desire to modernize monoliths is there but architects and business leaders want to create a shared, data-driven plan that is based on actual analysis and not best-guesses. vFunction Assessment Hub is built to meet this need.

vFunction Assessment Hub is a purpose-built modernization assessment solution for decision makers. It uses AI and graph machine learning to analyze and condense data into 3 high-level indicators: technical debt, risk, complexity that allows architects to assess, prioritize and drive immediate action on their modernization projects. The Assessment Hub also seamlessly integrates with the full vFunction Modernization Hub for immediate refactoring and rearhitecting.

Quillin:  A majority of companies today are facing three critical challenges in assessing their application modernization alternatives: (1) how  to quantify the technical debt in their enterprise applications, especially monolithic apps built on enterprise Java and .NET platforms; (2) deciding which apps to refactor, which ones to replace, and which ones to rewrite; and (3) building accurate and persuasive business cases for these application modernization projects. Our customers were stuck choosing either a  manual approach to assessment and modernization, which can be slow, complex, and incredibly costly, or simply avoiding modernization altogether and lifting and shifting the app to the cloud.

Existing assessment tools provide a lot of data but lack any details on the level of effort, complexity, ROI, and risk . In addition, these tools are not actionable in that they leave you with data but no path forward to actually refactor the apps. We wanted to create a solution that solved these challenges and specifically identified what to refactor, the resulting benefits, and a clear path to actually refactoring those applications.

VMblog:  How do you define "technical debt" and why is it important?

Quillin:  Technical debt in applications is defined by the liabilities and risk you carry that compound over time based on all the shortcuts and deviations from best practices that were made year over year in the interest of budget, features- architecture trade offs, resources, and delivery schedules. It is the cost we carry of maintaining aging architectures that drain our ability to innovate - in fact we look at technical debt as the lost opportunity cost for innovation. 

While most development teams and their management are keenly aware that they are carrying increasingly high loads of technical debt in their applications, paying it down becomes harder and harder the longer you wait. Most organizations hit a modernization breaking point over the last 2-3 years as digital transformation projects moved to the forefront as a top priority with COVID, cloud native benefits, green initiatives, and virtual team topologies brought these initiatives to the forefront. The most critical part of technical debt is that it robs IT and the business of their ability to innovate as every dollar you spend on technical debt is a dollar you can't spend on innovation.

VMblog:  What makes vFunction's approach to tackling "technical debt" different?

Quillin:  vFunction calculates technical debt based on the complexity of the monolith and the risk involved with changing the monolith. To understand complexity, we use Graph Machine Learning to  identify the communities or clusters of dependencies, which indicate where domains are evident and hence microservices could be extracted. Complexity is calculated by the degree to which class dependencies are entangled between themselves, reducing the level of modularity of the code.  Risk is measured by the length of dependency chains, which determines how likely a change in one part of the application will affect an unrelated part of the application downstream.  These then roll up into an overall technical debt score and assigned a dollar value based on ML algorithms trained from 100's of monoliths that we've worked with. This allows you to not only compare technical debt across your application estate but also determine the ROI of actually refactoring the application.

vFunction Assessment Hub is also the first assessment solution that directly leads to refactoring, re-architecting, and rewriting applications as it seamlessly integrates with the vFunction Modernization Platform. By creating actionable insights and a clear path to actual refactoring, this  revolutionizes how businesses can manage technical debt on a continuous basis and accelerate their app modernization projects.

Quillin:  Technical debt stifles digital modernization initiatives and hinders the adoption of new technologies like AI, ML and IoT. IT departments can't take advantage of these new technologies without modernizing their applications and infrastructure. Furthermore, app modernization equates to greater scalability and elasticity, which allows organizations to innovate faster and keep up with competitive market pressures. The IT organizations that don't modernize risk becoming a liability to the business as they lose their ability to innovate and deliver increasing value.

Another emerging major challenge for all IT organizations is recruiting and retaining talent and dealing with the new reality of remote team topologies. It has become harder and harder for enterprises to recruit new developers and architects to maintain monolithic applications, while retaining existing teams is equally challenging when more modern development opportunities exist. A monolithic application also typically results in a monolithic team, while cloud native architectures organized around domains, microservices, and common platforms can be more virtual and naturally distributed.