10 Steps of a Successful Technology Audit

When merging with or acquiring a technology company, team, or product, there are many different elements one must think through in order to be successful. In this article, we’ll take a look at ten things you should consider from the technology perspective. The goal is to help you take a non-emotional look at all things technology and come out with a rough score to help you make that final decision of moving forward with your merger or acquisition. 

There are a number of areas to consider under the flag of “technology audit” and they can be tackled in various ways. Some of the related areas are also lightly touched upon but will be covered in more detail in future posts dedicated to those topics.

The following article presents tasks that take into account technology considerations. We’ll also take a look into the relationships between them. With each of these considerations, we’ll also present additional sub-areas to apply a 1–5 score to as you work through your audit, with 5 being the best-case scenario. At the end of the audit, you can summarize the total number of points awarded to each area. The higher the score across the board, the better.

AREAS WE WILL CONSIDER IN THIS ARTICLE:

• Implementation details
• Popularity of the technology
• Team considerations
• Automation and efficiency
• Vendor support
• Total cost of ownership
• Compliance
• Security
• Legal
• Importance of a third-party point of view

TECHNOLOGY IMPLEMENTATION DETAILS

Where should you start? Look at the code! Usually, you can get read access to code in the source control repository. This is where you can take a quick look at how the code is written, its consistency, organization, etc. From this high level, it will be easy to see what sort of a mess you are looking at, if the maker was exact and organized, or how they put things together. You also can identify patterns and structures that were used. The areas to score from 1–5 are:

• Code readability
• File and folder structure
• Design pattern usage
• Coding best practices
• Code concerns separated appropriately 

Another option that is more time-consuming, but provides even more insight is to have one of your team members bring the code down to their local development environment to try and get the system running. Some areas to evaluate and score (1–5) are the following:

• How large is the system, and why?
• Is “getting the code” as easy as downloading one repository, or are there many repositories of code to pull into your local system?
• Does the directory structure, system configuration, and local environment variables add complexity to getting the system to run?
• Is there a build script that smartly runs to build the system, or must the code be built/compiled in a specific IDE?
• Can the system be easily compiled on your team members' machines?
• Once the build is sorted out, can you run the system without errors?

Once the system can be compiled (built) and run on a developer’s machine, the next question is how does the developer ensure that the system is running correctly? Here are some additional items to consider and score:

• Are there other background runtimes that need to be thought about in the same way as above? Download, build, run.
• What code or system dependencies are required that can’t be run locally? Are those effectively mocked out, or is there a centralized dev environment that developers can work against?
• Is there a process to deal with differences between a developer’s environment and production?
• Are there unit tests to ensure that the logic of the application is correct? Building and running don’t guarantee the correctness of the system.
• Are there tests to ensure that integrations with sub-systems are working?
• Are there functional tests to ensure that the front-end systems are working as expected?
• Are there performance or reliability tests for systems with large user communities or heavy load requirements such as Black Friday events to ensure that new features don’t derail performance targets?

Technology decisions tend to drift over time; what we thought was a great idea can change from year to year. It’s not that a decision was bad when it was originally created; but our assumptions might now be invalidated or we have found better, more efficient ways of doing things. You may find yourself in a position where you’re looking at that “best way of doing things” — from 15 years ago. Put someone on your team with years of experience in the specific technology being acquired to take this quick sneak peek. 

If you don’t have someone who fits that description, don’t skip this step. Find someone who knows the technology, architecture, and implementation. This team member should also understand your plans for the future needs of the system. This will allow them to keep future goals in mind when designing solutions or purchasing new assets.

POPULARITY OF THE TECHNOLOGY

It's important to consider how popular the technology stack is today. You could have a very well-formed system for its time, but if the underlying technology is no longer relevant, you may have a hard time finding someone to work on that system, add new features, support it, or even migrate it to a new suite of software. Some questions to ask in this area include:

• Using Google trends, how does the programming language that’s used compare to more current programming languages? How do the various admin frameworks compare to other admin frameworks? How does the front-end tooling compare? This will give you an idea of if the tooling is trending up or down over time.
• What versions of the software (and tools) were used to create this product? Antiquated? Bleeding edge?
• Does the company that made the underlying tooling still support their product? You may have to go back to the source code, or source of the tooling vendor for help from time to time.

TEAM CONSIDERATIONS

The team that you have is likely responsible in some way for the software that you are purchasing. You might have a great team! You might have a team of dead weight. Most likely, you have a mashup of a bit of both. Let’s see if we can figure out how much of each you have.

• How much turnover in the technology team have you had?
• If you have a long-lived team and the assessment has scored poorly so far, it is likely this team's responsibility for what you have.
• If you have a short-lived team and the assessment has scored poorly so far, it is likely the management team’s responsibility for what you have.
• If you have a mix of long-lived people and a couple of short-lived people — and the assessment has gone poorly — top performers won’t stick around.
• How are the team’s communication style and cadence? 
  - Do they meet often? 
  - Are they personable?
  - Do they assign blame more than they take responsibility?
  - Does everyone have the opportunity to give input?
• How does the team treat the “iron triangle?”
  - Does the team own the quality of the products?
  - Are they sensitive to the budget being spent on the product?
  - Do they respect deadlines?
  - Are they willing and able to push back on additional scope in favor of a healthy conversation around quality, budget, and timeline?
• How does the team manage new features, bug requests, and critical production issues?
  - Is there a project manager?
  - Is there a product manager?
  undefined

