What is your strategy to reduce the technical debt of your organization IT services and infrastructure?
Sort by:
I think the keyword is priority. Its necessary to establish at least a minimal plan, generally ordered by budget and number of customers impacted, as well senior management priorities (organization goals). Its important to see that technical debt and other related situations must be addressed due to the organization's goals. Technology is a very deep and wide ocean with many nuances and its impossible to face them all. Sometimes IT teams work on 'IT situations' rather than customer needs or organization goals. So, the most important thing is to equalize and align all these things, because technical debt should be as important as the impact it has on business results.
This is so true. If tech debt reduction is not a business priority and is clearly mentioned in the organization goals, any amount of planning and strategy would not fail. Business needs to understand that for growth, we need to let go of old applications. We cannot just focus on the new stuff and do not have a plan to get rid of the old.
Tech debt is one of the most common challenges faced by most of the organizations. Establishing a 360-degree view of the environment by applying application context is important to understand the intensity of tech debt. This will help determine the magnitude of the risk, provide a means to apply business context to the identified debt. Most of the tech decisions are made by the app CIOs in-line with their business priorities and this creates disconnected and siloed environments. It is essential to have a platform centric architecture and a clearly defined tech roadmap. This will lay out a definitive path to all the use cases in the organization. Establishing and publishing an enterprise-wide tech roadmap is key to minimize tech debt as the business grows, priorities change with the ever-evolving needs of the customers. Following a lived experiences strategy, engaging with all the business and technical stakeholders while defining the enterprise tech roadmap will ensure widespread adoption of the defined roadmap. Another important aspect is to define standard patterns aligning with the roadmap and strategic tech choices. Publish the patterns and encourage stakeholders to use the standard patterns. Establish strong governance with business and technical stakeholders to monitor the usage of patterns, and to identify any deviations and prevent from creating a tech debt that can create a significant risk to the overall strategy.
Interesting question! It is important at first to recognise that any technology choice could result in a technical debt if not managed properly. The strategy we used to have is primarily focused on establishing a technology roadmap plan and monitor it annually. However, business priorities could deter technology changes. Please be aware of the disability of your technology roadmap.
Standardized containers. It matters that much. Start with a secured, layered, published, and controlled (meaning 1 version of a tech stack with the next version in the works and that's it) container images. Start small focusing on the most impactful container (the stack that causes the most pain and/or the most common stack). Standardized containers give you the ability to patch quickly, truly embraces DevSecOps, allows you to pivot, and stops the hemorrhaging nearly all organizations experience quickly.
Remember that DevSecOps means DevSecOps. Build teams of people that are invested in the work and not just checking boxes. Cyber is always successful even if the power is off, I've never actually seen Cyber's success tied to project success...just compliance (think about that). Invest Cyber's success with business / project success. So, treat DevSecOps as a cultural way of doing business. It's not a position, it is THE WAY. Start with Developers, Operations, and Security at the start of an effort, not as an afterthought. Standardized containers are part of DevSecOps.
Automation is also a pillar of DevSecOps culture. Automate anything you can.
Agile means Agile, not GRAGILE (Government Rigid Agile) or FRAGILE (Federal Rigid Agile). Don't meet unless you must, meetings should produce results (action items) and help resolve friction (those things that are slowing down progress). Keep technical meetings between those that need to be technical and don't include everyone. Ensure that all team members recognize that "that's the way we've always done it" is no longer okay or an excuse. Remove blockers recognizing that it might take some time to change things but put that blocker on your radar and act.
Enterprise Architecture means you know what you have now, you know who you provide services to now, you have identified your goals and capabilities and have identified the gaps now. EA means you are looking to the future and thinking about where you're going next considering those CI's/concepts/etc. that are causing you technical debt.
Bake process in with standardization. There's no point in making a single tech stack that does not allow for deviation. What's your process for
Eat the elephant in small bites, you just can't do it all at once.
Change happens in small increments; transformations allow for backslide. Think of a rachet whose teeth inside the gear mechanism don't allow you to "go back" and it does this in small increments that make going back a non-option.
Finally, some folks will never learn or don't want to learn but sometimes you can light the path (by showing them the benefits, it's an investment but pays downrange) and they will follow it. If you can't get them to follow the path figure out how to optimize their abilities for your benefit (you should do this with all team members).
There are several lenses to how you can approach this, and borrowing themes from contemporary CIO playbooks they would be: 1) Security 2) Stability 3) Scaleability and 4) Modernisation.
My approach to this in the capacity of a CISO, was to tackle the security lens. I've found it useful to show a graph of aggregate vulnerabilities growing from end of life and end of support systems, combined with change freezes where patching is not applied such as peak trade periods in retail or online... I've then overlayed this with when hackers are the most active, and you start to see on a graph some hot zones of vulns increasing + peak trade period + no patching + hacker activity. This has led to a "we must reduce the technical debt to avoid this perfect storm scenario" - and several successful "Tiger Strike" projects, aimed to compliment operational teams in reducing technical debt - bad configurations and lack of patching.
I think it would be similar to Stability. Technical Debt leads to a variety of performance issues present in environments where hygiene and maintenance is poor. Scaleability... technical debt often prevents the use of technologies, such as the complex and often undocumented relationship between business applications, and databases... making any "lift and shift" to cloud where elasticity and scaleability are prime benefits.... and lastly Modernisation. Tech Debt is the polar opposite to modernisation. You can find many bullet points for how a lack of modernisation has multiple factors... the talent/workforce are geared to contemporary technologies not something used 10-15-20 years ago. A lot of the crazy good digital user experiences are hard to utilise when you're on some old CMS and front end tech.
All 4 of these themes can be used collectively to paint a picture of Technical Debt as being an anchor that holds an organisation back.