Contact Us
Partner Portal
Help Desk

Two In A Box – Configuration Management

Two in a box (if you can) and everyone in documentation (always).

In an IT context, “two in a box” refers to two servers or components that are designed to work together to provide redundancy and increased reliability. This setup can ensure that if one component fails, the other will take over its operations, thus maintaining the continuity of service. The goal of having “two in a box” is to provide high availability and disaster recovery. This also applies to human roles in an organization; however, it is rarely implemented.

Let’s look at a relevant Analytics example. We all likely know a person in our company or organization by name who is the “go-to” person for Analytics. They’re the ones who have reports or dashboards named after them – Mike’s Report or Jane’s Dashboard. Sure, there are other people who know analytics, but these are the true champions who seem to know how to get the hardest things done and overachieve on deadlines. The issue is that these people stand alone. In many cases under pressure, they don’t work with anyone as that might slow them down and this is where the problem begins. We never think that we are going to lose this person. I’ll refrain from the typical “let’s say they get hit by a bus” or using an example leveraging the current job market opportunities and say something positive like “they won the lottery!”, because we should all do our part to be positive these days.

The Story
Monday morning comes, and our analytics expert and champion MJ has submitted their resignation. MJ won the lottery and has already left the country without a care in the world. The team and people who know MJ are thrilled and jealous, yet work must go. Now is when the value and reality of what MJ was doing is about to be understood. MJ was responsible for the final publish and validation of the analytics. They always seemed to be able to improve efficiency or make that difficult change before supplying the analytics to everyone. No one really cared how it got done and was secure in the fact that it just happened, and MJ was an Analytics individual Rock Star so a level of autonomy was bestowed. Now as the team starts to pick up the pieces, the requests, the daily issues, the modification requests they are at a loss and begin to scramble. Reports / Dashboards are found in unknown states; some assets didn’t update over the weekend, and we don’t know why; people are asking what’s going on and when things will be fixed, edits that MJ said were done aren’t showing up and we have no idea why. The team looks bad. It’s a disaster and now we all hate MJ.

The lessons
There are some easy and obvious take-aways.

  1. Never allow an individual to work alone. Sounds good but in smaller agile teams, we don’t have time or the people to make this happen. People come and go, tasks are many, so it is divide and conquer in the name of productivity.
  2. Everyone must share their knowledge. Also sounds good but are we sharing with the right person or people? Keep in mind that many lottery winners are coworkers. Doing knowledge share sessions also takes time away from tasks and most people only invest in skills and knowledge just in time when it is needed.

So, what are some real solutions that everyone can be able to implement and get behind?
Let’s start with Configuration Management. We’ll use this as the umbrella term for several similar topics.

  1. Change Management: The process of planning, implementing, and controlling changes to software systems in a structured and systematic way. This process aims to ensure that changes are made in a controlled and efficient manner (with the ability to revert), with minimum disruption to the existing system and maximum benefit to the organization.
  2. Project Management: The planning, organization, and control of software development projects to ensure that they are completed on time, within budget, and to the desired quality standards. It involves the coordination of resources, activities, and tasks throughout the software development lifecycle to achieve the project objectives and deliver the software product on schedule.
  3. Continuous Integration and Continuous Delivery (CI/CD): The process of automating the building, testing, and deployment of software. Continuous Integration requires regularly merging code changes into a shared repository and running automated tests to detect errors early in the development process. Continuous Delivery/Deployment involves automatically releasing tested and validated code changes into production, allowing for rapid and frequent releases of new features and improvements.
  4. Version Control: The process of managing changes to source code and other software artifacts over time using specialized software tools. It allows developers to collaborate on a codebase, maintain a complete history of changes, and experiment with new features without affecting the main codebase.

All the above refer to good software development practices. Analytics that drive and run the business deserve no less as they are mission critical to decision making. All of analytics assets (ETL jobs, semantic definitions, metrics definitions, reports, dashboards, stories…etc) are just code snippets with a visual interface for designing and seemingly minor changes can reek havoc on operations.

Using Configuration Management covers us to keep running in a good state. Assets are versioned so we can see what has happened in their life span, we know who is working on what along with the progress made and timelines, and we know that the production will go on. What is not covered by any pure process is the transferring of knowledge and the understanding of why things are the way they are.