AUTOMATION AND EFFICIENCY

In addition to the tools and frameworks that make up the software and the cohesiveness of the team that is building your product, there is another area that will tell you about the product you are acquiring. How frequently does your team deploy new software, how stable is that process, and how does it impact your customers? Some questions to ask here are as follows:

• How many times a day are you able to deploy new features or bug fixes?
• Do you have to pause clients’ access to the system when performing deployments?
• If a part of the system goes down:
  -What process is used to monitor when this happens?
  -What process is used to identify what happened?
  undefined
• How does the team validate that all areas of the system are working as expected
• How do you monitor that adding a new feature doesn’t break an existing element?
• Does the team think about the scale the business hopes to achieve and build features accordingly?

VENDOR SUPPORT

When buying a software product, it may not be apparent how many software vendors or open-source projects are being utilized to make up your product. Your company may have a stance on using open-source software vs. prominent, brand-name commercial vendors. Equally important is the age of the dependent software pieces and whether or not the vendor or OSS project is still actively supporting those components. Some questions to consider are:

• What are all third-party dependencies, and which are open-source software vs. purchased software?
• For each item in that list, is it still an actively developed dependency?
• If any dependency is unsupported, what are the risks, and are there other options available?
• What is the timeline for each dependency before it is no longer available or supported?

TOTAL COST OF OWNERSHIP

There are at least three high-level costs to consider when purchasing software. Not properly digging into this area could come back to bite you in the future. Areas to consider here include:

• Runtime costs
• Support costs
• Future business needs

COMPLIANCE

Compliance is a complex subject and has many areas of focus and expertise, such as privacy and security. For example, perhaps you are buying software that manages some aspect of a hospital’s infrastructure. Maybe you are purchasing a system that manages a natural resource for a city or cities. Or, you might be acquiring a system that manages student data.

These systems require a certain level of compliance to be in place as it pertains to the system, its data, and access to its infrastructure. Perhaps even physical building security in an office area is needed. Some questions to consider are:

• Is your business or the software you are purchasing subject to any regulatory compliance?
• Should the product you are purchasing conform to a certain compliance standard but doesn’t? What will it cost you to get the product into a state of compliance?
• Are there areas of the system that require compliance that may be forcing all of the systems to be held to the same standards?
• Are there reasons the system should be compliant but isn’t?

SECURITY

Similar to the compliance space, security is an area of a system or product that is not prioritized appropriately. It is also an area that may require an expert that doesn’t currently exist on the development team. Some questions to ask are:

• Who has access to the production environment and why?
• How is both physical and digital access managed?
• Is data encrypted at rest?
• Is data encrypted in flight?
• What strategies are used to ensure there aren’t internal holes in our infrastructure and its access?
• What tools are used to ensure that malware is guarded against on team members’ machines?
• What level of security tooling is in place to keep people from getting into the software product or its supporting infrastructure?
• How is the infrastructure configured from a security perspective?
• What sort of monitoring is in place to validate network traffic?
• If attacked, what tooling is in place to deal with it?

LEGAL

First, I’m not a lawyer and Inventive doesn't provide legal advice. I can only tell you stories from the trenches. Get a reasonable attorney that specializes in IP law. If you can afford it, get a team of lawyers so that you have at least two sets of eyes in the process. If the contract side is not perfect, you may find yourself tied to a vendor forever or never fully owning your software. Many of the questions above will ferret out any questionable areas of the product. But some critical things to have spelled out and understood include:

• What is the timeline for transition?
• At what point will I see and thoroughly inspect the software, team, and related processes?
• Will I get access to the software’s source control, including its history?
• Will I own the data as well as the software?
• Will I own the data schema and all related logic in the data storage system?
• Are there any dependencies in my system that I will not own the rights to?
• For how long will your team support ramp up my team?
• Who is responsible for getting the software running in my environments?
• Will I have a third party review the system and all required dependencies and systems before purchasing the software? (due diligence)

IMPORTANCE OF A THIRD-PARTY POINT OF VIEW

From our experience, be sure not to use the “smartest technologist in the room.” You might know someone that appears to be a technology expert. They may even have worked at Google for a time and are legitimately super smart. However, that doesn’t mean that they are an expert in auditing systems or in what you are acquiring. Don’t fall into this trap, as you may end up purchasing something you quickly regret. Some areas to look for in a non-emotional third party are as follows:

• Do they know the tech that is used in the product I am interested in purchasing?
• Have they audited complex systems before?
• Do they have an example report they can provide of past projects?
• Do they have references for the work they have performed before?
• Are they larger than one individual capable of leaning on many different team members for specific areas of an audit?
• Does the team come with a history of building large and small systems?
• Does this teamwork in my industry and understand what I am trying to achieve with this acquisition?

As you can tell from the above, looking at an existing system for acquisition purposes is no easy task. This post is a starting point for auditing a technology product — large or small. Be sure to use the sheet we have prepared for this article as a way of tracking what you find out about the product during your audit.

There are many different areas to consider, and they are not all purely technical. Each of these high-level areas can be dug into even deeper depending on your plans post-acquisition. If you tend to integrate the existing team into your company, there are many other areas to dig into. If you plan to migrate off the existing infrastructure to your infrastructure, there are many areas to consider as well. 

Join our mailing list to find out more about auditing software systems, teams, and infrastructure. We have many great articles planned on this topic.