Technical Due Diligence Checklist

• Operating platform
  Depending on the technology, we need to examine what the operating platform is and how it scales out. Even if we say, oh, its fine, its mobile, we only have to worry about device performance, well, what about the backend? .. does that need to scale? If the service is cloud based, has it been built using managed services such as DocumentDB on Azure or Elastic beanstalk on AWS, does it rely on a series of dev-ops managed virtual machines that have to be carefully monitored, orchestrated and maintained and parched manually?
  
  
• Extensibility
  Here, we need to examine the system to see if it takes future growth into consideration. Are there any particular things that stick out as barriers to growth? For example, if the customer numbers were doubled in the morning, what kind of problems would this cause? .. how long does it take to onboard a new customer (technically), are there any on-boarding processes carried out for the customer that are not automated?
  
  
• Disaster recovery
  No matter how well we plan for things, stuff always happens unexpectedly. When it does, from a diligence point of view, we want to know how can the technology or system be recovered. What plans are in place, that steps need to be taken for a full system rebuild, how about the urgent need to change deployment/production platform or cloud provider? What if there is a major data loss, what are the key backup and critical data/service/configuration storage methods?
  
  
• Diagnostic monitoring
  One of the things I constantly tell people is that 'what we don't know is important'. Too many people trap and log errors, but how often do we look at and examine these logs to see what we can learn and improve upon? Here I am looking for any processes in place for logging and for analysis of logs that are generated to improce system quality and performance.
  
  
• Bottlenecks
  It's rare for a system not to have bottlenecks. Invariably, something creeps in that hasn't been thought through properly, or was never meant to be left in production for long, or was an ad-hoc feature that became important. These bottlenecks can be a killer for scaling. Look in particular at areas where the outside world touches into the system. How are customers taken onboard? Is there external data imported in a regular basis, if yes, is this automated, and how is it setup up? what monitoring of these systems are there? what happens if data fails to come in, or if too much comes in, is the system constrained by data volume in this manner? (etc!)
  
  
• Network diagram
  Although strictly part of the architecture, I like to dive deeper into how the network and communications are constructed, with a particular focus on any area that might cause a slowdown if things were to ramp up quickly.
  
  
• Future plans
  Knowing what we have today is one thing, but what's planned for the system into the future? ... how will the implementation of these new plans affect the existing system, will any area have to be reworked/revised as a consequence?
  
  
• Data repositories
  Assuming the system handles data, how is this stored and managed? what is the current data load? what are the data storage limits? what is the current per day/month data growth rate, how can the repository handle 10x, 100x growth? what kind of indexing schemes are used? is data pre-prepared and denormalized for fast lookup if necessary? are in memory databases utilized? how are unique identifiers/primary keys generated, will this cause a problem with fast moving data?
  
  
• Load testing
  Has the system been load tested under stress? if yes, what methodology was used and can iut be replicated? if not, what would it take to scale up a test and can it be done? Load testing like this can quickly identify scaling issues and are well worth considering.

Production

Once you have examined the core of how the system hangs together, you need to examine it live in production. What are the running system metrics like? is the system under pressure? is it well utilized? are there any IO or network bandwidth problems? Careful examination of the system in a live production environment is extremely important - sometimes what people think is happening is not, and running some performance monitors on a system while carrying out maintenance operations for example can give valuable insight.

• Deployment
  Once code is complete, how is it pushed into production? Check if continuous integration and deployment are utilized, carry out some minor changes or tests to see it in operation. If you had to create a complete new instance of the system or move it to another provider, how could this be done, confirm the steps required.
  
  
• Third party dependencies
  It is important to identify and have documented any third party dependencies in the production environment. Not only is knowledge of what is used, and how, but also any licensing requirements of same. In addition, you need to check any third party items for potential problems with scalability and support and maintenance.
  
  
• Infrastructure health monitoring
  We know we need to look at error trapping, logging and reporting on a code level, but equally important is what is done in relation to this on a system production level. Enquire as to what OS/VM/Container/Infrastructure health monitoring is carried out, how frequently logs are checked and what kind of automated reporting on more severe log items is carried out.
  
  
• Data archiving/purging lifespan
  Determine what processes are in place for data archiving and where necessary purging. Check if archiving requires any systems to be moved offline or can it be carried out live, in addition, confirm the procedure for data and overall system restore tests and look for logs in relation to this to confirm.

Support

