Our process for tech assessments

profile picture

Stijn Co - CTO

16 Feb 2017  ·  8 min read

We share our learnings and current process on how to screen a customer's technical stack.

At November Five we have developed methodologies to build new digital products from the ground up. We’ve talked about our strategic teams in previous blog posts, but shortly put: during our Strategy Design phase, we dive deep into the validation of business ideas for new services or products.

After we’ve determined the strategic values and goals, our Experience Design team creates a first concept that matches those values.

At that point, we start a technical assessment with our customer’s technical staff. This is an especially important step when we’re working with some of our bigger clients, like telcos, utility providers and software companies.

This brings us to the why and how of technical assessment, which is what we’d like to share with you in this blog post!

Why we perform tech assessments

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

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

Before we go into detail, it’s important to refer back to our concept phase. During this phase, we aim to shape an image of the road ahead: a first concept of what a product could and should look and act like, somewhere in the near future. It’s something of a “dream” phase, where we pull our customers out of the constraints they usually work in. This gives them an idea of what can be achieved. We don’t promise the impossible, but we explicitly don’t tie ourselves to the constraints of today’s technology. We’ve found that this allows for maximum creativity and the best ideas.

It’s not until the technical assessment that we really go deep into the technical setup.

However, 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, completely swamping us with years and years of architecture, development and evolution. In the other scenario, the staff is (understandably) doubtful, even hesitant, to share their architecture with us – because this is the thing on which they have worked for months, years or even complete careers.

Our aim is not to challenge or criticise their work – usually, it’s the result of many technical and business decisions taken over time, and we’re not here to judge.

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.

Usually, not all services we need for our product will be present at the start of development. These services can be things like CRM packages, streaming services, or systems that need to be created from scratch. We 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. And, as with all good things, most of the time the best option will be somewhere in the middle, with both parties collaborating on the development.


A thorough technical assessment is a pretty complicated beast. Funnelling all this information in a coherent way is not an easy job! Truth be told, our first attempts were not that well-organised: information often flowed in at a fast pace, we got easily side-tracked, and often explored subjects that weren’t that relevant in hindsight.

Enter Simon Brown’s 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 the model is straightforward: start by laying out the system as if you were explaining your project to your grandmother over a family dinner.

Grandma, we built this thing that talks to these other cool things and does this awesome thing for our users.

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.

Context View

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 then recognises two more C levels, the components level and the class diagram. In most cases, these levels are only discussed when we’re in the actual development phase.

Deliverables and tooling

Like most of November Five’s processes, we prefer to keep this process lightweight and practical. The diagrams are built and maintained in LucidChart, while the information recorded in the conversation is stored in the product’s dedicated Confluence space.

We’ve also created a number of templates to use in these conversations. This ensures that our information (and the conversation in itself) is always structured and consistent across our projects.


In these templates we tackle a number of default topics:

  • SPOC
  • Overview
  • Connection test
  • Maintenance window
  • Roadmap
  • Notes
  • Attachments

The SPOC is our contact for the entire discussion, and remains so when we need more information during development or during support scenario’s.

The overview is a bulleted list of the products that are used, in which business processes they manifests, and how we connect, authenticate and authorise the system. It also clarifies which actors can actually talk to this system (authenticated and anonymous users, call center employees, back-office employees, bots or other services, …).

The next part defines our exact maintenance window. We want our products to be up at all times, but in reality, systems need maintenance and fully redundant systems are often just not cost-efficient. When we understand the maintenance windows of every system that our product depends on and know how we can detect the maintenance mode, we can avoid issues for our user – like for instance starting her registration flow when the SSO service is down.

Users don’t like to fill out information only to end up on a ”Whoops, something went wrong, please try registering again tomorrow ;-)” popup. In most cases, you’ve lost that lead.

Our template also contains a detailed roadmap. Systems change, are updated or replaced by other systems. We need to avoid building the product and then, a week before going live, discover that someone who isn’t aware of the project is wrapping up the migration of a key dependency. It’s essential to get ahead of such situations, and then keep track of these timelines after a project has launched as well.

The notes section is pretty self-explanatory: it bundles all the meeting notes of the conversation(s).

Finally, under attachments, we make sure to list all API documentation, Word documents, PDFs, Visio files, Powerpoints, etc. All available information about a system is consolidated in the last part of the template.

Who’s involved?

Logically, the two high-level diagrams can only be drawn up by a client’s CTO or Architect. However, these people tend to have very busy schedules! We’ve found that this process reduces the time that we need with the CTO’s or Architect: they can appoint the SPOCs within their company, and we can continue the discussion with them. This way, the workload can be shared across a larger team, and main stakeholders don’t end up becoming bottlenecks.

In short, this is the schedule we impose during the assessment:

  1. Architect / CTO creates the Context & Container View
  2. Architect / CTO appoints SPOCs
  3. SPOC defines the Container Views, during a 1,5 hour long interview
  4. November Five organises a presentation and alignment session (with all above) to validate our conclusions.

Signed, sealed, still improving

Of course, we’re constantly improving this workflow, and fine-tuning it as we take on new projects. However, we feel we’ve reached a solid basis to work from.

Would you like to be a part of these processes and work with us on large-scale projects? We’re looking for some fresh blood! Interested in helping out and learning a bunch? Take a look at our job openings….