Finding the stakeholders

Any technology decision revolves around having the right stakeholders, who represent different perspectives on the decision:

• The individuals using the technology
• The individuals managing the technology (from a maintenance and compliance perspective)
• The individuals paying for the technology

Sometimes these are different people, sometimes (luckily or not) they are the same person.

Each stakeholder has requirements, which usually fall into one of three categories:

• Non-negotiable requirements — These are truly “we can’t use it if it doesn’t have X”, like it must be HIPAA compliant for us to use in healthcare.
• Painful, but doable, if not available — A great example of this are integration points. Say a technology can write notifications to AWS SNS, but not to Slack. Well, you could build a SNS to Slack integration, but that’s more work and code ownership than you were looking for.
• Manageable if not available — A good example is search; if I can’t use Ctrl + F to find something, maybe I can just copy and paste the page into a text editor and search it there.

Putting these all into a spreadsheet helps everyone see and validate the various requirements across the stakeholders.

Build vs. Buy and run vs. Buy SaaS

To continue the theme of threes (threeme?), there are typically three paths one could take

• Build it yourself (pure development)
• Buy and run it yourself
• Buy it and have them (the vendor) run it for you (SaaS)

To guide you down the right path, you can ask yourself the following questions:

On the scale of 1–5 (1 being the most basic), how novel is this problem?

Consider that things like authentication, databases, and programming languages typically fall in the basic bucket while things like specific business domain problems (e.g. 911 call routing, industrial automation, etc) fall in the very novel bucket. A good example of a fairly novel use case is scheduling — many options but never feels like a complete solution. Consider also how much your needs vary from what exists in the marketplace. A higher score implies that build is a good option

On the scale of 1–5 (1 being no prior knowledge), how much experience do you have in this problem space?

Some problem spaces are common across businesses (e.g. permissions) while others are very niche (e.g. device control systems in an industrial setting). A lower score here implies that build is not a good option.

On the scale of 1–5 (1 being no support), how much bandwidth do you have to support a commercially off the shelf (COTS) technology?

This includes both having the platform to run the software as well as having a dedicated team to run, patch, and monitor the software. A higher score implies “Buy and Run” is a better choice over “Buy via SaaS”.

On the scale of 1–5 (1 being not pressing), how soon do you need this live?

Building a product from scratch takes time but buying something off the shelf can accelerate your delivery time. A higher score implies buy (either hosted or as SaaS) are better options.

On the scale of 1–5 (1 being not painful at all), how hard would it be to switch to a different solution?

Because the future is unknown, there’s the possibility that the choice we make today is not the right fit next week, next month, or next year. A higher score implies that the “stickiness” of the solution (whether a SaaS or Buy and Run) might prevent you from pivoting in the future.

Case Study — Picking an identity provider

Recently Zus went through the process of selecting an identity provider for our services. Using this framework, we came up with the following requirements:

Given these requirements, we needed to understand what options were available to us. There currently are many SaaS offerings around identity management (Auth0, Okta, SailPoint, Cognito, etc), as well as self-hosted options (Keycloak). We could also build our own OAuth2 implementation. This led us to ask questions to guide us around Build vs. Buy and Run vs. Buy SaaS:

This left us with the Buy via SaaS, which felt right to us. While we were concerned with vendor lock-in, it was not as concerning as not being able to go to market with a quality product. The actual vendor selection process became fairly straightforward, focusing around the vendor’s ability to meet our critical requirements as well as being manageable from a cost perspective. We landed on Auth0 as it allowed us to manage almost everything via APIs and met our cost needs.

Conclusion

As a developer, I always want to be building, particularly when I don’t know how everything works under the hood of a program. While admirable, sometimes reinventing the wheel is not the fastest way to market.

Understanding what you need, what you can afford (both in terms of time, money, and personnel), and when you need it are critical drivers to understanding how to pick the right technology at this moment. Obviously technology is ever-changing (another JS framework, another NoSQL solution but with SQL, etc). While a product might be able to do it a bit better than your current selection, never lose sight of the reason for the technology choice: to go to market with a better product.