How does tech debt impact a Business Intelligence Implementation

 

Business Intelligence is big, it has been for a while, and there are a large number of platforms out there to choose between.  Decisions on BI implementation, in our view, often fail to recognise the importance of getting it right. Despite what many think it’s not as simple as comparing apples and apples. That is in part thanks to the prevalence of ‘Self-Service’ DIY type Business Intelligence.  So how do you ensure your BI implementation is done right and doesn’t end up costing you more in the long run?  That is through considering the Tech Debt implications.

So first….

What is tech debt

Technical debt can be thought of as a metaphor referring to all the consequences that arise due to poor or compromised development in software.  The consequences are generally with regards to the effort required to improve, enhance, or add additional functionality later on.

Just like with financial debt which we’d all be more familiar with, tech debt incurs interest if it is not repaid, and the longer we take to pay it, or the more debt that is allowed to build the greater the interest.  In a tech sense this interest relates to the amount of effort required to improve or increase functionality later on.

Sometimes real-life metaphors make things easier to understand, so let’s think of your software and tech debt in terms of the car. If you keep delaying getting your car serviced, over time the issues with your car will get more and more. We can keep driving the car with its issues, but it may be doing further damage, and also costing us more to run (much like we can continue with an inefficient process). Alternatively, we could take the car in for a service, but as we’ve waited so long for this service the volume of issues means we will be without it for a few days(much like your systems may be off-line while improvements are made, or functionality is added). We could rent a car that is cheaper to run (much like you can outsource your requirements), or you could go out and trade in for a new car (the same way you can invest in new software).

 3 types of tech debt

Accidental/unavoidable tech debt – Design was flawed and unable to easily add new features quickly/easily – but was not your fault or decision. Using our car metaphor this could be a product recall which was not your issue but does result in you being without your car for a period.

Deliberate tech debt – result of well-considered decisions. Where speed/time/cost is of most importance. Time: startups where time to market is important, or in our world where budget timelines must be met. Cost: where decide to go with the ‘cheap’ option for whatever reason.  This is like buying a small family car because that is all the budget allows, even though you know you will need a bigger car within the next year or two.

Developer tech debt – lack of skills/experience/understanding leading to poorly designed solutions that do not allow for future changes/amendments, changes to businesses etc.  This is like not considering the boot space in the car, and then after purchasing discovering the baby pram won’t fit in the small boot.

How can you limit it?

Accidental and unavoidable tech debt is as the name suggest, unavoidable.

Whilst Deliberate tech debt is a conscious choice, there are things that should be considered to ensure it is not higher than it needs to be.

Just like a family buying a new car, every business has budgetary constraints, so there will always be some element of Deliberate tech debt introduced. Not everyone has the budget to develop everything immediately, to purchase the software they will need in the future now, or to use  the most expensive consultants/developers out there.

So how can you work within these constraints to ensure you are not setting yourself up for further avoidable costs down the track?

In our view there are two elements that contribute to the avoidable components of Tech debt;

  1. The choice of platform/software (deliberate), and
  2. The choice of consultants/developer (developer skill).

A large part of Tech debt limitation comes down to the choice of platform. Some platforms are easier for the end user, others are easier to develop in. Some are cheaper and faster to ‘go-live’, whereas others are more flexible and are easier to amend/modify down the track.

Every business has different requirements of their software investments, different skills available internally, and difference paths they want to take with their implementation.  Understanding which platform is appropriate for which business is paramount in limiting Tech debt. Having access to consultants and developers who know multiple platforms, and understand the trade-off’s that exist between them, will go a long way to ensuring you select the product.  The product that is right for your business, right for now, and right for the future.

In addition to advising on the platform and product choice, consultants and developers are the main determinant of Developer tech debt. As we have been discussing, like all debt, tech debt is a long-term issue, and it can increase significantly over time if it is not managed.  Because of this it is important to ensure your consultants have not only the skills to develop within the chosen platform, but also the skills to understand your future use case, and where your business may be in 3, 5, or 10 years.