It is rare that a system runs itself without issue, in this section we examine what structures are in place for development, maintenance and end user support.

• Existing development support
  When new development resources are brought onto the team, is there a formal technical induction process, if yes, investigate what it is. Are there any contracts in place with third party suppliers or vendors to assist the development team, if yes, get sight of these and evaluate terms, conditions and costs.
  
  
• End user support
  Unless the system you are evaluating is simply technically facing, you will have some kind of end user support requirement. One would expect that the developer of the technology you are evaluating has their own support systems in place, perhaps a database of customer issues, bugs, frequently asked questions etc. Getting sight of user support history can greatly assist in evaluating future support requirements within your own organization and how these might (or not!) scale, costs involved etc. User support also tends goes in a curve, with more hand holding up front as a user on-boards to a system, and as you introduce new features, but leveling off thereafter. It is important to get an appreciation of how user support fits into the overall picture as heavy user support can kill or dramatically slow down an integration project.

Legal

The legal requirements of due diligence can be broken into two parts. On one hand there is the big legal picture that talks about contracts, financials, etc., but from a technical due diligence point of view we are more interested in legal aspects of the technology itself; who owns it, are there third party licenses involved, are there limitations on use etc.

• Code ownership
  On the face of it, who owns the code is not as clear cut as one might think. The Internet provides an open repository of code we can cut and paste from, and such code may or may not have certain conditions attached to it. Some open source code allows full commercial use, others restrict the use to non commercial or other open source projects, and of course a whole range of options in between. There is a useful list of open source licenses at opensource.org. The important thing to check here is what is the origin of the code, is it used under license, and if so, who owns the license and is its use permissible.
  
  
• License infringements
  It is prudent to specifically ask for and inspect any indemnity insurance carried against third party licensing infringements. You want to ensure where possible that you don't transfer or spread liability for something that goes wrong, or if you do, that you mitigate the risk.
  
  
• Compliance and regulation
  Depending on the country and industry in which you operate, it may be the case that your technology needs to adhere to certain compliance or regulatory laws or rules. This can range from privacy laws in relation to data, to standards and quality regulation in the case of medical and aviation technology. Talk to the business and business legal team to see if there is anything that needs to be covered off here on a technical level.
  
  
• Recurring licensing
  Many products use third party licenses that are upgraded each year. Sometimes they are bought for one purpose and never upgraded, other times they come with an annual recurring license fee that is required for continuing use. Regardless of what type of licensing is there, any third party licenses need to be identified, checked and verified to see if there is any ongoing liability.
  
  
• License transfer
  Some forms of technology license specifically forbid license transfer. This is done for a variety of reasons, and the upshot is normally a new license agreement needs to be put in place, usually with an associated cost. Most contracts will have a clause regarding ownership and transfer of ownership. If its not clear, pass it over to the legal bods for clarification.

Fit for purpose

This category is a moving target depending on the technology itself, where it is to fit into the organization, and the sector the organization is in etc. The bottom line is you want to know if the technology solution you are taking onboard is fit for the purpose that your organization intends to use it for, and ultimately, is it a good match or not.

• Gap analysis
  Put together a table that lists out the expectations that your organization has of the technology you wish to onboard. Rate each expectation as 'must have', 'must be capable of having', and 'nice to have'. Must haves are items that are in general show stoppers, 'capables' are features that can be added on with little effort, and 'nice' to have are an added bonus. Don't fall into the trap of making everything a 'must have', in reality its difficult to find a perfect match and you should expect to have to change things once you acquire a new technology. Once you have your list, you can simply check things off as you go along and will very quickly see if you have a match or not (regardless of how everything else comes together in your overall evaluation).
  
  
• Technology match
  Unless you are acquiring a development team along with the technology, be very careful about ensuring there is a technology match. You don't want to give the go-ahead for a system written using a Java or Python framework if your in-house team is entrenched in the .NET world (or vice versa) without making appropriate recommendations for maintenance and development resources, training etc.
  
  
• Skills match/gaps
  In addition to looking for matches and gaps in the base technologies used, also consider any skill matches or gaps. For example, your in-house team may have experience in MS SQL but the incoming technology is built on a NoSQL MongoDB and Redis cluster.

Wrap-up

To reiterate, this checklist is based on personal experience and won't suit everyone; in addition, I'm sure others out there will have gems of wisdom to add. Please leave comments so we can make it a better resource for all!