IT debt = Eternal burden ?

 

IT debt     = Eternal burden  ?

Technical debt has an assumed name because it is somewhat similar to financial debt: if it is not repaid, interest accumulates.   The more this debt is ignored, the more it takes root and spreads through the system, like a slow-release poison, leading to a gradual loss of efficiency.   Technical debt in IT is: Partly an analogy to describe  the accumulated cost of quality compromises in developments . This often results from a requirement for speed and efficiency, which will take precedence over the quality of developments. Partly an analogy to evoke  outdated technologies still exploited on a large scale, on which the company can be heavily dependent.  The Cobol language is the best-known example.

How to diagnose the presence of a “technical debt”?

Are you seeing an  increase in maintenance costs? Are you having  difficulty recruiting staff for your projects , particularly people skilled in the technologies that pose a problem to you? Are minor changes to your projects taking more and more time? Have you postponed Cloud migration projects  because the source system seems so complex to you? ....    Obviously, an information system cannot have been developed in a perfectly homogeneous manner and there can be continuous technological updating. But this must not weigh down companies too significantly.    Measuring technical debt in IT architecture is complex. There is no single metric for doing this. There are certainly some indicators such as the time required to operate the supply chains without errors, the ratio between the cost of remediation and the cost of developing a new technical solution, the level of satisfaction of the teams working on the project , number of unfixed bugs, migration speed, etc. But none of these methods caught on.

Rather than measuring, we propose to correct things:    By sharing the knowledge of a system to everyone , By reducing volumes, and therefore complexity, By enabling migrations of outdated legacy technologies.

Fix things by sharing with everyone knowledge of an analytics system

We believe that it is essential to make everyone aware of all the processes that are at work within an analytics system: where the data comes from, where it goes, who uses it, how it is processed, with what tools, when….   Data lineage based on the analysis of data processing, its storage, its scheduling, its consumption (reporting and queries), in short, makes it possible to draw up an exhaustive portrait of a system and to share its understanding. to everyone, even though the technologies are old and the chains are complex.    Our data lineage solution, {openAudit}, analyzes the most widespread technologies in legacy systems. Some examples :  Power supplies: Cobol, T-SQL, PL/SQL, Bteq, Perl, etc.  ETLs: DataStage, BODS, SSIS, Talend, ODI, etc.  Data visualization: BO, Qlik, SSIS, Crystal Report, etc.    All technologies are reconciled for an exhaustive reading of the data construction and deployment processes.   We have developed countless mechanisms to deal with what can generate breaks in flows: views, views of views, dynamic procedures, data transfers by FTP, etc. Anything that can actually create opacity.  The “map” of the system is produced continuously, with variable granularity depending on the need.

Fix things reducing ​ the volumes

Among all the branches of a system, a large part has no use.  The intersection of data uses and {openAudit} data lineage makes it possible to highlight unnecessary flows, which can make it possible to discard them with all their content: tables, code, ETL jobs, dashboards, etc. Maintenance may drop significantly.

See as well :

Identify and remove “dead branches”

Fix things allowing legacy technology migrations

The obsolete technologies that make up a large portion of IT debt are often very heavily used. It is complex to get rid of it  : For databases, their strong history is the source of countless dependencies. For the data visualization layer, the intelligence is often sedimented in considerable proportions, which makes migration projects often hazardous.   By relying on the hyper granularity of {openAudit} analyses, we have developed migration engines allowing us to make very effective “moves to Cloud”, with a minimum of regression, whether for certain databases, or for certain data visualization technologies.

Conclusion   IT debt is a burden accumulated due to a number of small, very legitimate negligences, or by the natural obsolescence of certain technologies. It is expensive, because it requires continually untangling knots and surrounding yourself with increasingly rare skills. Above all, it prevents systems from being modernized.   To reduce it, we believe that the implementation of automated processes is essential. Automate, to share with everyone the understanding of the twists and turns of a system, automate the detection of what is not or no longer useful, and automate migrations to current technologies, often in the Cloud.

Contact​