How to Perform Technology Risk Assessment at Small and Medium-sized Companies

If you’re running any business bigger than a coffee point, information technology is already a significant part of your company. Accounting software and payment solutions or marketing tools are some of the technologies you use to solve your business problems. For bigger companies, software is a no-brainer: modeling, logistics, invoicing, and many more areas are driven by information technology. For companies doing software in the first place, technology is at the very heart of the business: this is literally the foundation of everything. 

At the same time, there is no single business task with only one solution or vendor. Cloud providers, payment services, programming languages — there are always plenty of solutions. However, each choice is neither free nor safe: whatever you pick, you risk something. Going with managed services in the cloud means vendor-lock; using emerging technologies is subject to stability issues, and so on. Today, we are going to figure out how technology risk assessment works in companies of different scales.   

My name is Vladimir, I am a Senior Engineering Manager at Bolt leading Billing Teams in Commerce with a long track of software architecture and system design. I am ultimately accountable for technical decisions which my department makes. I have a relevant newsletter and a YouTube channel, so if you like the article, you can find more content there!

Defining Technology Risk Assessment

The common risk theory tells us that whatever choice we make brings risks with it. We can either accept, mitigate, or avoid the risk. However, in order to pick the risk-addressing strategy, we need to perform a risk assessment. This means listing the risks you see and understanding two characteristics of each one: likelihood and impact. 

Let’s say you pick up a database for a new project. One of the risks any database technology brings is the ability to scale beyond a point. The impact of such limitations will be staggering: you will need to pick a better option and migrate your data. The likelihood, on the other hand, is the probability you will have to do it at all, and it depends a lot on the business, data model, etc. 

Making this analysis results in mapping the risks on some risk matrix where you can pick up the appropriate actions. For example, you can try to avoid high risks (highly likely ones with high impact), accept the low risks (unlikely ones with low impact), and create mitigation strategies for moderate ones. 

Risk matrix

Good! Now, let’s see how companies of different sizes will approach the technology risk assessment. 

Risk Assessment in Startups and Small Companies

Early startups and small companies are characterized by limited budgets, smaller teams, and fewer resources. It typically means companies from single digits to a few dozen employees. 

Let’s look at a small startup in the compliance field: supplied.eu. Their goal is to provide Know-Your-Customer(KYC) and Know-Your-Business(KYB) services alongside Tax Reporting opportunities. Therefore, the key focus areas in the technology will be: 

• Rapid Adaptation: Need for agility and quick pivoting to remain competitive. 
• Vendor Lock-In: Risks associated with dependence on a single technology or vendor.
• Scalability Concerns: Ensuring that technology can grow with the company’s needs.
• Security: Balancing cost-effective security measures with the need for strong protection.
• Expertise: Having the necessary technical knowledge to use and develop solutions efficiently. 

The main aspects of core business are visual recognition and document parsing. Let’s try to make a technology risk assessment for the choice of technology. 

The options that we have as we need to extract information from the documents and recognize faces:

1. Build the software ourselves using some open-source components;
2. Find vendors for each component to support the required capabilities;
3. Find a single vendor for the whole stack. 

Building our own solution

To extract text from the documents, you need to have appropriate models, a pipeline to improve and deploy those models, and some infrastructure to feed the data into models for recognition. Thus, there are multiple risks associated with such an approach: 

1. High requirements for company staff and associated cost — remember the resource constraint.
2. Long time-to-market: a startup should be agile and quick to try the ideas fast and understand what sticks.
3. Reaching the goal in a reasonable time.

For the sake of simplicity of the article, I will claim those risks are both highly probable and highly impactful. It means that you may have to close the business once any of those risks materialize. 

Find individual vendors

So, imagine we went with individual vendors for text extraction capability and face detection and matching. For example, there is a Textract Service and Rekognition service at Amazon. Vendors like Abbyy offer that, and ChatGPT can read the documents, too. Let’s perform the risk assessment: 

