IT Leaders continually strive to balance the diverging needs of the organization, trying to address the “innovate vs sustain” challenge. They need to ensure that the limited resources support the existing investments in technologies, systems and processes while also enabling innovative techniques.
One of the key challenges in sustaining technology landscape is to ensure “technical debts” are paid off.
The term technical debt is generally used to describe the burden created by decisions to cut corners during design and coding software. The catchy metaphor is attributed to Ward Cunningham, who helped us think about how quick-and-dirty solutions set us up for debt that has to be paid back with interest. Technical debt driven by software vendors is a less frequently discussed, but significant variation on the theme.
In a recently published article in Cutter IT Journal, I try to broaden the conversation around technical debt to include the challenges of keeping up with software vendors’ lifecycles. Such vendor-driven technical debt requires the continual attention of CIOs and technology executives who need to balance limited budgets to address the issue.
This seems to be a persistent challenge fellow Enterprise Architects face in other organizations too. For instance, a query in a recent EA forum generated nearly a dozen responses in a span of a few days. Damien Malone’s queries on tracking technical debt - How do I track? What do I track? - yielded a range of ideas.
Software vendors and solution providers continually upgrade their product offerings, promising newer technical and functional capabilities. In order to provide support, vendors expect clients to keep up with their upgrade cycles. Upgrading to a newer version of software recommended by the vendor requires deliberate impact assessment to understand the potential impact to systems upstream or downstream. Such an upgrade may have to be orchestrated with changes in the rest of the landscape; for example, during a large pre-scheduled program.
After a few cycles of not upgrading, the software may fall behind the vendor’s support cycles, and the vendor may demand a penalty for supporting older versions. Some vendors call this “extended support,” and it can be expensive. In some cases, after adequate notice, vendors may stop support of versions going back several generations.
Note: a more detailed analysis of this topic and techniques to address and repay technical debt are in my Cutter IT Journal article “Vendor-Driven Technical Debt: Why It Matters and What to Do About It (link).”
Cross post from my LinkedIn Pulse article
One of the key challenges in sustaining technology landscape is to ensure “technical debts” are paid off.
The term technical debt is generally used to describe the burden created by decisions to cut corners during design and coding software. The catchy metaphor is attributed to Ward Cunningham, who helped us think about how quick-and-dirty solutions set us up for debt that has to be paid back with interest. Technical debt driven by software vendors is a less frequently discussed, but significant variation on the theme.
In a recently published article in Cutter IT Journal, I try to broaden the conversation around technical debt to include the challenges of keeping up with software vendors’ lifecycles. Such vendor-driven technical debt requires the continual attention of CIOs and technology executives who need to balance limited budgets to address the issue.
This seems to be a persistent challenge fellow Enterprise Architects face in other organizations too. For instance, a query in a recent EA forum generated nearly a dozen responses in a span of a few days. Damien Malone’s queries on tracking technical debt - How do I track? What do I track? - yielded a range of ideas.
Crux of the problem
Enterprises of all sizes buy or license software products, solutions, and tools from vendors. These products range from small investments in worker productivity tools to large investments in ERPs, CRM, databases, and specialized solutions designed to meet specific functional needs. The decision to implement a version of the software — for example, Oracle Database 12c Release 1 or SQL Server 2008 R2 or SAP ERP 6.0, EP 4 — is generally a strategic one, requiring considerable analysis, planning, and resources. Such decisions are taken at a point in time, while considering the organization’s business needs and constraints in the technology landscape.Software vendors and solution providers continually upgrade their product offerings, promising newer technical and functional capabilities. In order to provide support, vendors expect clients to keep up with their upgrade cycles. Upgrading to a newer version of software recommended by the vendor requires deliberate impact assessment to understand the potential impact to systems upstream or downstream. Such an upgrade may have to be orchestrated with changes in the rest of the landscape; for example, during a large pre-scheduled program.
After a few cycles of not upgrading, the software may fall behind the vendor’s support cycles, and the vendor may demand a penalty for supporting older versions. Some vendors call this “extended support,” and it can be expensive. In some cases, after adequate notice, vendors may stop support of versions going back several generations.
Note: a more detailed analysis of this topic and techniques to address and repay technical debt are in my Cutter IT Journal article “Vendor-Driven Technical Debt: Why It Matters and What to Do About It (link).”
Cross post from my LinkedIn Pulse article
No comments:
Post a Comment