Every system, database, and analytics tool have their own quirks. Things that make them go fast or slow, items that make them behave a certain way or produce a desired result. These can be settings at a system or global level or things within the asset design that make them run just as they should. The problem is that most of these things are learned over time and there is not always a place to document them. Even as we move to Cloud systems where we no longer control how the application executes and we rely on the supplier to make it as fast as possible the tweaking of definitions continues within our assets to unlock exactly what we are looking for. This knowledge is what needs to be captured and shared by making it available to others. This knowledge has to be required as part of the documentation of assets and made an integral part of the version control & CI/CD check in and approval process and in some cases even as part of a checklist prior to publish of things to do and not do.

There is no magic answers or AI to cover up for shortcuts in our analytics processes or lack there of. Regardless of the size of the team that keep the data and analytics flowing an investment in a system to track changes, version all assets and help to document the development process and capture knowledge is a must. Investment in processes and time up front will save a ton of wasted time later figuring things out to maintain a healthy state of our analytics. Things happen and its best to have an insurance policy for MJs and other lottery winners.

 

Ready to streamline and automate your BI & analytics platforms?
Get A Demo
White Motio Logo Image
Solutions
Products
About Us
Resources
Contact
  • Tel:1 (972) 447-9595
  • Toll Free:1 (833) 855-3073
Follow Us
Youtube Linkedin Twitter
© 2024 Motio. All rights reserved
Scroll to Top
As the BI space evolves, organizations must take into account the bottom line of amassing analytics assets.
The more assets you have, the greater the cost to your business. There are the hard costs of keeping redundant assets, i.e., cloud or server capacity. Accumulating multiple versions of the same visualization not only takes up space, but BI vendors are moving to capacity pricing. Companies now pay more if you have more dashboards, apps, and reports. Earlier, we spoke about dependencies. Keeping redundant assets increases the number of dependencies and therefore the complexity. This comes with a price tag.
The implications of asset failures differ, and the business’s repercussions can be minimal or drastic.
Different industries have distinct regulatory requirements to meet. The impact may be minimal if a report for an end-of-year close has a mislabeled column that the sales or marketing department uses, On the other hand, if a healthcare or financial report does not meet the needs of a HIPPA or SOX compliance report, the company and its C-level suite may face severe penalties and reputational damage. Another example is a report that is shared externally. During an update of the report specs, the low-level security was incorrectly applied, which caused people to have access to personal information.
The complexity of assets influences their likelihood of encountering issues.
The last thing a business wants is for a report or app to fail at a crucial moment. If you know the report is complex and has a lot of dependencies, then the probability of failure caused by IT changes is high. That means a change request should be taken into account. Dependency graphs become important. If it is a straightforward sales report that tells notes by salesperson by account, any changes made do not have the same impact on the report, even if it fails. BI operations should treat these reports differently during change.
Not all reports and dashboards fail the same; some reports may lag, definitions might change, or data accuracy and relevance could wane. Understanding these variations aids in better risk anticipation.

Marketing uses several reports for its campaigns – standard analytic assets often delivered through marketing tools. Finance has very complex reports converted from Excel to BI tools while incorporating different consolidation rules. The marketing reports have a different failure mode than the financial reports. They, therefore, need to be managed differently.

It’s time for the company’s monthly business review. The marketing department proceeds to report on leads acquired per salesperson. Unfortunately, half the team has left the organization, and the data fails to load accurately. While this is an inconvenience for the marketing group, it isn’t detrimental to the business. However, a failure in financial reporting for a human resource consulting firm with 1000s contractors that contains critical and complex calculations about sickness, fees, hours, etc, has major implications and needs to be managed differently.

Acknowledging that assets transition through distinct phases allows for effective management decisions at each stage. As new visualizations are released, the information leads to broad use and adoption.
Think back to the start of the pandemic. COVID dashboards were quickly put together and released to the business, showing pertinent information: how the virus spreads, demographics affected the business and risks, etc. At the time, it was relevant and served its purpose. As we moved past the pandemic, COVID-specific information became obsolete, and reporting is integrated into regular HR reporting.
Reports and dashboards are crafted to deliver valuable insights for stakeholders. Over time, though, the worth of assets changes.
When a company opens its first store in a certain area, there are many elements it needs to understand – other stores in the area, traffic patterns, pricing of products, what products to sell, etc. Once the store is operational for some time, specifics are not as important, and it can adopt the standard reporting. The tailor-made analytic assets become irrelevant and no longer add value to the store manager.