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 ways of working 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 microservices architectural style was pushed by developers and technical architects, who were keen to deliver faster software to the end users. However, by taking this approach it has resulted in developers who want to start coding straight 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 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. Simon Brown (http://simonbrown.je) has taken the concept of Lean UX canvas and has applied it to Microservice architecture.
One of the things that I love about using canvas in Agile projects is the structure that they bring to the team and this is a perfect tool for designing the microservices in your team.
The canvas above is the one that Simon Brown originally designed and labelled 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 best out of the tool.
Let’s start
We have listed below the order you should follow, key question/s to ask the team and what is the aim behind 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 that your designing
All of the team should be clear in what the service is being called, by having 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 focus
Again, everyone in the development should be clear at the high level what the service is. If the team is unclear use a tool like Epic Value statement to get them the team back on track.
3. User tasks
Key question: what are the key tasks that the user needs to undertakes that the service enables
By being able to articulate what tasks the users need to carry out helps the team to 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, security.
This box may cause a debate between the development team and the product owner should be part of this conversation. By agreeing this the team will be able to decide the best approach for 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 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 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 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 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 that I have worked with.
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 technical team 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 microservice.
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
Before you start creating the canvas, I have listed some things that you will need to be aware of before you start — these are things I have learnt from my own mistakes:
- Don’t worry about getting it perfect- the document will evolve as the team find 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 have 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 workshop to make sure that everyone in the team knows what the design and architecture of the service will look like.
If you have any feedback please let me know via twitter @rohelaraouf
