Dr. Bill Curtis - Dr. Bill Curtis, Senior Vice President and Chief Scientist with CAST - lays out the “Technical Debt Management Cycle”, a 7-step process for analyzing and measuring Technical Debt so you can relate executive business priorities to strategic quality priorities for reducing business risk and IT cost. It includes a formula to benchmark your Technical Debt against industry data, or adjust the parameters to best fit your organization’s own maintenance and structural quality objectives, experiences, and costs.
What is Technical Debt? It doesn't have to be negative, but it does have to be carefully managed. Here is a quick run-down of best practice to approaching Technical Debt management.
Presentation given by Fadi Stephan from Kaizenko at AgileDC2018 on 10/15/2018 in Washington DC. Also see blog series on Managing Technical Debt at https://www.kaizenko.com/managing-technical-debt/
Is your team constantly missing delivery dates? Is the velocity decreasing from sprint to sprint while the development costs are rising? Are customers complaining about the increasing number of bugs and the long time it takes to add new features? These are all signs that you are mired in technical debt and probably on your way to bankruptcy or a complete system rewrite. Technical debt is inevitable, whether intentional or unintentional. However, not managing technical debt can paralyze your organization. Fadi Stephan expands on the technical debt metaphor and introduces a technical debt management plan that enables executives and teams to make prudent decisions on code quality and technical debt. Come learn how to measure the quality of your code base and determine the amount of your debt.
Whether we know it or not, every time we deliver a feature we also deliver technical debt. This debt remains largely invisible, it isn't tracked, it isn't visible on our information radiators and we very seldom tell our clients about it. The closest we come to acknowledging technical debt is bugs, mainly because our users tell us there is a problem, so we can't ignore it. Technical debt shouldn't be invisible, it's as real as the features we deliver and we should start treating it so. In this talk I propose a technical debt model which can be used when identifying technical debt, furthermore I propose a low friction technique for integrating technical debt into your current SDLC process.
What is Technical Debt? It doesn't have to be negative, but it does have to be carefully managed. Here is a quick run-down of best practice to approaching Technical Debt management.
Presentation given by Fadi Stephan from Kaizenko at AgileDC2018 on 10/15/2018 in Washington DC. Also see blog series on Managing Technical Debt at https://www.kaizenko.com/managing-technical-debt/
Is your team constantly missing delivery dates? Is the velocity decreasing from sprint to sprint while the development costs are rising? Are customers complaining about the increasing number of bugs and the long time it takes to add new features? These are all signs that you are mired in technical debt and probably on your way to bankruptcy or a complete system rewrite. Technical debt is inevitable, whether intentional or unintentional. However, not managing technical debt can paralyze your organization. Fadi Stephan expands on the technical debt metaphor and introduces a technical debt management plan that enables executives and teams to make prudent decisions on code quality and technical debt. Come learn how to measure the quality of your code base and determine the amount of your debt.
Whether we know it or not, every time we deliver a feature we also deliver technical debt. This debt remains largely invisible, it isn't tracked, it isn't visible on our information radiators and we very seldom tell our clients about it. The closest we come to acknowledging technical debt is bugs, mainly because our users tell us there is a problem, so we can't ignore it. Technical debt shouldn't be invisible, it's as real as the features we deliver and we should start treating it so. In this talk I propose a technical debt model which can be used when identifying technical debt, furthermore I propose a low friction technique for integrating technical debt into your current SDLC process.
Copy and paste to access the full recording: http://www.castsoftware.com/news-events/event/gartner-technical-debt?gad=ss
-------------------------------------------------------
In this webinar David Norton of Gartner Research discusses recent findings on Technical Debt that estimates industry IT debt is at $500 billion—and on target to reach $1 trillion by 2015. He also talks about the importance of Software Analysis & Measurement to manage Technical Debt, how to measure debt continuously to control TCO of the application lifecycle and include debt measurement in project management and prioritization.
Presented by David Croley at ALN Houston.
Learn about technical debt (the good and bad kind), its impact on your ability to ship working product via game format.
echnical debt is a popular metaphor used in most delivery teams. It’s a powerful way to describe complicated problems, convey the importance of building things right, and describes the cumulative effect of taking shortcuts. As engineers we all appreciate why preventing and paying down technical debt is important, but its often not something ‘the business’ really appreciates or seemingly cares about.
More and more we see the backlog sliced in 2 different sections, the first being the business value adding work, the second being the technical debt work. This is also accompanied with some kind of rule that says ‘we can spend 10% of our time on technical debt’. It always feels like technical debt is just ‘something the devs go on about’, and not something that adds business value.
This talk is to try to convince you to think about technical debt differently and eliminate it from your backlogs. To do this we’ll have to explore what ends up in the technical debt bucket, why its such a problem and what we can do about it. We’ll also talk about risk, the part it has to play and how it should be your best friend when managing complicated problem domains and systems. My goal is make risk exciting, useful and fundamental in what we do….which may sound crazy, but just stick with me!
Technical debt shouldn’t be something just the dev’s care about, its something everyone should care about.
Technical debt in a software system not only impacts the productivity of the team but also compromises the external product quality. Technical debt needs to be managed pragmatically to ensure discipline, value, and quality.
Managing the the Technical Debt lifecycle. In this presentation we explore the evolution of the metaphor, the value it brings to organizations and challenges to successful adoption.
The full audio and video can be viewed at http://blog.acrowire.com/td-webinar.
A collection of slides that illustrate how to go about effectively managing technical debt on a software project. I used these slides during a demonstration at an internal demonstration on technical debt at Fuzz Productions.
The Technical Debt Trap - Michael "Doc" NortonLeanDog
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
What do we do about it?
Technical debt is something that most project teams or independent developers have to deal with – we take shortcuts to push out releases, deadlines need to be met, quick fixes slowly become the standard. In this talk, we will discuss what technical debt is, when it is acceptable and when it isn’t, and strategies for effectively managing it, both on an independent and team level.
Misfocus-caused error in software projectsAdam Russell
We know that many projects fail, or become impaired, but what is the reason given so many methodologies, tools and support systems. Error comes from many places. For whatever reason, teams create problems by investing more time in aspects of software development practice that have a smaller impact on project overall success, and accordingly invest less time in areas that have a larger impact.
Introduction to Agility from Saint Louis Day of Dot Net session:
History, Definition, Comparison to Waterfall, Agile methodologies, Myths & Misconceptions, Common failure, & Advanced discussion points.
A Data-Driven Approach to Balance Delivery Agility with Business Risk
While there are many ways to define and measure Technical Debt, one thing is clear—it has been growing exponentially as maintenance is starved and development teams are forced to cut corners to meet increasingly unrealistic delivery schedules. CAST clearly defines Technical Debt as the cost of fixing the structural quality problems in an application that, if left unfixed, are highly likely to cause major disruption and put the business at serious risk. Once Technical Debt is measured, it can be juxtaposed with the business value of applications to inform critical tradeoffs between delivery agility and business risk.
The term ‘technical debt' and the challenges it can bring are becoming more widely understood and discussed by IT practitioners, vendor managers and business leaders. If you're looking at technical debt in your organization, or already thinking about measuring technical debt with your vendors, you will find this report useful.
Copy and paste to access the full recording: http://www.castsoftware.com/news-events/event/gartner-technical-debt?gad=ss
-------------------------------------------------------
In this webinar David Norton of Gartner Research discusses recent findings on Technical Debt that estimates industry IT debt is at $500 billion—and on target to reach $1 trillion by 2015. He also talks about the importance of Software Analysis & Measurement to manage Technical Debt, how to measure debt continuously to control TCO of the application lifecycle and include debt measurement in project management and prioritization.
Presented by David Croley at ALN Houston.
Learn about technical debt (the good and bad kind), its impact on your ability to ship working product via game format.
echnical debt is a popular metaphor used in most delivery teams. It’s a powerful way to describe complicated problems, convey the importance of building things right, and describes the cumulative effect of taking shortcuts. As engineers we all appreciate why preventing and paying down technical debt is important, but its often not something ‘the business’ really appreciates or seemingly cares about.
More and more we see the backlog sliced in 2 different sections, the first being the business value adding work, the second being the technical debt work. This is also accompanied with some kind of rule that says ‘we can spend 10% of our time on technical debt’. It always feels like technical debt is just ‘something the devs go on about’, and not something that adds business value.
This talk is to try to convince you to think about technical debt differently and eliminate it from your backlogs. To do this we’ll have to explore what ends up in the technical debt bucket, why its such a problem and what we can do about it. We’ll also talk about risk, the part it has to play and how it should be your best friend when managing complicated problem domains and systems. My goal is make risk exciting, useful and fundamental in what we do….which may sound crazy, but just stick with me!
Technical debt shouldn’t be something just the dev’s care about, its something everyone should care about.
Technical debt in a software system not only impacts the productivity of the team but also compromises the external product quality. Technical debt needs to be managed pragmatically to ensure discipline, value, and quality.
Managing the the Technical Debt lifecycle. In this presentation we explore the evolution of the metaphor, the value it brings to organizations and challenges to successful adoption.
The full audio and video can be viewed at http://blog.acrowire.com/td-webinar.
A collection of slides that illustrate how to go about effectively managing technical debt on a software project. I used these slides during a demonstration at an internal demonstration on technical debt at Fuzz Productions.
The Technical Debt Trap - Michael "Doc" NortonLeanDog
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
What do we do about it?
Technical debt is something that most project teams or independent developers have to deal with – we take shortcuts to push out releases, deadlines need to be met, quick fixes slowly become the standard. In this talk, we will discuss what technical debt is, when it is acceptable and when it isn’t, and strategies for effectively managing it, both on an independent and team level.
Misfocus-caused error in software projectsAdam Russell
We know that many projects fail, or become impaired, but what is the reason given so many methodologies, tools and support systems. Error comes from many places. For whatever reason, teams create problems by investing more time in aspects of software development practice that have a smaller impact on project overall success, and accordingly invest less time in areas that have a larger impact.
Introduction to Agility from Saint Louis Day of Dot Net session:
History, Definition, Comparison to Waterfall, Agile methodologies, Myths & Misconceptions, Common failure, & Advanced discussion points.
A Data-Driven Approach to Balance Delivery Agility with Business Risk
While there are many ways to define and measure Technical Debt, one thing is clear—it has been growing exponentially as maintenance is starved and development teams are forced to cut corners to meet increasingly unrealistic delivery schedules. CAST clearly defines Technical Debt as the cost of fixing the structural quality problems in an application that, if left unfixed, are highly likely to cause major disruption and put the business at serious risk. Once Technical Debt is measured, it can be juxtaposed with the business value of applications to inform critical tradeoffs between delivery agility and business risk.
The term ‘technical debt' and the challenges it can bring are becoming more widely understood and discussed by IT practitioners, vendor managers and business leaders. If you're looking at technical debt in your organization, or already thinking about measuring technical debt with your vendors, you will find this report useful.
5 Ways to Lower Technical Debt Through Modernization.pptxreachbyteridge
Technical debt is like a shadow that looms over many businesses, slowing progress and hindering innovation. The debt accumulates when teams opt for workarounds or shortcuts in the product development process, leading to costly modifications and complexities in the future.
While the average organization loses 23-42% of its development time dealing with technical debt, CIOs across enterprises report 10-20% of their technical budget diverted to fixing technical debt issues.
Euromicro/SEAA 2019, Kallithea (Greece): Talk by Marcus Ciolkowski (@M_Ciolkowski, Principal IT Consultant at QAware) & Haralld Störrle (@stoerrle, Principal IT Consultant at QAware)
=== Please download slides if blurred! ===
Abstract:
Background: Technical debt is a metaphor for trading software quality for business goals, reminding actors of the deferred cost associated with such trade-offs. The bulk of the literature on technical debt focuses on source code quality debt. Much less research is devoted to other forms of technical debt, such as documentation debt or architecture debt. In practice, however, we often observe technical debt pertaining to high-level, domain-oriented design issues.
Goal: We aspire to fill this gap in the study of technical debt and establish "domain debt" as a first class citizen in the discourse on technical debt. We aim to explore sources, indicators, and potential remedies for domain debt.
Method: We present real-life examples of domain debt, representing common design flaws of Enterprise Information Systems. These examples are taken from our work in industry and allow us to characterize "domain debt" precisely. We explore the genesis and impact of these design flaws, and analyze the differences to other forms of technical debt.
Results: Once a name is coined, instances of domain debt pop
out surprisingly often.
Conclusions: Domain debt is a useful notion in practice, and it
can be made operational. It is suitable to steer the conversation around business trade-offs towards higher levels of system design quality.
When a mission-critical application fails, the loss of business revenue is large and swift. Poor application quality causes highly visible major outages, as well as ongoing lapses in business performance that are less visible, but steadily add up to substantial revenue loss. Even minor quality improvements can result in significant gain. Yet, executives struggle to build a business case to justify proactive investments in application quality. This paper presents a quantitative framework for measuring the immediate and positive revenue impact of improving application quality.
Using Adaptive Scrum to Tame Process Reverse Engineering in Data Analytics Pr...Cognizant
Organizations rely on analytics to make intelligent decisions and improve business performance, which sometimes requires reproducing business processes from a legacy application to a digital-native state to reduce the functional, technical and operational debts. Adaptive Scrum can reduce the complexity of the reproduction process iteratively as well as provide transparency in data analytics porojects.
In the last past months we at RockeTier were working with several large organizations in three aspects: 1) boosting existing software performance (lean projects); 2) design new systems which are capable process billions of events per day based on commodity hardware and software and 3) establishing processes in large organization that support the life cycle of performance from event management, problem management to establishing a continues performance boosting to the organization systems from RFI to production. This presentation was presented to a large telecommunication industry company. This company is considering implementing a 360 degrees performance boosting project along its main product lines.
Restructuring Technical Debt - A Software and System Quality ApproachAdnan Masood
Agile Software Architecture based overview of the technical debt metaphor … idea is that developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a "debt": on which "interest" has to be paid and which the "principal" should be repaid at some point for the long-term health of the project. (ACM)
Interview with Banca Intesa: Unbiased Metrics For Objective Portfolio Rationa...CAST
Banca Caboto is a financial company focused on capital markets. A merger with Banca Intesa necessitated an objective review of the health and structure of existing applications and systems, including those managed by outsourcers. CAST empowered this critical assessment and is now used for regular reviews to measure and control application quality.
Governance of Power Platform – As enabler, not as gatekeeperSwatantra Kumar
In today’s digital age, organizations are under immense pressure to define, ideate, build and deliver services at consistently shortening time to market. With a demanding market, an unpredictable and slowing economy, and a global shortage of skilled labor, low-code platforms are increasingly seen as a boon for enterprises aiming to fuel digital transformation by building new apps, modernizing application landscapes, or automating processes quicker and more efficiently. Low-code/no-code (LCNC) tools have seen steady growth due to their effectiveness in addressing some of the challenges in technology – primarily for digitizing workflows, enhancing user experiences, promoting internal efficiency, and their ability to quickly fill the workforce gap. Low-code application platforms are emerging as a key accelerator for app development and delivery. However, there are still challenges ahead due to a vacuum of battle-tested IT governance for low-code platforms. This article covers our view on the governance of one of the leading LCNC tools, Power Platform, and why it is important while planning, securing, deploying, and supporting applications built on the platform.
Discute as facilidades que uma ferramenta como portal corporativo pode oferecer a uma organização, apresenta os critérios de avaliação, infra-estrutura de tecnologia de informação, e o posicionamento, visão e impacto do portal na corporação.
www.terraforum.com.br
Six steps-to-enhance-performance-of-critical-systemsCAST
To view more ways to improve application performance: https://bit.ly/2OZGxgf
This white paper presents a six-step Application Performance
Application Development and Maintenance (ADM) teams often face performance issues in applications during the testing phase when an application is almost complete which results in delays and business loss. The performance modeling process using software Intelligence to identify and eliminate performance flaws before they reach to production level.
By adding dynamic performance testing with automated structural quality analysis, ADM team get early and important information that might be missed with a pure dynamic approach such as inefficient loops or SQL queries and improve the development lifecycle. The combined approach will result in detection of performance issues within the application software.
This white paper presents a six-step Performance Modeling Process using automated structural quality analysis to identify these potential performance issues at the earlier stage in the development lifecycle which results in reducing the cost but also intercept business from any kind of downfall.
This white paper helps to understand different approaches of structural quality analysis and illustrate the modeling process at work.
To view more ways to improve application performance: https://bit.ly/2OZGxgf
Application Performance: 6 Steps to Enhance Performance of Critical SystemsCAST
See more ways to improve application performance: https://www.castsoftware.com/use-cases/Improve-adm-quality
This white paper presents a six-step Application Performance
Modeling Process using software intelligence to identify potential performance issues earlier in the development lifecycle. Enriching dynamic testing with structural quality analysis gives ADM teams insight into the performance behavior of applications by highlighting critical application performance issues, especially when combined with runtime
information.
By adding structural quality analysis, ADM teams learn important information about violations of architectural and programming best practices earlier in the development lifecycle than with a pure dynamic testing approach. Structural quality analysis as part of the performance modeling process allows for fact-based insight into application complexity (e.g. multiple layers, dynamics of their interactions, complexity of SQL, etc.) and allows ADM managers to anticipate evolution of the runtime context (e.g. growing volume of data, higher number of transactions, etc.). The combined approach results in better detection of latent application performance issues within software. Resolving application performance issues early in the development cycle, these alerts help to not only save money but also prevent complete business disruptions.
See more ways to improve application performance: https://www.castsoftware.com/use-cases/Improve-adm-quality
See how to Assess Your Application: https://www.castsoftware.com/use-cases/application-assessment
Assessing application development like the rest of the business
Well overdue, it is time to measure application development and
maintenance the same way as the rest of the business, based on not just how much work someone does, but how well they do the work. As we know, looking to see if the code works as expected is only a single measurement. Knowing how easy it will be to maintain over time, how flexible it is to change as required by business changes, how quickly new team members can understand the code and get working on it and how easily the application can be tested are just some of the things that we need to look at in order to understand the real quality of the work being done by application development teams. When these measurements are combined with ways of counting the productivity (quantity) of development teams, we can get a real understanding of how well the teams are performing and what return is being realized from the investment. These measurements can be assessed both for in-house development organizations as well as the work being done by outsourcers.
The applications delivered by IT are a significant differentiator between competitors and therefore it needs to be managed as a core business process. Held up against corporate standards and no matter how or where the development work is done, it must be done well and the resulting applications need to be able to withstand time.
See how to Assess Your Application: https://www.castsoftware.com/use-cases/application-assessment
Cloud Migration: Azure acceleration with CAST HighlightCAST
Learn how to accelerate your cloud migration: https://www.castsoftware.com/use-cases/cloud-readiness-and-migration
Cloud migration is table stakes for digital transformation initiatives. The driving factors to get to the cloud vary from organization to organization...for some, it's about cost savings and for others, it's about creating smarter apps that support continuous innovation.
IaaS – For organizations looking to reduce costs, Infrastructure as a Service (IaaS) is a great option. IaaS is sometimes described as "Lift and Shift" – when applications are moved from an existing infrastructure to a cloud infrastructure. This helps save money by reducing the hardware needed to run those applications and providing flexibility to adjust infrastructure requirements on-demand.
PaaS – For organizations looking for smarter deployments that facilitate digital transformation, streamline the delivery of new feature and support emerging technologies like IoT and Machine Learning, Platform as a Service (PaaS) is a more suitable option. While a considerable percentage of new application development is done with a cloud-first mentality, most legacy software is not optimized for a cloud environment.
So now the question becomes, how do I get my existing application portfolios ready for cloud migration so I can take full advantage of new technologies and processes
Software Intelligence-Based Cloud Readiness
So you’re ready for PaaS, but before you begin to assess the technical and structural requirements of the migration, you must also determine the business drivers for cloud and the desired outcomes. Setting a cloud migration roadmap that is based on comprehensive Software Intelligence that considers both business drivers and technical features of your applications is a critical first step.
Learn how to accelerate your cloud migration: https://www.castsoftware.com/use-cases/cloud-readiness-and-migration
Cloud Readiness : CAST & Microsoft Azure Partnership OverviewCAST
Learn more about accelerating Cloud Migration: https://www.castsoftware.com/use-cases/cloud-readiness-and-migration
A joint team from CAST and Microsoft worked to define rules that assess the ability of an existing codebase to migrate to Microsoft Azure. The team then integrated the rules into CAST Highlight and moved the solution itself to Azure.
In this report, we describe the process and what we did before, during, and after the hackfest, including the following:
• How we produced the rules that assess the ability to migrate to Azure
• How we benchmarked the rules
• How we migrated the CAST Highlight service to Azure
• What the architecture looked like and future plans
• Learnings from the process
Our first objective was to define rules that assess the ability of applications to migrate to Azure and integrate those rules into CAST Highlight. This was the more-complex task for our team.
Our second objective was to move the existing application to Azure, thus profiting from App Service features such as auto-scaling and deployment slots. The existing application is a Java web app running on Apache Tomcat and using PostgreSQL as its database. This is a frequent scenario for web applications running in Azure, so we did not anticipate having any issues with this task.
Learn more about accelerating Cloud Migration: https://www.castsoftware.com/use-cases/cloud-readiness-and-migration
Cloud Migration: Cloud Readiness Assessment Case StudyCAST
Learn more about Cloud Migration: https://www.castsoftware.com/use-cases/cloud-readiness-and-migration
Review this case study of a CIO migrating applications to Microsoft Azure to see how a cloud readiness assessment help to identify obstacles preventing the organization from moving faster to Azure. Learn how to gain quick visibility through an objective assessment of your core application's cloud readiness, before you plan your cloud migration.
Learn more about Cloud Migration: https://www.castsoftware.com/use-cases/cloud-readiness-and-migration
Digital Transformation e-book: Taking the 20X20n approach to accelerating Dig...CAST
More information on Digital Transformation here: https://www.castsoftware.com/use-cases/accelerate-it-modernization
The digital transformation wave is hitting its peak. An IDC
study found that global enterprise spending related to digital
experiences is set to reach $1.7 trillion in 2019.
The problem is that companies are spending heavily on
digital transformation, but not getting results: Approximately
59 percent of those polled in the IDC study identified as
companies at a digital impasse—stuck in an early stage of
maturation and struggling to move forward.
Digital transformation frameworks—formalized strategies that
define priorities and create clear technology roadmaps —are
essential to becoming a digitally mature organization. The
20x20n approach gives organizations an iterative, cohesive
base to build their efforts around. It isn’t just a high-level
philosophy, it’s a pragmatic, analytics-driven framework.
More information on Digital Transformation here: https://www.castsoftware.com/use-cases/accelerate-it-modernization
Building Business Capabilities and Improving the Application Landscape
1. Balance Decision Making: Top-down for business capabilities; bottom-up effective landscape
2. 3 Categories are used for building the IT budget: Assign metrics that drive prioritization based on business outcomes
3. New projects should balance new capability with business risk
4. Improve landscape: accelerate time to market
5. Improve landscape: budget for high availability of critical applications and improve runtime performance
6. Improve Landscape: Strive to reduce business risks caused by application vulnerabilities
7. Improve Landscape: Prepare for dynamic staffing models
8. Improve landscape: Reduce applications support cost
9. Break Fix
Improving ADM Vendor Relationship through Outcome Based ContractsCAST
How shifting focus from time-based to outcome-based contracts improves supplier relationships and drives value.
One of the major challenges between a client and application development and maintenance supplier is that their relationship is defined by the production and management of time. Most ADM contracts can be reduced to a simple equation: Price = Rate(s) x Hours.
Suppliers remove Cost of Labor from rate to find profit, however; both parties manage time as the key variable. While these contracts are governed by project plans and deliverables, the client and supplier’s primary goal is to manage the consumption of time, not the production of business value.
Drive Business Excellence with Outcomes-Based Contracting: The OBC ToolkitCAST
Making Outcomes-Based Contracting Work With Facts
Introduction by Amit Anand, Robert Asen & Vijay Anand of Cognizant
Using metrics to develop effective results-based contracts
Managing outcome based application contracts requires a combination of scope management,
pricing, and, above all, quality. As suppliers and clients evolve the relationship, the
need for clear facts dominates conversations.
The premise of outcomes-based contracting is that hours (and indeed rate) are inputs to
the ADM process (not outputs), and that structures that measure programming results are
now both possible and achievable. Outcomes-based structures bring the original intent of
software to the forefront—creating successful results. While many companies have shifted
from input-based to output-based contracting, forward-thinking IT leaders are also taking
steps to define a sustainable outcomes-based relationship with their ADM suppliers.
Outcomes-based contracts focus on how the delivered product adds value, while inputand
output-based contracts focus on the resources and the activities needed to deliver the
outcome, respectively.
Get the big picture on your application portfolio - FAST.
Highlight is the SaaS platform for fast & code-level application portfolio analytics.
Try our demo dashboard @ casthighlight.com
Shifting Vendor Management Focus to Risk and Business OutcomesCAST
Watch the complete recording: http://www.castsoftware.com/castresources/materials/recorded/072815/
The cloud, tighter regulations, business agility, and digital transformation are driving radical changes to vendor management. Vendor management leaders have gotten more sophisticated than first generation sourcing professionals, but they now face challenges beyond cost optimization and simple performance monitoring. These disruptive forces are driving a need for vendor management leaders to advance the discipline to control risk and achieve business outcomes.
Thank you for your interest in ISG’s webinar on "Managing Service Providers for Today's Digital Business." Bob Krohn, a partner at ISG, discussed how an outcomes-based approach and Business Processes as a Service (BPaaS) are increasingly being studied and adopted by businesses as a way to drive greater effectiveness and quality at their companies.
Krohn said that companies wanting to quantitatively measure the effectiveness of their SLAs have been hindered by their inability to measure performance across multiple service providers and systems. However, advances in software analytics now make it possible for sourcing organizations to structure and measure complex SLAs so that they more closely align with business objectives. This enables them to operate with a flexibility that meets their constantly evolving requirements.
Please let us know if you would like additional insight into how Software Analytics improves service provider relationships.
To watch the complete recording, please visit: http://www.castsoftware.com/castresources/materials/recorded/072815/
The business case for software analysis & measurementCAST
As software becomes more integrated into our daily lives, companies are finding that visibility into the systems that run their business has many benefits: reduces business risks, increases revenue, and improves IT spending.
This whitepaper provides a framework for capturing the impact of software analytics on your business and a worksheet to help you create your own business case. Leaders that can clearly articulate this value are more successful than their peers in obtaining strategic support and funding for software analytics.
The cost of maintaining a software application is directly proportional to its size and complexity. IT organizations can take several steps using static code quality analysis to reduce size and complexity, and thus diminish their software maintenance costs.
Is your application system process facing problem? With the help of System-level analysis you can save your application from failures at different levels. It analyzes how the components are interacting at multiple layers & technologies. Keep your system efficient and secure.
What you should know about software measurement platformsCAST
Software analysis and measurement is a growing sector, and becoming a must-have in any company that runs on enterprise software. Do you know how to pick the right solution for your company? What are the essentials to delivering a comprehensive and actionable software quality measurement program to your entire enterprise? What about do-it-yourself solutions?
Our guide to the most important considerations about the engine that powers software measurement program will help you make smarter decisions about your own program.
The 2014 CRASH Report finds applications built with either Agile or Waterfall methods alone are more susceptible to security, reliability, performance, and cost issues.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...
7 Steps to Pay Down the Interest on Your IT Technical Debt
1.
2. Contents
I. Introduction 1 IV. The Real World of Technical Debt 15
Case Study: Large insurer 16
Case Study: Telco provider 18
II. Measuring Technical Debt 3
V. Conclusion 20
III. The 7-Step Technical Debt 7
Management Cycle VI. About CAST 21
7 Steps to Pay Down the Interest on Your IT Technical Debt
3. I: Introduction
We all make mistakes.
That point could not have been clearer in 2011, a year in which experts generally Whatever the cause of
believe that more IT system failures, outages and data breaches occurred than any
previous year since the dawn of the age of technology. And while some of these application software failure,
issues could be traced to intentional and malicious undermining of systems, many, the cost of fixing the
if not most, had some measure of application software failure or weakness at
their root. resulting structural quality
problems in production code
These failures or weaknesses in application software stem from two areas. One is
when developers write software that violates good architectural or coding practices to control development costs
causing structural flaws in the code. The other is found in legacy code – lines of
or avoid operational
code that are carried over from previous versions of application software – which
either do not work properly with the new code being written, are no longer valid or problems is called
carry defects that were not previously detected, thereby exposing the new software
Technical Debt.
to failure or breach.
1 7 Steps to Pay Down the Interest on Your IT Technical Debt
4. Introduction
As depicted in Figure 1, the causes of Technical Debt vary from simple Technical Debt Inelegant code
explanations like an inadvertent coding mistake to intentional shortcuts based ‘priority fix’ ‘fix not required’
on business needs. Regardless of the origin, organizations that do not address
the resulting structural flaws before application software is deployed expose
Intentional
themselves to significant risk and will inevitably find themselves addressing Prioritized Fix if
coding
refactoring time allows
the issues when they manifest themselves as application failures. This is how shortcut
Technical Debt is amassed.
Inadvertent Prioritized Learning
Left unaddressed, Technical Debt can so degrade an mistake bug fixing opportunity
application that its benefits to the business cannot be
justified by its growing costs or operational risks. Figure 1. Reasons for Technical Debt
Consequently, managing Technical Debt is an executive
liability for those responsible for governing the costs
and risks of application portfolios.
2 7 Steps to Pay Down the Interest on Your IT Technical Debt
5. II: Measuring Technical Debt
Although Technical Debt represents liability, it
also represents a way to apply financial terms to
the business risks associated with operational “Technical Debt’s usefulness
performance of critical business applications. has been limited historically
because most organizations
Technical Debt’s usefulness has been limited historically because most have not known how to
organizations have not known how to measure it. As a result, these
organizations have been incapable of using Technical Debt to estimate
measure it.”
the costs of application ownership or to guide management decisions
about how much to invest in application quality, which, when left
unfunded, leads to more Technical Debt being accrued.
3 7 Steps to Pay Down the Interest on Your IT Technical Debt
6. Measuring Technical Debt
Recent advances in software analysis and measurement, however,
have solved this problem. Automated analysis and measurement is far Hours to
correct Historical data
more accurate than previously employed manual assessments and is problems on maintenance
therefore more reliable and efficient at detecting software quality issues
– meaning companies now have an objective measurement of an Technical
Structural
quality Static analysis
Debt problems of applications
application’s Technical Debt, making it a critical and effective tool for
application management.
Developers
burdened IT or contractor
hourly rate finance records
Still, a single method of measuring Technical Debt does not exist.
Generally speaking, Technical Debt can be calculated by analyzing the
structural quality of an application, rating the severity of each problem, Figure 2. Components and Data Sources
and identifying the “must-fix” problems. Using this roadmap, CAST has to Calculate Technical Debt
worked extensively with industry leaders to research and devise a
method for calculating Technical Debt, as shown in Figure 2, based on
the number of must-fix problems in the code, the time needed to “...companies now have an objective
correct the problems and the cost to fix the problems.
measurement of an application’s
Technical Debt, making it a critical
and effective tool for application
management.”
4 7 Steps to Pay Down the Interest on Your IT Technical Debt
7. Measuring Technical Debt
Number of must-fix problems: The first step in calculating
Technical Debt is to determine which issues will be addressed. ((.1 LSV + .25 MSV + .5 HSV) x 1 hour x $75)
Based on its research, CAST assumes that only 50% of high Where, LSV = Low Severity Defects
MSV = Medium Severity Defects
severity problems, 25% of moderate severity problems, and
HSV = High Severity Defects
10% of low severity problems will ultimately be corrected in
the normal course of operating the application.
Figure 3. CAST’s Formula for Calculating Technical Debt
Time to correct problems: The next element in the calculation is the
time it takes for remediation. The time to fix a structural quality problem includes
the time to analyze the problem, understand the code and determine a correction,
evaluate potential side-effects, implement and test the correction, and release the Using each of these
correction into operations.
elements, the formula
Cost to fix problems: The final element in calculating Technical Debt is the cost of developed by CAST to
the time spent by a developer to remediate the issues. CAST found that the data on
calculate Technical Debt
this subject varies widely from company to company, but based on its research it
determined that $75 per hour was a conservative estimate of the average rate for is depicted in Figure 3.
developers. This figure, however, should be treated like a variable rather than a
constant and companies calculating their own Technical Debt should use whatever
the average rate for their developers is.
5 7 Steps to Pay Down the Interest on Your IT Technical Debt
8. Measuring Technical Debt
It is important to note that the Technical Debt formula presented only provides a basis
“CAST employed the formula
for benchmarking. Organizations can and should adjust the parameters in the formula
to fit their own maintenance and structural quality objectives, experiences and costs. on the previous page in its
2011-2012 CRASH Report,
CAST employed the formula on the previous page in its 2011-2012 CRASH Report
(CAST Report on Application Software Health), based on analysis of 745 applications based on analysis of 745
containing 365 million lines of code (11.3 million backfired function points) submitted
applications containing 365
between 2008 and 2011 by 160 organizations located primarily in the United States,
Europe and India. million lines of code.”
In doing so, it determined that the
average Technical Debt accrued per line
of code (LOC) for all applications
reviewed was $3.61. That means even a
slightly below average sized application
containing 300,000 LOC carries more
than $1 million in Technical Debt.
6 7 Steps to Pay Down the Interest on Your IT Technical Debt
9. III: The 7-Step Technical Debt Management Cycle
Just as individuals make decisions on how to pay The Technical Debt Management Cycle is a seven-step
process for analyzing and measuring Technical Debt
down personal debt, organizations need to (presented in Figure 4), that relies on comparing it to both
determine how they will retire Technical Debt. IT and business priorities. This process begins by
translating executive business priorities into Technical
Debt targets for each application.
Trying to do this on a global level can be
overwhelming and it is often difficult to visualize the
expected payoff. However, the analysis and
Application QA/Build/
measurement of Technical Debt can guide critical IT Executives Managers Developers Release
management decisions about how to allocate
Step 1 Step 2 Step 3
resources for reducing business risk and IT costs. Set strategic Set reduction Measure
quality priorites targets & plans Technical Debt
Executives can set specific reduction targets based
on the strategic quality priorities of their organizations,
Step 4
weighing the costs of remediation against the Plan actions for
remediation
expectation of achieved benefits. This is what is
known as the Technical Debt Management Cycle.
Step 7 Step 6 Step 5
Report to the Remediate
Track results
business violations
It is vital that actions for achieving these targets are
determined in advance, and to track the progress at
each release and periodically report this progress to Figure 4. Flow of the Technical Debt Management Cycle
the business.
7 7 Steps to Pay Down the Interest on Your IT Technical Debt
10. The 7-Step Technical Debt Management Cycle
1
Set strategic quality priorities
Since application budgets and time are constrained, IT executives must
“In highly competitive
determine the most critical structural quality objectives each application
service offers to the business and provide clear-cut guidance to application markets, business agility may
managers. In many cases, they will need to set these priorities in concert
be the most critical issue so
with the application managers since executives will generally lean toward business
risk factors, and because structural quality priorities typically vary depending upon Changeability would be a
the purpose of the application software. For instance, in highly regulated industries
priority because of its impact
the most critical issue may be protecting customer data, which would make Security
the highest priority. In highly competitive markets, business agility may be the most on the speed of delivering
critical issue so Changeability would be a priority because of its impact on the speed
new functionality.”
of delivering new functionality. And an online retail application may need to satisfy
several priorities, such as Robustness and Security.
Applications with large and growing levels of Technical Debt related to IT costs may
need to prioritize these factors over business risk issues since the application
architecture can degrade to the point that it becomes unable to serve its business
mission. In these situations, IT executives must determine the balance between
business risk factors and their own internal IT cost factors. Fortunately, structural
quality analysis and measurement provides the data needed to optimize the balance
among strategic priorities.
8 7 Steps to Pay Down the Interest on Your IT Technical Debt
11. The 7-Step Technical Debt Management Cycle
2
Measure Technical Debt
In much the same way that developers use freeware static analysis
“...the most effective times
tools to measure Technical Debt as part of their unit testing regimen
before submitting code to a build, structural quality flaws that cause to measure structural quality
Technical Debt should also be measured at numerous points in the
are either after each phase of
software life cycle. The difference between the two, however, is that analysis at the
testing level cannot detect serious architectural flaws that may span multiple layers of a build or immediately
the application and may be written in different, sometimes incompatible languages.
before release in order to
These multi-component flaws are often the most devastating during operations and
are the most time-consuming to fix. Consequently, the most effective times to determine the efficacy of the
measure structural quality are either after each phase of a build or immediately before
application as a whole.”
release in order to determine the efficacy of the application as a whole.
The build team or quality assurance typically performs structural quality analysis of
application software, although organizations may conduct it in an Application
Intelligence (AI) Center dedicated to this function. Whoever carries out the analysis
should feed the results back to the development team along with a list of the
violations that yielded the measures. These analyses should be retained as a baseline
to assess progress toward strategic structural quality priorities.
9 7 Steps to Pay Down the Interest on Your IT Technical Debt
12. The 7-Step Technical Debt Management Cycle
3
Establish reduction targets and plans
To establish a basis for decision-making, application managers need
“...Technical Debt reduction
to translate structural quality priorities into specific targets for their
application. They can accomplish this in a few ways including stating needs to be treated as a
them as thresholds, such as “no high severity performance defects in
standard component of
the operational code base,” or “sustain Transferability scores at or above 2.8
across releases.” The strategic priorities passed down by executive management maintenance or sprint
should provide the guidance needed to allocate resources toward the most critical
planning.
targets.
That, however, is where the tension arises. With every release, there is a “tug-of-war”
over the needs of the organization to provide new functionality quickly to the business
and the need to reduce Technical Debt in priority areas. As a result, structural quality
targets can rarely be achieved in the span of one or two releases. Instead, Technical
Debt reduction needs to be treated as a standard component of maintenance or sprint
planning. Application managers must allocate time for structural quality improvement
into their application maintenance plans, or in an agile environment allocate a
percentage of stories in each sprint to remediating structural quality problems (a
determination that needs to be factored in as part of the design of the agile process).
Since developers frequently participate in these planning activities, they should be aware
of the strategic structural quality priorities against which they are expected to plan.
10 7 Steps to Pay Down the Interest on Your IT Technical Debt
13. The 7-Step Technical Debt Management Cycle
4
Plan remediation actions
At the beginning of each release planning cycle or sprint, the
“To ensure the process of
application manager and development team can use the structural
quality analysis from the previous release to prioritize a list of reducing Technical Debt
violations for remediation that will help achieve the application’s
remains consistent from one
structural quality targets. The team should select as many high-priority violations to
remediate as can be addressed by the resources allocated during the cycle or sprint, phase to the next, the list of
and it is important to make sure Technical Debt does not increase because of
prioritized violations should
development activities that are separate from those being conducted for the
remediation of Technical Debt. be revised and updated after
each release.”
To ensure the process of reducing Technical Debt remains consistent from one phase
to the next, the list of prioritized violations should be revised and updated after each
release. The rate of progress in remediating the backlog of violations should also be
compared to executive priorities and timelines to determine if the amount of
resources devoted to remediation needs to be adjusted in future cycles or sprints.
This will ensure that Technical Debt planning continues throughout the application
lifespan as part of the longer strategic plan.
11 7 Steps to Pay Down the Interest on Your IT Technical Debt
14. The 7-Step Technical Debt Management Cycle
5
Remediate violations
Development teams should addresses violations tagged for “If a specific type of flaw
remediation within the cycle or sprint as part of their normal
development or maintenance activities. These remediation activities has been detected numerous
may involve refactoring poorly designed code or correcting specific
times across the code base,
coding weaknesses. Testing and static analysis should then be used to
verify that the flaw has been successfully remediated. The team should keep track of the development team
the time required to remediate structural flaws to help with more accurate estimates
should, as time allows,
on the number of remediation tasks that can be undertaken in future cycles or sprints.
identify the root cause of
If a specific type of flaw has been detected numerous times across the code base,
the flaw and take steps to
the development team should, as time allows, identify the root cause of the flaw and
take steps to eliminate it; with agile in particular, this is an appropriate topic for eliminate it...”
retrospectives at the end of a sprint. Results of these root cause analyses should be
reported back to central team conducting the structural quality analyses so they can
detect trends across the organization.
12 7 Steps to Pay Down the Interest on Your IT Technical Debt
15. The 7-Step Technical Debt Management Cycle
6
Track results
The application manager should track the ongoing results of “Technical Debt data can be
Technical Debt remediation efforts, compare the results against
established targets and share them with the development team. used as input for estimating
Significant deviations against expected progress should be
and tracking the long-term
addressed when planning upcoming cycles or sprints to develop
achievable commitments based on the resources allocated. cost of ownership for the
application...”
Periodically the application manager and IT executives should review their progress in
retiring Technical Debt and reaffirm application targets against the strategic structural
quality priorities; this allows them to adjust the targets if strategic priorities have
changed. Technical Debt data can be used as input for estimating and tracking the
long-term cost of ownership for the application, while structural quality data needed
for upcoming management decisions regarding the application should be discussed.
13 7 Steps to Pay Down the Interest on Your IT Technical Debt
16. The 7-Step Technical Debt Management Cycle
7
Report to the business
Following review with the application managers, IT executives should “The discussion of Technical
report the status of Technical Debt to the business. Because it highlights
a direct relationship between aspects of either business risk or IT cost, Debt and its potential
Technical Debt can be translated into terms easily understood by those on
liabilities initiates a dialogue
the business side. Terms like reductions in risk, limiting exposure to security
breaches or outages, increased capability for business agility or reductions in IT’s that provides businesses with
long-term costs all can be illustrated by Technical Debt and resonate with the
greater understanding of the
business side. This information can also be reported to corporate auditors
responsible for assessing risks to the business. IT risks and costs and how
they relate to business issues.”
Translating Technical Debt into business risks, however, requires the business to
articulate its costs and the losses experienced when applications suffer outages,
performance degradation, security breaches, data corruption and similar events. The
discussion of Technical Debt and its potential liabilities initiates a dialogue that
provides businesses with greater understanding of the IT risks and costs and how
they relate to business issues. Consequently, the Technical Debt Management Cycle
provides a vehicle for greater alignment between the business and IT.
14 7 Steps to Pay Down the Interest on Your IT Technical Debt
17. IV: The Real World of Technical Debt
While it is one thing to discuss Technical Debt, how
to measure it and how to manage it, it is another
thing all together to put it to use in actual practice.
The following are two cases where the determination of
Technical Debt was used to improve not only the structural
quality of application software, but also the conduct of business.
15 7 Steps to Pay Down the Interest on Your IT Technical Debt
18. The Real World of Technical Debt
Case Study
Large insurer cuts maintenance costs 20%
12
A large insurer had a claims management system
10
with 700,000 lines of code that managed 8 million 56% of reduction in
8 defects in 4 years
Defects / KLOC
claims per year from a client base of 10 million
6
customers. Development of new functionality
suffered as a result of substantial Technical Debt, 4
and was typically accompanied by high defect rates. 2
0
To gain control over Technical Debt and reduce maintenance 2002 2003 2004 2005 2006
costs, the executive in charge of this application mandated
Figure 5. Reduction in Defect Rates for a Large Insurance Application
that future development would be subjected to structural
quality measurement and baseline targets were set for
maintainability. Development teams were held accountable
for making steady progress toward the maintainability targets
release by release, and were presented the results of each
structural quality analysis.
16 7 Steps to Pay Down the Interest on Your IT Technical Debt
19. The Real World of Technical Debt
Over the course of four years, they saw the following results:
• Maintainability targets were stabilized against the baseline target even
though the application code base grew by 40%.
• Defect rates in system test and operations fell 56% as Technical Debt
was remediated and the application became easier to understand and
maintain, as shown in Figure 5.
• Delivery time was reduced by 60% as a result of more maintainable code
and less interference from rework.
• Maintenance costs for this application were reduced by 20% within the
first three years.
17 7 Steps to Pay Down the Interest on Your IT Technical Debt
20. The Real World of Technical Debt
Case Study
Telco provider reduces outages to save $2.7 million
CAST performed structural analysis of Technical Debt on the billing
system of a large telecommunications company. Management’s
objectives were to reduce rework and outages, as well as gain control
over outsourced maintenance costs. If managing Technical Debt
Anti-patterns
addressed the objectives, then the process would be deployed to Defects
reduce Technical Debt in other critical applications.
R4 R5 R6 R7
Releases
Technical Debt was measured at an initial release and critical violations of good
architectural and coding practice (anti-patterns) were targeted for remediation. Over Figure 6. Reduction in Technical Debt
and Defects across Releases
the subsequent three releases, the anti-patterns constituting Technical Debt were
steadily reduced, as shown in Figure 6. Along with this reduction in Technical Debt
was a highly correlated reduction in system test and operational defects. A decline in
The effort to remediate Technical Debt is
operational problems was also observed, which was correlated with reductions in
correlated with a reduction in system test
defect rates, although the data were not available to prove a causal relationship.
and operational defects over the next 9
releases until it appears to stabilize at
Based on the successful pilot, structural analysis was deployed to a portfolio of release 11.2. The same pattern was
critical applications to reduce and control Technical Debt. Figure 7 shows structural observed with other applications.
quality analysis was initiated on this particular application at release 8.
18 7 Steps to Pay Down the Interest on Your IT Technical Debt
21. The Real World of Technical Debt
Reducing rework by lowering
the number of defects resulted
in a substantial reduction in Code
Non code
maintenance costs.
IT estimated cost savings
of $2.7 million in the first
year on this particular
application as a result of
rework and outage
reductions as well as
R1 1
R8
2
3
R1 .2
R1 .1
R1 0
R1 .2
R1 3
R1 .1
R1
.2
R3
3
R2
R5
R9
.2
R6
.1
R4
R7
.1
.1
.1
.1
4E
R1
R1
1.
R1
R1
0.
1
1
0
0
R1
R9
R1
R9
R3
R2
R7
better management of
R8 - Structural Quality Analysis starts here
outsourced services.
Figure 7. Defect Volume Reduction across Releases
19 7 Steps to Pay Down the Interest on Your IT Technical Debt
22. V: Conclusion
Technical Debt provides a way to apply financial terms to the risks inherent in
applications that have structural flaws in code caused by violations of good
architectural and coding practices. For those with executive responsibility for
governing the costs and risks of an application portfolio, the Technical Debt
Management Cycle provides a clear process for measuring and managing
Technical Debt that can help in balancing IT and business priorities, and over
time reduce the risk of failure of critical applications.
By following this 7-step process, an organization can
weigh the costs of remediation against the expectation
Author
of achieved benefits—and ultimately pay down the
Dr. Bill Curtis, Senior Vice President
interest of the overall liability inherent in the portfolio. and Chief Scientist, CAST
For a more detailed overview on the concept of Technical Debt, please
download our white paper “Paying Down the Interest on Your Applications: A
Guide to Measuring and Managing Technical Debt.”
20 7 Steps to Pay Down the Interest on Your IT Technical Debt
23. VI. About CAST
Call: 877-852-2278
Connect with us:
Email: info@castsoftware.com
Visit our Web site: www.castsoftware.com
CAST is a pioneer and world leader in Software Analysis and Measurement, with unique
technology resulting from more than $100 million in R&D investment. CAST introduces
fact-based transparency into application development and sourcing to transform it into a
management discipline. More than 250 companies across all industry sectors and
geographies rely on CAST to prevent business disruption while reducing hard IT costs.
CAST is an integral part of software delivery and maintenance at the world's leading IT
service providers such as IBM and Capgemini.
Founded in 1990, CAST is listed on NYSE-Euronext (Euronext: CAS) and serves IT intensive
enterprises worldwide with a network of offices in North America, Europe and India. For
more information, visit www.castsoftware.com
21 7 Steps to Pay Down the Interest on Your IT Technical Debt