1. The usage of a vendor will affect the cost of the service we provide.
2. The vendor can be inflexible to our product demands.
3. The vendor may be unreliable and unable to grant the required level of availability.

Those risks are of medium probability, and their impact is pretty significant as well: either the prices will go up, or the quality of our service will suffer. However, we can implement efficient mitigation strategies here to use several vendors at once, make the quick failover, and negotiate the prices. 

Find a single vendor for the whole stack

Relying on a single vendor brings its own risks, as well as the cost concerns and product demands. The biggest one is the vendor lock — if something goes really south, we are locked in with the company, and the transition will be painful and expensive. So again, it’s high impact but medium probability. 

Let’s bring all the risks into a table: 

Risk Factor	Build the Software In-House	Find Individual Vendors	Find a Single Vendor for the Whole Stack
Technical Expertise Required	High Requires significant expertise and technical staff, which may be costly and difficult for a small startup.	Medium Less in-house expertise required but needs skilled staff for integration and maintenance.	Low Minimal in-house expertise needed; vendor handles most technical aspects.
Time to Market	High Risk Development from scratch is time-consuming, potentially delaying product launch.	Medium Risk Integration of various vendors' services takes time but is faster than in-house development.	Low Risk Fastest option, as the vendor provides a ready-to-use solution.
Cost	High Risk Significant initial investment in development, infrastructure, and ongoing maintenance.	Medium Risk Service costs can add up, but initial costs are lower than in-house development.	High Risk Potentially high ongoing costs and limited negotiation power over pricing.
Flexibility/Adaptability	High Flexibility Complete control over the solution, but requires time and resources to make changes.	Medium Flexibility More flexible than a single vendor but can be limited by vendor APIs and SLAs.	Low Flexibility Dependent on a single vendor's roadmap and update cycles.
Vendor Lock-In	None No dependency on external vendors, full control over the tech stack.	Low to Medium Risk Limited vendor lock-in, as multiple vendors are used, but switching costs may still exist.	High Risk Significant lock-in with a single vendor, making switching difficult and costly.
Scalability	Medium Risk Scalability depends on the quality of the in-house solution and the team's ability to handle growth.	Medium Risk Scalability depends on vendors' ability to grow with your needs; multiple vendors might complicate this.	Low to Medium Risk Scalability is managed by the vendor, but you're limited by the vendor's capabilities.
Security	High Risk Security is entirely the company's responsibility, requiring significant investment in securing the solution.	Medium Risk Security partially managed by vendors, but in-house integration needs to ensure overall system security.	Medium Risk Security is largely managed by the vendor, but there's a risk if the vendor's security fails.
Reliability	Medium Risk Reliability depends on the quality of the in-house solution and the team's ability to maintain it.	Medium Risk Reliability depends on the reliability of multiple vendors; redundancy can mitigate risks.	Medium Risk Reliability depends on the single vendor's infrastructure; failure can have a significant impact.
Overall Risk Level	High Multiple high-impact risks with high probabilities make this the riskiest option.	Medium Balanced risk profile with some significant risks, but mitigation strategies exist.	Medium to High High impact due to vendor lock-in, but medium probability makes it a slightly safer option than in-house development.

As a result, we have three options. Two of them are in the High-Risk section of our risk assessment, so the decision here would be to pick several vendors for individual capabilities as it provides the most balanced approach.

Risk Assessment in Medium-sized Companies

The company grew and got some cash flow going. It now has more resources than startups, but still limited compared to large enterprises. At this point, technologies must support ongoing expansion and increased complexity. Therefore, the key focus areas will become:

• Integration Risk: Challenges in integrating new technologies with existing systems.
• Vendor Stability: Assessing the long-term viability of technology vendors.
• Regulatory Compliance: Ensuring new technologies meet industry standards and regulations.
• Data Security and Privacy: Stronger emphasis on protecting customer and business data.
• Talent Availability: Risks associated with the availability of skilled personnel for new technologies.

