How I use Whiteboard to design the Assets database

[#1]

The problem

Setting up an Assets database for success from the beginning is crucial. Being able to predict the fields, cardinality, schemas, permissions and even automations that you are going to use in the final implementation will be greatly improved by designing the solution before you start implementing.

This article is mostly aimed at my consulting colleagues who are often setting up new environments for our clients, where it is normal to start from scratch, but this could also be useful for SQL database devs or even workflow designers.

What might be useful

Being familiar with UML is, in general, great for those looking to design new databases.

Power users who want to learn how this standard works can look at this excellent article (outside the community site)

I use a simplified version of it myself, so no need to go through the entire thing to understand my process. Here is how it goes:

•  Object types are boxes. I like to use "Rectangles" colored in yellow. Write the name of the Object Type in bold and list the attributes as a bullet list. Notice how I write the attribute type by the name. As a general recommendation, let the first attribute be the object type label. Also, if you reference another object, use the object type name as the attribute type.

• Whenever your objects are related, create arrows between them: The rule goes as follows: The object that contains the related object has an arrow outgoing towards the referenced object.
• Use the relation to specify the cardinality. For example, my Main Product can have any number  (N) of sub-products, yet the Sub-Product may only be referenced by one Product at a time (1)
• Avoid crossed relations. You might be tempted to keep in a subordinate entity the exact objects it is subordinate to. This is not necessary, as you can use the relationships between objects both inwards and outwards. 
• Use sections to design your schemes. This is really comfortable as you can refit your section as you design the system without the need to redo all your work. Name the section the way your schemes will be named in the future.
• Your Assets live in Jira, make sure to account for it. I like to color code my sticky notes with Automations, in blue, triggers in green, decitions made during the design in purple and others as they come up.
• Asynchronous work is the best, so leave comments. The best thing about comments in Whiteboards is that they are positional, so leave your comment close to the most relevant subject. This will also help when your colleagues look at your documentation! Always document as if you are going on leave tomorrow.

A real example

Recently I designed toguether with a colleague and a client a small database whose aim was:

1. Keeping track of how many clients the company had
2. Keeping track of the Products this customers had purchased
3. Keeping a catalogue of Products and their modules.
4. Cataloguing all their hosting, key stakeholders, support groups, etc for an ITSM service
5. Automating assignments according to which customer opened tickets in JSM, as the routing could depend on which products they had purchased.

I might write another article outlining my best practices on designing Assets databases. This time around, let's just see the final diagram without zooming in. (Don't worry, I made sure to ask for permission before reposting this)

I hope this was useful. If anyone reading this has any extra tips and tricks for using Whiteboards, designing relational databases, or best practices, make sure to share with the community!

[Dave Mathijs]

@Jaime Escribano Thank you for sharing your insights, interesting article.

Why would you prefer Confluence Whiteboards over third-party diagramming apps like Drawio or Gliffy for example?

[Jaime Escribano]

Thanks for the reply, @Dave Mathijs

I honestly don't have that much experience with other third-party tools, though I've heard great things of Draw.io and Miro.

The good thing about Whiteboards is that you can use it even with standard Confluence instance, export as pdf or take screenshots and delete them for later use.

I'd use Whiteboards by default, though I wouldn't say no to trying out these other solutions should my clients make use of them! My methodology should work with them no problem ;D

Maybe other readers have experience with both tools and be able to make a comment on which they prefer.

Regards,

Jaime

[Francesc Arbó]

I've read the begining and I'll save it to read it deeply later. Thanks for sharing your knowledge.

[James Rickards _SN_]

This is a nice example of how the forced simplicity of Whiteboards removes much of the "techno babble" from diagrams making them easier for staff who are not classically trained on UML to come to grips with the concepts without being overwhelmed by needing to know the minute details about each style of crows-foot arrow.  At the end of the day these tools are to help people work out what to do, and how to do it.

I've seen people waste days on formatting in tools like draw.io, Miro, PowerPoint, Visio, Lucid, when at the end of the day something simple is all that's needed to get a concept from one person's head into another's, to allow them to take action.

[HIROTA Takayuki_Ricksoft_]

Great suggestion! I like the idea of using the text of a relation as a cardinality. I think cardinality is very important for class diagrams.

[Jaime Escribano]

@James Rickards _SN_ glad you like it :D

This has indeed worked well for me in the past. The method was developed while designing the system with clients who might not be technical, as you say.

One improvement that I've been thinking about is including what type of relationship the objects will have between them, as naming relationships is real usefull when configuring Assets custom fields in Jira.

Maybe the community can offer some ideas on how to do this elegantly.