Having gone through technical due diligence twice in my career (both of which involved the sale of a startup to a large company, the first being my ISP, Pacific Rim Network to the ISP Verio, and the second being Classmates.com to now-parent United Online), there are a few items I'd add to Kate's excellent list.
My original list included 72 items, using slightly different categories than Kate's. Rather than reproducing the entire list (with duplicates) here are the items on my list not explicitly on hers. (Admittedly, her list was more for familiarizing yourself with a new environment, but this is partly the aim of technical due diligence as well, so both her and my list are cross functional that way).
Engineering Focus Items
- What does the development environment look like?
- Developer tools, desktops, environments, data should be reasonably similar to production environments to ensure no environmental defects are introduced to production.
- What's the Code Review Policy?
- Engineering should have stricter controls and peer review in place for sensitive areas of the codebase. In particular, anything you do with credit card processing, or storing private, sensitive or legally protected data should have a formal peer review process in place. Even lacking these higher requirements, embracing such a process has been a hallmark of high-performing teams I have managed.
- Software Lifecycle management strategy?
- The code an organization relies on to run its business is akin to the food pack a travelling nomad brings along for the journey-- everything ought to be as fresh as possible, and that mystery meat should be thrown out, stat! The Y2K problem was arguably greatest for those organizations who had tons of COBOL code running their production systems without any COBOL programmers on staff. You should be asking "who owns our oldest code, when was the last time it was touched, and do we need it anymore?" Every line of code in your source code system should be adding to shareholder value, and the best place to start your analysis is typically your oldest codebase.
- Documentation, documentation, documentation.
- This is on Kate's list, but it bears expanding upon. Not only should appropriate documentation (akin to javadocs) be in-line in your source code, any artifacts that were instrumental in software design should live in a central repository (I prefer a well-organized wiki), and the culture of the organization should ensure that these artifacts are used, and re-used, or pruned when they are no longer relevant. Ideally this culture extends beyond engineering to product development, marketing and beyond.
- Security
- Are there periodic security training sessions? When was the last one held? Did it cover the OWASP Top Ten? Are the software engineers familiar with the principal attack vectors your application is potentially vulnerable to? Are your testers aware of various techniques to use to validate that your products are not vulnerable?
- Testing Strategy?
- Is testing a hodge-podge of "what feels right", or is there a strategic viewpoint? For example, are your libraries and low level code unit tested for a reason, or just by accident? Do your higher-level systems use integration and build verification tests? Are these tests automated? How often does the automation run? Do failures break the build?
- Technical Contingency Planning
- What strategies have been used until now to keep pace with scalability? What's in progress, and what does the future look like? What tier has the greatest pain? What does growth look like? Linear, logarithmic, exponential? What's the doubling speed? Are infrastructure cost needs reflected in the budget?
- Caching Strategy
- Is the architecture demonstrably using every caching tier effectively? (Browser, Edge, Web, Application, Database)
Configuration Management/Deployment Focus Items
- What is the Deployment & Configuration Management Strategy?
- 3rd party and vendor software is often deployed using RPMs, or using package managers like yum, apt, or (heaven forbid) tarballs or system-based software package managers. But what do you use for internally built software? These tools are often language specific (ant/maven for java, for example, or gems for ruby, or pear for php), and in hybrid environments, having engineers package software releases into rpms shows a higher degree of aptitude (pardon the pun) in configuration management and deployment.
Information Technology (IT) Focus Items
- 3rd Party Licenses
- All 3rd party software on engineers' desktops should be properly licensed. A culture of respecting others' intellectual property must be encouraged, and a process that directs new software requests to management (for consideration whether single-, multiple- or a site- licenses should be acquired).
- Proper ownership of technical assets?
- Are ownership of technical assets in the right hands? From domain name registrations to licenses to support, telco and datacenter contracts, they should, to the extent possible, be using role-based accounts monitored by multiple people, or if directed at a person, ideally someone high up enough in the chain to have fiduciary responsibility.
- Customer Support System
- What's the ticketing system?
- Policy Compliance
- This is a very broad area. To the extent it is relevant, are your software products in compliance with regulations including (but certainly not limited to) CAN-SPAM, Privacy/Terms of Service, COPPA, PCI-DSS, SOX, HIPAA, etc.?
- Hardware Documentation
- Do you have a list of all of your hardware assets? When were they acquired? When are they due to be replaced? Are they granular enough to take into account sub-systems? (Cards, hard drives) What software versions do they run (i.e. are they firmware and software patched and up to date)?
- Legacy Assessment
- What systems, software and hardware are considered legacy? (To me, this means, not currently under an active support contract, end-of-lifed, no bugfix policy, or hardware older than 3 years old). Are they that way because of certain software systems, or vice versa? What's the plan for untangling the mess?
Operations Focus Items
- Network Bandwidth
- What's current base and peak utilization? If peak is approaching > 30%, what are the plans on what timeline to expand bandwidth needs? (This applies to every central or branch office, as well as to any critical or backup datacenter, or to any VPNs or leased circuits)
- Single Points of Failure
- Kate touches on this from a broad perspective, but it bears considering network path redundancy. What happens if a given link is cut? Say a backhoe takes out a bundle of fiber. What alternatives for every business-critical system do you have in place?
- Hosting Infrastructure Review
- Kate also touched a lot on this area, but ensure that your DNS, Web, Database, Data Warehouse, Reporting and Monitoring systems have no single points of failure, and if they do, a mitigation, disaster recovery, remediation or response plan should be identified.
- Escalation Lists
- You should have a list of escalation contacts, technical, business or otherwise, with every 3rd party service provider, from facilities (your office building, data center) to transit provider (telco/ISP) to service providers (cloud hosting, cloud service provider, etc.). Ideally copies of these for Technology would be kept in the same place as your SLAs and contracts.
- Infrastructure Concerns
- These are mostly environmental. Space, power & cooling (both nominal and backup) in your various places of business, particularly colo/hosting facilities.
- System Administration Policies
- In line with PCI-DSS, do you have controls (audits) of who did what to what system? Who has administrative access (this list should generally be constrained to key operations folks). Who has the root password (this list should be ultra-minimal, allowing most administrators to use sudo or passwordless ssh-to-root style access)?
- Environment Restrictions?
- Do you enforce environment restrictions ensuring that only people who "need" access have it to any given environment?
- Application Restrictions?
- Whether it's a bug tracking system, ad server system, customer support system or otherwise, ideally access to these systems are governed by centralized policy, authentication and controls (say, LDAP for example).
- Physical Security
- Are keys (physical or digital) to critical systems locked up, with backups, with restricted access? Are critical systems secured physically and digitally?
- Backup Access?
- Access to backups should be treated as sensitively as the most sensitive data they contain. Archives of credit card numbers should be under lock and key in a bolted-down safe, whereas HTTP access logs can just be locked up in an office, for example.
- Data Retention Policy
- Is it defined, and adhered to?
I hope this list, in conjunction with Kate's, helps you identify what opportunities your startup faces to raise the technical diligence of your organization. If there's something missing from our lists, please add it to the comments below!