Now let’s pick Bolt, an Estonian-based ride-hailing company. It managed to successfully expand to 50+ countries mainly in Europe and Africa; however, growth should continue. Let’s consider the decision about the compute layer. Bolt used to run all the payloads as Node.js services on the EC2 VMs in AWS but faced scalability, observability, and cost issues. In order to improve the situation, the company can consider the following options: 

• Move payloads to serverless solutions, i.e. AWS Lambda;
• Move payloads to managed container orchestration solution like EKS/ECS;
• Migrate to self-managed Kubernetes cluster (EKS/OpenShift/etc).

Let’s consider the risks for each of those picks.

AWS Lambda

AWS Lambda is a serverless offering that allows you to deploy a code archive or a container, and AWS handles the rest. You have limited options to control the layer: the memory limit, timeouts, etc. The risks associated with Lambda are the following: 

• Cold Start Latency: AWS Lambda functions can experience cold start delays, especially for infrequently invoked functions or those using heavier runtimes. The increased latency can degrade user experience, particularly in time-sensitive applications.

• Limited Execution Time and Resource Allocation: Lambda imposes execution time limits (maximum 15 minutes) and memory/CPU resource constraints. It may not be suitable for long-running or resource-intensive tasks.
• Vendor Lock-In: Heavy reliance on AWS-specific services increases dependency on AWS and makes migration to another provider more complex. Reduced flexibility in the future if Bolt wishes to move to another cloud provider.
• Cost predictability: Costs can become unpredictable with Lambda, particularly with high volumes of invocations leading to Potential budget overruns if usage spikes.

Managed Container Orchestration (EKS/ECS)

All major clouds allow you to orchestrate containers with different offerings. Some of them are a fully managed Kubernetes environment, and some are simpler container managers like Elastic Container Service. However, the set of risks is similar:

• Management Complexity: Although managed, EKS/ECS still require considerable expertise to configure, manage, and optimize. Thus, you will have increased operational overhead and a potential learning curve for the development and SRE teams.
• Service Integration: Integrating existing services with a containerized environment may require significant refactoring, which increases development time and potential disruptions during migration.
• Resource Over-Provisioning: Inefficient container orchestration can lead to over-provisioning of resources, increasing costs.
• Availability and SLAs: While managed, EKS/ECS services are subject to AWS SLAs, which may not meet internal availability requirements.

Migrating to a Self-Managed Cluster (Kubernetes/OpenShift/etc.)

Risks:

• Operational Overhead: Self-managing a Kubernetes cluster involves significant complexity, including maintaining control plane components, networking, security, and upgrades, imposing a high operational burden and potential for human error.
• Security Management: Self-managing Kubernetes increases the responsibility for security patches, updates, and configuration management, which adds up to the probability of potential security vulnerabilities if patches or configurations are not managed correctly.
• Resource Allocation and Costs: Inefficient resource management can lead to over-provisioning or underutilization of resources.
• Disaster Recovery and High Availability: Ensuring high availability and a robust disaster recovery plan is more complex in a self-managed environment.
• Talent and Expertise Requirements: Managing a Kubernetes cluster requires a specialized skill set that may not currently exist within the team.

Conducting the risk analysis for these options, we can say that cold start latency, limited execution time, and vendor lock-in are both high risk and high probability, so, we eliminate this option, balancing out self-managed vs managed Kubernetes. This situation is pretty tough: the sets of risks are both medium severity and medium probability. If I were to make such a decision, I would say that security management, disaster recovery, and talent requirements have higher risks as well as higher impact, so I would go with EKS. However, in your company, you can assess the risks differently based on your situation, access to talent, and other factors. 

Conclusion

No technology is perfect, and each choice brings its own set of pros and cons alongside the associated risks. In order to make a calculated decision, you must conduct the risk assessment and estimate the impact and probability of each risk, weighing them all out. I wish you solid decisions!