{"id":27029,"date":"2019-05-22T15:48:43","date_gmt":"2019-05-22T20:48:43","guid":{"rendered":"https:\/\/centricconsulting.com\/?p=27029"},"modified":"2022-09-30T12:50:03","modified_gmt":"2022-09-30T16:50:03","slug":"technical-debt-why-is-such-a-simple-change-taking-so-long","status":"publish","type":"post","link":"https:\/\/centricconsulting.com\/blog\/technical-debt-why-is-such-a-simple-change-taking-so-long\/","title":{"rendered":"Technical Debt:\u00a0Why is Such a Simple Change Taking So Long?\u00a0"},"content":{"rendered":"
Part of a blog series.<\/em><\/a><\/p>\n Technical debt is a cleansed and politically correct term.<\/span>\u00a0<\/span>If you haven\u2019t heard it before,\u00a0<\/span>a more accurate description of it in the data<\/a> world would be \u201c<\/span>stuff we know is\u00a0<\/span>needed but<\/span>\u00a0<\/span>i<\/span>sn\u2019t\u00a0<\/span>done<\/span>\u00a0yet<\/span>.<\/span>\u201d<\/span>\u00a0<\/span><\/p>\n Given that<\/span>\u00a0<\/span>a picture is worth a thousand words, let me paint one for you.<\/span><\/p>\n Imagine you\u2019re a commercial lines underwriter.<\/span>\u00a0<\/span>You\u2019re looking at expanding an existing\u00a0<\/span>custom commercial multi-peril product<\/span>,<\/span>\u00a0<\/span>which will require a detailed analysis\u00a0<\/span>of your existing book of CMP business.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n As part of the analysis, you<\/span>\u2019re going to want to look at a series of underwriting questions\u00a0<\/span>and third-party data\u00a0<\/span>that the policy management system tracks.<\/span>\u00a0<\/span>Most importantly, you\u2019re going to want to see a lot of this data available on a regular basis to track the success of the product expansion.<\/strong>\u00a0<\/span>You know this data exists, it’s in the core system you\u2019ve been writing this business on <\/span>and\u00a0<\/span>you just want access to it<\/span>.<\/span>\u00a0S<\/span>imple right?<\/span>\u00a0<\/span><\/p>\n You submit your request to your information technology team and\u00a0<\/span>a meeting is scheduled.<\/span>\u00a0<\/span>If this is your first time making this type of request, you probably walk in excited.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n You\u2019re looking forward to the business value of the product expansion and\u00a0<\/span>this meeting is going to get you\u00a0<\/span>the\u00a0<\/span>critical support you need to make that happen.<\/span>\u00a0<\/span>By the time the meeting ends, a lot of your excitement has likely been replaced with concern, frustration and disappointment.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n During that meeting, you likely were exposed to the concept of technical deb<\/span>t in a fundamental, non-specific way<\/span>.<\/span>\u00a0<\/span>In short,\u00a0the complexity of the existing data architecture was explained\u00a0in enough detail to identify a series of\u00a0hurdles that would have to be cleared to make this request happen, effectively taking this from \u201csimple\u201d to \u201ccomplicated.\u201d\u00a0<\/strong><\/p>\n Once that was understood, the conversation of available resources and existing prioritized work c<\/span>omes up and \u201c<\/span>complicated<\/span>\u201d becomes \u201c<\/span>complicate<\/span>d\u00a0<\/span>technically and politically<\/span>.<\/span>\u201d<\/span>\u00a0<\/span><\/p>\n So,<\/span>\u00a0afte<\/span>r this experience, you probably walked out of the room\u00a0<\/span>feeling\u00a0<\/span>confused<\/span>\u00a0\u2013<\/span>\u00a0and that you and IT are at odds<\/span>.<\/span>\u00a0<\/span>The unfortunate part about this experience is\u00a0<\/span>that everyone involved want<\/span>s this initiative to be successful and as transparent as possible to make sure <\/span>the right expectation is set.<\/span>\u00a0<\/span>However<\/span>, what you didn\u2019t realize walking into that meeting, is\u00a0<\/span>your<\/span>\u00a0product expansion is\u00a0<\/span>going to cost a lot more than you thought,<\/span>\u00a0and you\u2019re not sure why.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n The reason<\/span><\/b> for this is the especially vague nature of \u201ctechnical debt<\/span><\/b>.<\/span><\/b>\u201d<\/span><\/b>\u00a0<\/span><\/p>\n As an underwrit<\/span>er<\/span>, you\u2019re likely very familiar with project<\/span>–<\/span>specific technical debt.<\/span>\u00a0<\/span>For example, you\u2019ve probably run into<\/span>\u00a0minor screen tweaks on your policy management system\u00a0<\/span>going on a backlog<\/span>. That<\/span>\u00a0became<\/span> technical debt<\/span>\u00a0because while they are considered a defect,\u00a0<\/span>their potential impact is low enough that fixing it has been deferred.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n However, there are other forms of technical debt that are far less\u00a0<\/span>clear\u00a0<\/span>and whose implications are much further reaching<\/span>.<\/span>\u00a0<\/span>One of those forms of technical debt<\/span>\u00a0just created a\u00a0<\/span>large<\/span>\u00a0headache for you<\/span>\u00a0and the only way to avoid it doing so again in the future<\/span>\u00a0is to\u00a0<\/span>shine some\u00a0<\/span>light on it.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n The most common form of technical debt in the world of data is<\/span>\u00a0<\/span>foundational.<\/span>\u00a0<\/span>To understand what that means, here\u00a0are a couple\u00a0of core concepts we need to agree upon:\u00a0<\/strong><\/p>\n So,<\/span>\u00a0<\/span>to put this into the context of\u00a0<\/span>our hypothetical<\/span>\u00a0scenario<\/span>, the answers to underwriting questions have value.<\/span>\u00a0<\/span>How much value\u00a0<\/span>they<\/span>\u00a0ha<\/span>ve<\/span>\u00a0is\u00a0<\/span>subject to interpretation and requires analysis to prove.<\/span>\u00a0<\/span>That data<\/span>,<\/span>\u00a0while it may be gathered\u00a0<\/span>at the time the policy is underwritten<\/span>, is not automatically available for analysis<\/span>.\u00a0<\/span>It<\/span>\u00a0is instead buried in the policy management system<\/span>\u00a0<\/span>which shouldn\u2019t be available for direct access t<\/span>o perform analytics.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n Given this<\/span>\u00a0and the general drive for projects to focus on value-add\u00a0<\/span>deliverables, the effort necessary to make your underwriting question data available for analysis at the time they were implemented\u00a0<\/span>was differed and became \u201ctechnical debt<\/span>.<\/span>\u201d<\/span>\u00a0<\/span>In short, this leaves you paying for\u00a0decisions made potentially years before\u00a0and, in that time,\u00a0many factors have complicated the implementation and\u00a0increased the cost associated with that decision.\u00a0<\/strong><\/p>\n If you\u2019ve ru<\/span>n into this example or something similar in the course of your career, hopefully, this shines a little light on what happened<\/span>\u00a0and potentially why.<\/span>\u00a0<\/span>If you\u2019re curious about how to avoid this happening in the future, <\/span>read on!<\/span>\u00a0<\/span>Above we referenced the three core concepts\u00a0<\/span>that generally provide context to Data Technical Debt.<\/span>\u00a0<\/span>What we didn\u2019t cover is how those three concepts have fundamentally created a lot of technical debt<\/a> over the years\u00a0<\/span>with P&C insurers.<\/span>\u00a0<\/span>There has been a\u00a0<\/span>long-presumed<\/span>\u00a0premise<\/span>\u00a0<\/span>in<\/span>\u00a0<\/span>enterprise analytics<\/span>\u00a0that<\/span>\u00a0\u201call data we deliver must be governed<\/span>.<\/span>\u201d<\/span>\u00a0<\/span><\/p>\n That means any data\u00a0<\/span>we provide for analysis\u00a0<\/span>must<\/span>\u00a0have a standardized name, definition, underlying formula, cleansing rules, and must be published into a centralized platform (usually called an Enterprise Data Warehouse).<\/span>\u00a0<\/span>As you can imagine, governing data costs money<\/span><\/b>\u00a0and if you want to be smart about where you invest, you don\u2019t want to spend that money unless you know there\u2019s value in it.<\/span><\/b>\u00a0<\/span><\/b>So,\u00a0let\u2019s think about\u00a0that for a moment:<\/p>\n I know data is valuable, but some data is far more valuable than other<\/span>\u00a0data. A<\/span>nd I don\u2019t want to spend money governing all the data, just the data that is of\u00a0<\/span>high<\/span>er<\/span>\u00a0value<\/span>.<\/span>\u00a0<\/span>However, I don\u2019t have a true\u00a0<\/span>answer on<\/span>\u00a0which data is more valuable, or how much more valuable it is without doing the analysis<\/span>.<\/span>\u00a0<\/span>Unfortunately,<\/span>\u00a0<\/span>as noted above, I can\u2019t do the analysis because I don\u2019t have access to that data in the first place.<\/span>\u00a0<\/span>That fundamental chicken or the egg situation is at the core of most data technical debt.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n It also clearly disproves the tenant that \u201call data we deliver must be governed<\/span>The Scenario<\/h2>\n
Enter Technical Debt<\/h2>\n
What Just Happened<\/h2>\n
Data Technical Debt<\/h2>\n
\n
So, Now What<\/h2>\n