Technology Stacks and Platforms


How do you take your burger? Beef, cheese, bacon, tomato? …or maybe vegetable protein, vegan cheese, egg-free mayo? Perhaps you don’t like burgers at all. Maybe you prefer a toastie? Any of these sandwiches could satisfy your hunger, so how would you choose which one to eat? It’s likely your choice of sandwich would be influenced by a number of factors like your flavour preferences, the weather, time of day. What if you had to share it with others? Would that impact your decision?

A technology stack is often compared to a burger or sandwich. It is simply a list of all the software, tools, programming languages and platforms that are layered together to serve a function. Can you define the technology stacks and platforms your organization uses? If you want to make a sandwich for anyone else, or train others to do the same, then at a minimum you need to know what ingredients are available.


Traditionally, when looking at technology stack models, it has been common to separate front end and back end. In this model front end refers to the tools and languages used to create a user interface, and back end refers to the tools, languages, and platforms used to perform the transactions and work behind the scenes.

A better, modern approach to model your technology stack that is also transformation friendly is to consider it in the below terms.

  • User Experience
    • The human centric presentation layer, including the layers that directly impact the user experience. e.g. website, app, or user interface.
  • Solution stack
    • The tools and programming languages that provide the logic required to provide the service offered via the user experience layer. e.g. JavaScript, java, php, ruby, perl.
  • Platform
    • The server or serverless platforms that provide the runtime environment needed for the solution stack. e.g. physical servers, virtual servers, operating systems, cloud based runtime environments, containers, API gateways.

In reality there are no strict boundaries between these layers and each reaches into the other, however adopting this model when examining your technology stack can be a valuable tool to enhance your responsiveness and expedite your decision making.

Each of these layers is important, however the most important of these to get right when considering organizational responsiveness and transformation activities is platform.

Platform can be expensive. The wrong choice of platform will come with a high risk of your organization accumulating unnecessary technological debt. The right choice of platform will increase your ability to respond to disruption.

Finally, we need to mention XaaS. Anything/everything as a Service. If you are using mature XaaS offerings then you can let someone else worry about the details of technology stacks.

insights & further reading

Popular tech stacks used by major tech companies can be easily found online 1


Perform an inventory of the technology stacks used in your organization. Your transformation team should ensure the completeness of this data while exploring opportunities for small change.

In particular, take note of technology stacks that use a traditional platform layer that includes servers or virtual machines, and operating systems. Examine these carefully to understand if the workloads they run are candidates for conversion to XaaS offerings, cloud based containers or serverless computing. Generally speaking, adopting one of these platform models offers you the most flexibility and the least risk.

Pay special attention to opportunities for adopting XaaS for highly specialized functions where mature offerings exist.

Look at your technology strategy. If you have followed earlier topics in this framework, then you know it’s principles should define what platforms to use for delivering technology. Revisit it now, and ensure that containers and serverless platforms are included and recommended for workloads that align well.

Look for disparate tools and programming languages in the user experience and solution stack layers across your organization. Consider further programmes to align them.

Avoid vendor tie-in by selecting commonly used, open source runtimes, and widely used programming languages.

methods & tools

Contact us to discuss your requirements and access this practical content and further in depth analysis.