this is a long one so apologize but no short way to deal w/ the breadth of this part...
in my last post i went into the initial technical due diligence topic i focus on, staffing. from that topic i like to get into the infrastructure and then architecture aspects of the company’s technology decision making. for both of these, diagrams (if available) do the best job of telling the story, so i recommend that cto’s be prepared to provide network, server infrastructure and product architecture diagrams. both physical and logical are usually the best way to start the process of telling the complete story of their technology environment. easiest place to start the infrastructure overview is with the provider methodology: in-house or outsourced, so who’s doing the network they’re utilizing, how is it managed and where are the servers (or services) located. this should be provided for all areas, so development, testing, staging, production, redundant locations and disaster recovery. now most startups will not have all of these segmented areas from an infrastructure or even logical segmentation standpoint, but that’s ok. its always a good idea to hear the answers to things you know aren’t in place yet but might be desired by them in the near future or it could be an area you think they’ll need as they scale but maybe not when they’re still in their early growth phase. for buttoned up startups this is easiest part of the conversation since it involves mundane data center located systems that are highly commoditized so these cto’s can usually rattle off their low cost and high availability decisions that haven’t required much staff growth if any at all. ok I just showed one of my biases but in today’s world, network and infrastructure is highly commoditized and for a startup to opt for in-house hosting it really needs to be justified with a unique reason, can’t say i can think of any myself but that’s what these conversations are for, to hear about the intended company’s reasons for doing whatever unique thing it is they do with technology. next the budget allocated for these mundane infrastructure areas should be fully exposed, including assumed scale parameters. so they need to be able to state that their current deployment can handle up to “x” growth and then go through exactly how the environment would need to be extended to meet net new growth of “y”, what it would entail and how long they assume it would take to get it accomplished, especially exposing any assumed risk and what they’d need to mitigate that risk. the risk discussion is a normal part of internal company technology growth conversations so having it enter into a funding discussion is sometimes seen as peculiar but for me it just makes sense, i want to see how the normal technology decision making and thought process works so why not get into their treatment of risk.
so once the infrastructure is understood, its time to get into the architecture. this is where the conversation can go in a lot of directions and expose whether the company is grounded in its approach or shackled with barriers to growth and success. i pride myself in being a technology agnostic, which i feel has allowed me to work w/ a ton of technology platforms w/out bias, thus i feel i’ve been able to select the right technology tool for the situation at hand instead of starting w/ a technology preference and trying to then force it into a situation that it might not be well suited to handle. so this part of the conversation is meant to fully document the technology framework that supports the products of the company, whether its appropriate for the stage of the company, thus not overbuilt but also not architected in such a way that any spike or growth event will expose its fragile startup state. this is also the critical area for most funding discussions, if the expectation is to use funds to extend the framework how this is going to occur needs to be fully exposed and vetted, especially if its to extend functionality, because that means new product components, added risk and a grounding in change control management. I like to understand every aspect of software and methodology utilized by the technology team, which is sometimes shocking to raw teams because while they know what they do to create on a daily basis, they might not have had to explain the how and why details of it to someone outside their team. so i do feel like my asking them to walk me through “everything” is a good exercise for them in step back, take a breath and break it down into, we need to do “x” so we did it this way w/ “y” because etc… again a critical juncture in the discussion but often the pivotal point when I feel like i’ll be able to tell whether they’re “real” (as mentioned in part 1) or not…
here’s my core technology sections of the outline that i tend to follow:
2. infrastructure & architecture
2.1. network & infrastructure diagrams (or descriptions)
2.2. systemic, programmatic & product architectural diagrams (both physical & logical)
2.3. data center services
2.3.1. summary of data center services contracts (or approach)
2.3.1.1. bandwidth under contract
2.3.1.2. racks under contract
2.3.1.3. data center operations services under contract
2.3.2. budgets for all data center and operations support services for previous 3 full years and anticipated for current year
2.3.3. provide methodology regarding disaster recovery & business continuity
2.4. list of development, staging and production hardware in use, including whether it is owned or leased (include full specs)
2.5. list of major software systems in use, including whether they are owned or leased or purchased on an asp basis (include versions)
2.6. describe methodology related to such key technology decisions such as: security, data integrity, scalability, change control and dealing with emerging technology requirements (include any others as needed)
2.7. please list major software platforms, toolkits and applications, including:2.7.1. whether purchased, partnered with or built in-house
2.7.2. detailed description of all product related platforms/applications
2.7.3. detailed description of all supporting or backend platforms/applications
2.7.4. explain who is responsible for maintenance of the above platforms/applications
2.7.5. please list details of all patents (device, method or process)
2.7.6. analytics
2.7.6.1. please provide all traffic metrics, such as monthly page views and monthly unique visitors for previous 3 full years and anticipated for current year
2.7.6.2. please provide any other relevant analytical reporting that is utilized by the company for previous 3 full years and anticipated for current year
that’s it on core technology; again as i’ve stated throughout these posts, i try to keep it conversational and generic enough in nature to handle a wide variety of company types and scenarios, going into depth via additional questioning as needed. anything you think i missed in these sections? next post i’ll get into workflow and governance areas that i focus on which will hopefully be the final part ;)
Comments