Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Designing a Microservice Canvas From a Non-Dev Perspective

DZone's Guide to

Designing a Microservice Canvas From a Non-Dev Perspective

Take a look at an efficient approach to designing microservices architecture by taking on an agile, business-side perspective.

· Microservices Zone ·
Free Resource

Learn how modern cloud architectures use of microservices has many advantages and enables developers to deliver business software in a CI/CD way.

You Can Never Have Enough Canvas…

Every business analyst who has worked or works in digital projects has come across the term “microservices.” More and more businesses are implementing this way of working in their organization.

The need for the business analyst to understand this way of working has increased. One of the best ways to get your head around this architectural style is to get involved in designing the microservice with the development team. Before you can start designing the microservice, you need to understand both the "surface of the service" and "below the surface" element of the service.

Brief Overview

At the beginning, the microservices architectural style was pushed by developers and technical architects, who were keen to deliver software to the end users faster. However, taking this approach has resulted in developers who want to start coding without thinking about the design of their service or the wider architecture of the organization.

This is where the business analyst comes in- we are there to make sure that the microservice has been designed in a way that meets both the business and user's needs. Nevertheless, there is a desire to avoid using a tool that can hinder the development team and therefore reduce the benefit of utilizing microservice architecture.

What’s the Solution?

If you have worked in an Agile environment, you will be familiar with the concept of canvas - product canvas, UX Lean canvas, and so forth. Matt Mclarty has taken the concept of Lean UX canvas and applied it to microservice architecture.

One of the things that I love about using a canvas in Agile projects is the structure that it brings to the team, making it a perfect tool for designing the microservices in your team.

Screen Shot 2018-01-23 at 20.15.50

The canvas above is the one that was originally designed and labeled as "Microservice Canvas." Like with any Lean/design/Agile canvas, there is a logical flow that you have to follow in order to make sure that you are getting the most out of the tool.

Let’s Start

We have listed below the order you should follow, key questions to ask the team, and the aim of each of the box within the canvas. You will notice that we have slightly tweaked some of the titles within the canvas.

1. Service Name

Key question: What is the name of the service you are designing?

Everyone on the team should be clear on what the service is being called; confusion over the name of the service can cause issues further down the line.

2. Description

What: At a high level, describe the service - keep this user-focused.

Again, everyone in development should be clear, at a high level, on what the service is. If the team is unclear, use a tool like an Epic Value statement to get them the team back on track.

3. User Tasks

Key question: what are the key tasks the user needs to undertake that the service enables?

Being able to articulate what tasks the users need to carry out helps the team focus on what the design of the service should look like.

4a. Interface: Queries

Key question: which Queries under the microservice will be called?

These should be linked to the user tasks.

4b. Interface: Commands

Key question: which Commands under the microservice will be called?

These should be linked to the user tasks.

4c. Interface: Event Subscriptions

Key question: which Event Subscriptions under the microservice will be called?

These should be linked to the user tasks.

4d. Interface: Event Publications

Key question: which Event Publications under the microservice will be called?

These should be linked to the user tasks.

All the interactions that the user is anticipated to have with the service should be listed in the interface section of the canvas. By having all the interactions listed, it will help the development team to shape the underlying service implementation. You should not have any interactions that are not displayed on the canvas- if you do then the design of the canvas will be impacted.

5. Qualities

What: This is where you should document your non-functional requirements - performance, availability, and security.

This box may cause a debate between the development team and the product owner, who should be part of this conversation. By agreeing on this, the team will be able to decide the best approach to designing and implementing the microservice.

6. Logic/Rules

Key question: what are the business rules behind the service?

For the canvas, you don’t need to go into too much detail - you should provide enough details to allow the team to think about how they want to implement the service.

7. Data

Key question: what data is required for this service to operate?

For the canvas, you don’t need to go into too much detail - you should provide enough details to allow the team to think about how they want to implement the service.

8. Dependencies

Key question: what are the names of the external services that this microservice depends on?

This is a really important box for the team, so make sure that you don’t skim over this.

User-Friendly Version

While I like Simon’s canvas and have used it in many workshops, I prefer the James Higginbotham version. This canvas, seen below, is nicer to work with and I feel the order of the canvas is better suited to the teams I have worked with.

Screen Shot 2018-01-23 at 21.25.49

Your Role

You are not expected to know everything that goes into this canvas – that’s the job of the developers, tech architects, solution architects, and tech leads.

As business analysts, we should feel comfortable being part of the conversation with the technical team. I have found that the best way to do this is by facilitating a workshop/discussion – that way, you get involved in the conversation but are not expected to know everything. This canvas should give the team enough information to start the implementation of microservices.

The canvas will also allow you, the product owner, and the development team to write stories that will cover what the team needs to do in order to implement the service.

Things to Be Aware Of

I have listed some things that you will need to be aware of before you start creating the canvas – these are things I have learned from my own mistakes:

  • Don’t worry about getting it perfect: The document will evolve as the team finds out new information, so use it as more of a living document.
  • Keep it simple: Do not get bogged down with putting all the detail on the canvas; keep it simple and at a level that the team has just enough information to carry out the implementation of the service.
  • Right people: Make sure the right people attend the workshop; it should be development-heavy, but you still need the product owner in the meeting.

Try It!

So, next time you get involved in a team that is going to implement a microservice, ask them for this canvas. If they don’t have one, then facilitate a workshop to make sure that everyone on the team knows what the design and architecture of the service will look like.

Discover how to deploy pre-built sample microservices OR create simple microservices from scratch.

Topics:
microservices ,software architecture ,software development ,tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}