When you work on projects with bigger clients, like telcos, utility providers and software companies, it’s crucial to know all about their technical stack before you dive into development. After all, you don’t want to run into mysterious problems or unexpected dependencies later…

In this post, we’ll walk you through our process for these technology or architecture assessments and the many benefits of doing it right!

The goals of tech assessments

‍

When performing tech assessments, we always have two main goals:

• performing a reality check on the proposed product;
• identifying any missing components or services that we need to build our solution.

‍

Your mileage may very, but at November Five, this is a more-than-crucial step. When we create our long-term product vision, we explicitly don’t tie ourselves to the constraints of today’s technology. We don’t promise the impossible, of course, but we’ve found that this allows for maximum creativity and the best ideas.

‍

However, this does mean that it’s not until the technical assessment that we really go deep into the technical setup, making all the more essential to do this right.

‍

Now, experience has taught us that diving into a client’s technical architecture can be tricky. Two things can happen: ideally, the technical staff is completely on board and shares a tremendous amount of information with us – years and years of architecture, development and evolution. In the other scenario, the staff is (understandably) doubtful to share their architecture with us – because this is the thing on which they have worked for months, years or even complete careers.

‍

It’s important to assure everyone that we’re not there to challenge or criticise their work. However, this architecture will be the foundation of our product, and as such, we need to examine it.

The better we understand the ecosystem that we’ll be extending, the better the product will become.

When it comes to the actual learnings, we focus on the status of the services we need for our product, like CRM packages, streaming services, or completely new systems. They won’t usually all be present at the start of development and sometimes need to be created from scratch. A first step is to determine whether these missing parts should be acquired, customised, or developed by November Five or our client.

These decisions are mostly driven by operational responsibility.

• If the new service needs to iterate with process changes managed by the client, the most logical choice is to have our client develop and maintain the service. That will make changes much easier to plan and implement.
• If the service will change together with our product, it makes more sense for us to take charge of development.

Most of the time the best option will be somewhere in the middle, with both parties collaborating on the development.

How do you organise a technical assessment? 

‍

A thorough technical assessment is a pretty complicated beast. Gathering information is one thing, but representing it in a way that makes sense can be complicated. And truth be told, our first attempts were not always that well-organised, which is why we were looking for a better way.

Enter Simon Brown’s extremely useful C4 model. His view on creating several zoom levels of architecture resonated in the team and guided our conversations about a better methodology.

The basic premise of his model for architecture visualisations is straightforward: start by laying out the system as if you were explaining your project to your grandmother over a family dinner.

This gives you your Context View: in one fell swoop, you have now defined which parts you own and which you don’t. You quickly define which actors can work on or use your system.

‍

This can already be a pretty big challenge, if your day-to-day job is managing dozens of these interconnected services.

Next you zoom in on the central node. This is what Simon refers to as the Container View. These are course grained subsystems like the CMS, frontend/native applications, billing systems, backoffice systems, CRM systems, etc.

‍

When you’re creating this diagram, it is important to know how information flows through the system. To help our clients help us, we ask them to think about the customer lifecycle. The way each of the actors travels through his or her lifecycle will define the order in which we start drawing and annotating arrows.

We’ve found that with this approach, we get 80% of the system’s use cases properly described – which is what really matters in the initial assessment.

The edge cases and exotic use cases can be defined and evaluated properly at a later stage.

‍

Simon Brown’s model recognises two more C levels, the components level and the class diagram, but usually, those are only discussed once we’re in the actual development phase.