I was invited by Rafal Los (@Wh1t3Rabbit) to publish as guest blogger to his HP blog... reposted here for posterity.
----
If you’ve been paying attention to the Enterprise Architecture space, the notion of measuring, managing and avoiding technical debt has come into the forefront in the past 5 years. Broadly attributed to Ward Cunningham, technical debt is a concept spawned from the adjacent concept of design debt. The idea of technical debt is that there are decisions made throughout the SDLC that hamper the delivered product from the ideal, and that this is deficit spending you'll have to pay for eventually.
There might be a compelling business reason to host a public application with web/app/database on the same physical server, implement deprecated function calls, or to use MS-SQL 2008 for your database because you're constrained in some fashion; this is all cruft that will likely result in future efforts to correct the architectural misstep. In essence, you're willing to saddle the organization, business unit, and that application with "technical debt" because of an imperative like time-to-market, budget shortfall, or architectural constraints imposed from legacy investments (i.e. - creating more technical debt because of existing technical debt).
You've likely gritted your teeth several times in your career when you run into problems of technical debt -- Visual Basic codebase, NT servers still in use, use of telnet, users with desktop admin privileges, use of custom cryptography, all of these are examples of intractable technical debt in a large enterprise.
We all have technical debt -- but is it managed? In my experience across many large organizations, while people get the concept of technical debt, after a fashion, the governance of it is exceptionally difficult, because it means having teeth in your governance program sufficient to make very hard business decisions. To transition from notional concepts of technical debt to actual _managed_ technical debt, you have to have accountability for the technical debt, a way of measuring and reporting on it, and managing it into the future budget cycles. From discussions with peers, few organizations have a mature enough Enterprise Architecture and portfolio management practice to be able to manage that in a suitably complex environment. When your network is so large that no single person can know it all, or no single person has visited all your facilities, then managing technical debt becomes a difficult problem. In most organizations of that size, your portfolio management and EA teams would be happy if they could just know all the applications (and cloud apps) installed by shadow IT.
Measuring "relative evil" as technical debt when an application is implemented, warts and all, as a means of assessing progress (deprogression) is a great way to drive visibility through metrics. However, when it comes to actually putting the wheels on tech debt governance and driving it down the road, that's another thing entirely. That requires a level of sophistication in portfolio management that most organizations are not ready to achieve, IMHO. However, in organizations that can pull it off, there are some hard dollars to be found in R&M, rework, outages, costs passed along to future projects, brittle architecture, and lack of first-mover advantage. In other words, it's worth the trip.
As architects, it's our job to articulate those issues to the ones making the decisions to add technical debt, and make it clear that it's not cheaper, not by a long-shot -- in my experience, the total costs are probably 10x the total costs being "saved" by the project right in front of them wishing to add technical debt. I've also advised several times to go with the tech debt to gain first-mover advantage in a new market, because it's the right thing for the business, tech debt be hanged.
This brings us to the brink of security debt, which is a very useful term if you can make it stick. Once people latch onto the notion of technical debt, you have fertile ground for making the leap to security debt, as the notion of managing and measuring the costs associated with deviation from policy, standards and suitable good practice. However, notice I referred both to the brink of security debt, and leaping. Be careful where you take that, because if your organization cannot effectively measure and manage technical debt, they likely aren't ready for security debt. However, a good quantitative analysis method (I'm a fan of Jack Jones' FAIR model) combined with metrics and collaboration with audit can likely create a solid picture during the SDLC of the actual probabilistic losses associated with security debt being added to the organization, and that can be a powerful tool.
As Dan Geer has said many times, in Information Security, the future belongs to the quants.
---------------
No comments:
Post a Comment