Consultants who take a longer-term view of the development and are focussed on ensuring their solutions deliver value well into the future will help to limit your tech debt. We believe consultants with both an understanding of the technical and financial/operational are perfectly positioned to provide this.  The financial and operational understanding allows them to easily understand your business, its processes and operations, and understand where it may be headed and how that will impact on the solution developed.  The can then easily translate this to the technical requirements of the solution, and incorporate these requirements back into the platform/software selection process.

Why does it matter?

For most of our readers and Finance professionals, getting into how to identify, value and manage Tech debt might be a bit too deep. Simply being aware of how you might introduce tech debt into your business, the future consequences of this, and how to limit it is what is most important.  However if you do with to delve further into Tech Debt (and the flip side Tech Equity, there is a very good article by McKinsey on exactly this.

But if Tech debt is ‘tech’ and not financial, why does it matter?

Because it costs money to reduce Tech debt, and it may cost your business if you don’t.

As businesses change in size and scale so do their requirements. The easiest way to understand is to think of accounting or ERP systems. Whereas once a small ERP system might have been appropriate, as the complexity and size of the business increases this ERP system may no longer be fit for purpose. Trying to make it work can require significant manual intervention, which often leads to data errors, resulting in reporting delays, and overall process inefficiencies.  This often results in a decision to change ERP’s.  Depending on the change this can be simple, or more often than not be a very slow and difficult process, with a significant cost involved, both for new licensing and the implementation.

Whilst we are not suggesting every business should start with the biggest and best ERP system, when selecting the platform, it is important to understand what you may require in the future, and determine how difficult, and expensive, it will be to add that functionality to the chosen platform in the future.

What about Tech Debt in Business Intelligence..

Business Intelligence is essentially visuals, backward looking analytics. It is not an ERP as used in the example above, or a car, so how does Tech debt relate to a Business Intelligence implementation?  In exactly the same way.

There are multiple Business Intelligence platforms out there, and nearly all of them will do what you want, but ensuring you select the best platform and implement in the correct way is still important in limiting your tech debt.  Anything can be changed down the track, but how hard will that be and how much will that cost?

When we get approached by prospective clients about implementing a Business Intelligence solution, the initial discussion is often around what they want now.  Often People are putting Business Intelligence solutions in place to meet an immediate need, without properly considering if that will be suitable later on.

BI is analytics, and in analytics the structure of the data is key to ensuring the required analytics are available. So having a consultant who can ask the right questions to get you to consider HOW you may want to analyse in the future is important.

Some things that should be considered are;

  • Changes to business structure and reporting levels. Eg. whilst you may only have 2 divisions now, how many may you have in the future, will there be sub-divisions underneath these?
  • Current ERP and likelihood of it changing. The ERP can significantly impact the options available to get data into your BI platform, which may then limit your choice of BI platform.
  • Frequency of data updates. The frequency with which you want your BI analytics data to update is an important consideration in both the platform selection and data structuring.
  • Chart of Accounts structure.  The Structure of your CoA (or lack of one) can determine how the data needs to be structured in your Business Intelligence solution, and how much ‘manual’ control you will need, to generate the reporting you require
  • Dashboard and report commentary entry. Not all BI platforms allow for data entry, so you need to ensure the right platforms, or platforms, are selected.
  • Self-service requirements. Do you want everyone to build their own dashboards, or do you want a central control which develops for release to the business.
  • What-if/sensitivity analysis and Budgeting and Forecasting requirements. This is only possible in certain BI platforms.
  • Users and access. The way in which you want to distribute dashboards and reports across your business, and the functionality you want in these will play a part in determining the appropriate platform

This is far from an exhaustive list, but hopefully it has given you a starting point for what you need to consider when selecting and implementing your Business Intelligence solution.

Related Articles

Four factors that influence BI success

7 Steps to get meaningful insights from your data


Contact Us

Get in touch with one of our business intelligence experts today.

Contact Now