IT debt = Eternal burden ?

 

IT debt     = Eternal burden  ? Technical debt is given a pseudonym because it is somewhat similar to financial debt: if it is not repaid, interest accumulates.   The more this debt is ignored, the more it becomes rooted and spreads through the system, like a slow-release poison, leading to a gradual loss of effectiveness.   Technical debt in IT is: Partly an analogy to describe the accumulated cost of quality compromises in developments . This often results from a demand for speed and efficiency, which will take precedence over the quality of developments. Partly an analogy to evoke outdated technologies still widely used, on which the company may be heavily dependent. The Cobol language is the most well-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 are causing you problems? Are minor changes to your projects taking longer and longer? Have you postponed cloud migration projects because the source system seems so complex? ....    Of course, an information system cannot be developed in a perfectly homogeneous manner, and there must be continuous technological updates. But this must not place too much of a burden on the company.    Measuring technical debt in IT architecture is complex. There is no single metric for doing so. While there are a few indicators, such as the time required to operate 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, the number of unfixed bugs, migration speed, and so on, none of these methods have gained traction.  Rather than measuring, we propose to correct things:    By sharing knowledge of a system with everyone , By reducing volumes, and therefore complexity, By enabling migrations from outdated legacy technologies. Fix things by sharing with everyone knowledge of an analytics system  We believe it is essential to make everyone aware of all the processes at work within an analytics system: where the data comes from, where it goes, who uses it, how it is processed, with which tools, when, etc.   Data lineage, based on the analysis of data processing, storage, scheduling and consumption (reporting and queries), allows us to draw up an exhaustive portrait of a system and share its understanding with everyone, even when the technologies are old and the chains are complex.    Our data lineage solution, {openAudit}, analyzes the most common 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 a comprehensive reading of the data construction and deployment processes.   We have developed countless mechanisms to deal with things that can cause breaks in the flow: views, views of views, dynamic procedures, FTP data transfers, etc. Anything that can actually create opacity.  The system “map” is produced continuously, with variable granularity depending on the need. See also:  Data Lineage: Risk Reduction & Governance Fix things by reducing the volumes Among all the branches of a system, a large portion has no use. The intersection of data usage and {openAudit} data lineage allows us to highlight unnecessary flows, which can allow us to discard them along with all their content: tables, code, ETL jobs, dashboards, etc. Maintenance could be significantly reduced.  See also:  Identify and remove "dead branches" Fix things by allowing legacy technology migrations Obsolete technologies, which make up a large portion of IT debt, are often heavily used. It is difficult to dispose of them  : For databases, their high age is the source of countless dependencies. For the data visualization layer, intelligence has often sedimented in considerable proportions, which makes migration projects often risky.   By leveraging the hyper-granularity of {openAudit} analyses, we have developed migration engines that enable highly efficient “moves to Cloud” with minimal regression, whether for certain databases or for certain data visualization technologies. Examples:  Migrating from Oracle to Postgre Migrate from SAP BO to Power BI    Conclusion   IT debt is a burden accumulated due to a number of small, but legitimate, oversights, or the natural obsolescence of certain technologies. It is expensive because it requires constantly untangling knots and surrounding oneself with increasingly scarce skills. Above all, it prevents systems from being modernized.   To resolve this, we believe that the implementation of automated processes is essential. Automate, to share with everyone the understanding of the intricacies of a system, automate the detection of what is no longer useful or no longer useful, and automate migrations to the latest technologies, often in the Cloud.