In this instalment of our #Zone5Principles blog series, Zone’s head of engineering, Paul Kiernan, discusses picking the right tools for the job when developing digital products or services.
Being able to deliver a quality experience at speed isn’t just about building a lean feature backlog, it also involves making the right technology choices that deliver the backlog and enable an iterative agile methodology allowing the platform you’re developing to evolve and change.
During the development lifecycle, there are lots of technology choices that need to be made, all the way from the big macro decisions on the hosting platforms, system choices and architecture approaches, down to micro-decisions on specific frameworks, tooling and deployment processes.
Working for a consultancy like Zone, we are practised at adapting/tailoring our approaches for a myriad of client needs and existing technology ecosystems. Taking a “technology agnostic” position helps us to assess the existing client’s ecosystems and recommend the right tools that best fit the needs of the business and user.
It’s worth acknowledging that “technology agnostic” is quite a big claim as the technology industry is vast and ever-changing. Technology agnostic also only goes so deep — an agnostic approach is great at a strategy layer, but when it comes to implementation specialist knowledge should be used.
I have asked myself over the years, how can someone really be agnostic of all technology, even at the strategy layer, but still know enough? The following are a few key factors that steer our approach and can help in many other environments when making technology selections.
- Gathering data to make the decision
- Focusing on the user experience
- Checking your technology bias
- Leveraging existing systems and platforms to enable speed
- Building or buying
- Creating an architecture that can evolve over time
- Empowering the team with a solution and platform they control end-to-end
- Differing solutions until the right time
In addition to the above, it’s important to remember that making technology choices is affected by many factors and each choice will be different for each situation. If you are working internally at an existing product house your choices will be different from a new start-up with a greenfield build. Decision factors can include current specialist skillsets, existing technologies constraints, current IT strategy or previously defined architecture principles, etc.
Wherever you work, keeping an architectural decision record (ADR) will help you rationalise decisions in the moment and serve as a reminder in the future if there is a “why did we do that?” moment. ADRs are often quite simple and detail background/context, the problem you were trying to solve, critical user journeys, the solution options, the final decision with reasons and the people that were involved.
Gather Data
Seek out qualitative and quantitative data to help support future technology decisions and prioritisation.
At a minimum, we need to understand the broad functional and non-functional requirements of the system before we can design the correct solution. Also, seek out security requirements and volume metrics on the number of users the application needs to support, the traffic patterns (spikes vs extended load), the volume of information and the shape of data.
Speak to people and understand what they have done in the past, and why it should/shouldn’t affect future projects.
The more information you have the better, but seeking out all/every piece of information can delay projects and may not be required. Try to strike a balance to allow you to move forward with confidence, but without creating delays.
Focus on the user experience
Thanks to the likes of Amazon or Netflix, we now all expect a slick, streamlined and responsive user experience from most of the services we interact with, regardless of how mature they are. Although an MVP is not going to be anywhere near as slick an experience as from these massive companies (they’ve had years iterating on them), picking the technologies and frameworks that are built to create slick experiences can help get the basics right.
For example, if you have an interaction rich and data-heavy site, using frameworks such as reactjs to build the UI will help, or hosting the application on a platform built to deliver application files at speed and the scale required can help to keep users engaged and flowing through your user journeys.
Picking the wrong technologies can lead to an experience that lacks quality, with slow pages and ultimately increasing user drop-off.
Over the past few years, we’ve seen a transition to “headless” architectures (decoupling presentation layers from systems that master content/data/logic), whether that’s a headless CMS, headless e-commerce or something else. One reason for this trend is to allow the user interface to be built in the technologies that deliver the best experience for the user’s needs and to allow the technologies to be enhanced as advancements are made in the industry. The other side of the architecture can then concentrate on whatever it does best e.g. managing content, products, inventory levels, etc.
Check your technology bias
Technologists may have a preferred stack but when looking at new problem spaces, it’s best to take an unbiased view towards the overall solution. Exploring existing stacks or competing tools with an open analytical mind, assessing their benefits and making evidence-based recommendations. Simple decision approaches such as listing the pros/cons of solutions or decision matrices can help rationalise decisions and help create alignment in teams.
The best solution architects/technology directors I know have come from a practitioner background either as developers or testers. These people have expertise in certain technologies or platforms but are able to extrapolate common practices/patterns from their core technology expertise. They apply those patterns/practises at a high level to understand other technologies, languages or platforms.
To move at speed taking a technology-agnostic approach only goes so deep. Once tools have been picked it’s often best to bring in specialists to perform final assessments and implement. This approach will help to avoid common issues and pitfalls.
At Zone we are specialists in most core experience-focused technologies and, being part of Cognizant, we have literally thousands of engineers that we can call on to help implement any specialist technology. If you don’t have such a support network, bringing in a core set of consultants to help build internal capabilities will help.
Leverage existing systems and platforms to create speed
When we are looking to pick the right tool for the job, we need to have already understood the existing ecosystem the solution is designed within. If that ecosystem already has tools that support the outcomes we require then don’t be afraid to leverage them.
For example, if you need to send a simple email to end-users and a company already has a method to do this, analyse the tool to make sure it fits your requirements and plug it in. The time it takes to select a new tool and get through a procurement process can be substantial and if you’re delivering a lean MVP you need to just get it working for now.
This might sound simple and obvious but focusing on outcomes and leveraging existing tools can be overlooked in the excitement of building shiny new systems.
Build vs Buy (OTS)
You only have to google “build vs buy” to find a plethora of articles describing the factors and processes to follow when deciding when to build or to buy a solution. Therefore, I won’t go into this here. Some obvious solutions for buy over build are content management or customer relationship systems. There are a huge amount of commercial and open-source CMSs and CRMs that solve common challenges already, they are highly configurable and fit 99.9% of everyone’s needs.
So what else is there left to say? I’d like to reinforce that just because you bought something it doesn’t mean you need to use it to solve all your problems, and it definitely shouldn’t be twisted to do something it’s not built for.
Think about it like a hammer, just because your hammer is great at getting all different sorts of nails into the wall doesn’t mean it’s good for getting a screw into a wall or checking the level of a table. I’ve seen people use systems as they weren’t intended for or aren’t specialised in ending up in a Frankenstein type solution.
To get the most out of SaaS/COTs you need to adapt your business processes or experience design to how they work. Lots of the big software platforms also have add-ons for all sorts of things, these can be great at getting a generic experience up quickly and cheaply.
However, if you want a high-quality experience tailored to your business or customer needs, then you’re probably looking at a “build” situation. This will allow you to create an experience that fits the needs of the user and leverage tools that are specialists at building such an experience.
Often building a tailored experience can lead to bespoke solutions in technologies such as reactjs, nextjs and JAMStack type architectures. Sometimes utilising the APIs of your off-the-shelf (OTS) platform as the core data or business logic layer.
In the end, making the right choices will enable speed and deliver a quality of experience for the target user.
Create an architecture that can evolve
This is often one of the most challenging parts of designing a technology solution. Not only do you want to cater for the immediate requirements, but you also need to keep an eye on future requirements so that you don’t design yourself in a corner. At the same time, you don’t want to build for the future because it will reduce your speed to market and the future can and probably will change… tricky!
There is no easy answer here and I’ve concluded that this is often just hard, you will learn by trial and error, but will never stop learning.
The following are a few core principles we use:
- Keep it simple — 99% of the time a system will only grow in complexity. Keeping it simple as possible at every stage will help reduce that complexity and hopefully mean the team can move at speed. As with everything, there is always a balance to strike. If you’re faced with a decision, try and pick the simplest option and the one that allows for future flexibility without adding considerable complexity or effort. This isn’t easy, and I’ve definitely not always got it right. Martin Fowler discusses techniques such as YAGNI and others on his blog https://martinfowler.com/bliki/Yagni.html which is worth a read. Whatever decision is made keeping an ADR will help make the process quick and somewhat objective.
- Keep it modular and componentised — Having your application (software and infrastructure) separated into components or modules with specific responsibilities and defined interfaces, will allow you to swap, change, scale or add modules as required. For example, if you have a component in your architecture which is intended to handle identity and access management, keep all authentication and authorisation information in that component and don’t pepper it around the architecture.
- Be cloud-native where possible — When saying “cloud-native” I’m not referring to microservices or containerisation, I simply mean embrace the cloud and design your applications to leverage the scale and services it offers. In the past, a lot of time was taken up provisioning servers, firewalls, load balances, database clusters etc. Thanks to cloud-native we have services that offer us the same features without the headache of provisioning and managing the infrastructure. For example, if we’re in Azure and we want a MongoDB, using something like MongoDB atlas we can have a database set up in minutes, all provisioned and managed for us. If we need this instance to scale, we can simply pay a bit more money.
Empower the team
Whatever tools you use, pick ones that empower the team and decouple them from dependencies outside their sphere of control. This generally means allowing the team who are building the product or service to self-serve whatever they need e.g. provisioning hosting components, access to sandbox environments, giving control to deploy or access to logs and telemetry.
The tools chosen need to allow the team to own the platform “end to end”. That includes both cutting through the architecture stack from front to back and giving the team the power to deploy from dev to test and higher environments. This is where good DevOps practices and tools come in, doing it right will allow a team to move at optimum velocity enabling more time to focus on quality and value. Doing it wrong will cause the team to be blocked, impeded, or in some cases, cause the team to grind to a halt.
Defer solutioning until the last responsible moment
It’s very tempting to jump to a solution design as soon as you’ve heard the high-level requirements, that’s natural and as technologists, we’re often keen to flex our creative muscles.
It’s common to sketch solution ideas during the very early stages of a project which is fine and it helps articulate current views, knowns and unknowns. Treating early solutions as a “hypothesis” can help the team to defer making a final decision until the time is right and they’ve been able to perform technical proofs-of-concept, run spikes, and gather more data.
We often say the decision needs to be made at “the last responsible moment”, a common term in agile and is the instant in which the cost of the delay of a decision surpasses the benefit of delay; or the moment when failing to make a decision eliminates an important alternative.
Conclusion…
Picking the right technologies can not only allow your team to create exceptional experiences, but they can help them do that at speed ultimately delivering value faster.
Technology is complex, there is a lot to consider and there isn’t always a best fit solution. The themes discussed will help guide decision making but there is also a lot of other factors involved. In summary…
- Gather data to make the decision
- Focus on the user experience
- Check your technology bias to help design the best solution
- Leverage existing systems and platforms to enable speed
- Consider building or buying where appropriate
- Create an architecture that can evolve over time
- Empower the team with a solution and platform they control end-to-end to give them maximum control of their processes
- Differ solutions until the right time to make decisions with as much information as possible
In the next article, we’ll look at the important process of continuously managing scope throughout the project delivery, something often not done well, but also something that can make or break an MVP delivery.
Notes:
This article is part of an overarching series aimed at people who develop digital products or services, either in-house or agency side, and have been frustrated by missed deadlines, poor output quality or the overall experience not delivering the value you hoped for.
The information discussed isn’t new or groundbreaking; however, it is generally talked about separately and in silo. These articles will provide a holistic and balanced view of the key focus areas to help teams move quickly while still delivering value.
It’s an iterative process to get all these practices and processes in place, so start small, experiment, persist with what works and take the learnings from what fails.
For a full introduction to the series please read the series introduction article.
Principle One: Look at the big picture, but don’t get lost in it
Principle Two: Create a true MVP (Part One)
Principle Two: Create a true MVP (Part Two)
