What is CRUD?
Hello there! Word of the day – CRUD Matrix. BABOK® v3 defines it as “a two-dimensional matrix showing which user roles have permission to access specific information entities, and to create new records in those entities, view the data in existing records, update or modify the data in existing records, or delete existing records. The same type of matrix can be used to show which processes, instead of users, have the create, read, update and delete rights.”.
Developing software systems that effectively manage information is a complex task that requires careful planning and consideration. One key aspect of communication and entity management is data operations, such as creating, reading, updating, and deleting data. These operations, commonly called CRUD, help with this task.
By implementing CRUD operations effectively, developers can ensure that users have access to the data they need while maintaining the integrity and security of the data. However, more than simply implementing CRUD operations is necessary. Business analysts often use the CRUD matrix or just the CRUD concept to identify and design all necessary operations in the system. If you choose the matrix, it provides a visual representation of the data entities in the system, along with the CRUD operations required for each entity.
Operations and examples
Before we dive into the details of the CRUD matrix, let’s first take a closer look at CRUD operations.
Create
Allows users to add new data to the system. They can do this through forms, data entry, API, or other means. For example, in a messaging app, users can send a message, which creates an instance of a “message” entity. Uploading videos to TikTok or making payments through the banking application are also examples of creating instances. Usually, creating is a quick action, but in some cases creating an instance of an entity may require going through multiple steps. The latter supposes either that previous steps saving in the cache with instance creation in the end, or creating the instance right away and setting “draft” status for it until finishing.
Read
Enables users to view or retrieve data from the system. You can perform this action mainly through browsing. For example, on an e-commerce website, you can view a list of products or view a product details page (view list and view instance are the most common examples). Tricky nuance: analysts sometimes consider search as a part of CRUD operation, which is not a common thing. Often, a search may be a very intricate feature. Thus, it is better to state search separately and explicitly.
Update
Allows users to modify existing data in the system. This can be done through various editing tools. You can edit your profile information, and instance metadata, change the content of a blog post after publishing, add attendees to existing meetings, etc.
Delete
Helps users to remove data from the system. For instance, you can delete tasks from your task management app, or delete users from the system. Tricky nuance: deleting content from the published blog post is editing. That is because you are not deleting an instance completely, you redact its part keeping the whole. Also, the “delete” feature has a confirmation dialog or “undo” subfeature. In some cases, “delete” does not remove instances from the system, but sets “deleted” status.
Creating CRUD matrix
Designing an effective CRUD matrix requires careful consideration of several factors. One of the critical aspects is understanding the information entities in the system and the CRUD operations that each entity requires. Business analysts can work with stakeholders and subject matter experts to identify these entities and operations.
Once you have identified the entities and operations, you can start designing the matrix. The matrix should indicate which user roles or processes have permission to create, read, update, or delete data in each entity. You can use different colors or shading to highlight the permissions of each role or process.
When designing the matrix, it’s essential to keep it simple and easy to understand. Use clear and concise language to describe the entities and operations, and avoid using technical jargon that stakeholders may need help understanding. You can also use diagrams or other visual aids to supplement the matrix and make it more accessible.
Now, let’s review different representations of the CRUD matrix.
Role-Operation
In this case, you can quickly get a list of entities for each role. This convenience has a considerable disadvantage, as you have to duplicate each entity multiple times. You can somewhat negate it by including other roles same operation permissions. Overall, this is a less usable option, as you can get a list of features for each role by other means;
| Role / Operation | Create | Read | Update | Delete |
|---|---|---|---|---|
| Guest | – | Categories Products Static pages Subscription (description) | – | – |
| Manager | Product Subscription (payment) | Guest role Product Subscription (seats) | Product Subscription (cancel) | Product |
| Admin | Manager role Categories Users | Manager role Subscription (payment) Categories Users | Manager role Categories Users Subscription (seats) | Manager role Categories Users |
Role-Entity
This option shows operations on the entity available for a specific role. It is much more convenient as it provides a glance at the permission situations for each role. I would say that its disadvantage would be the fact that you need to transform letters into words to understand the content mentally;
| Role / Entity | Category | Product | Subscription | User |
|---|---|---|---|---|
| Guest | R | R | R (description) | – |
| Manager | R | CRUD | C (payment) R (seats) U (cancel) | – |
| Admin | CRUD | CRUD | CR U (seats) | CRUD |
Entity-Operation
Readers can use this one to understand who can access which entity quickly. Same as the Role-Operation, it’s bulky and requires additional thinking resources to process.
| Entity / Operation | Create | Read | Update | Delete |
|---|---|---|---|---|
| Category | Admin | Guest Manager Admin | Admin | Admin |
| Product | Manager Admin | Guest Manager Admin | Manager Admin | Manager Admin |
| Subscription | Manager | Guest Manager Admin | Manager Admin | – |
More complex implementations
Previous examples are great when we are talking about matrices that you use more in the preliminary phases to understand the domain and context. Moving to the implementation phase, usually, they do not work as you have to deal with a lot of information, meaning that you have to get rid of the disadvantages of the selected approach. A solution would be to select and approach and then group, for example by an entity, in a single table:
Product
| Role / Operation | Create | Read | Update | Delete |
|---|---|---|---|---|
| Guest | + | |||
| Manager | + | + | + | + |
| Admin | + | + | + | + |
Subscription
| Role / Operation | Create | Read | Update | Delete |
|---|---|---|---|---|
| Guest | + | |||
| Manager | + | + | + | |
| Admin | + | + |
Another example. Some systems provide access to features on a deeper level, providing operations availability for specific fields or features. In this case, business analysts can use any approach to create something like this:
| Field / Operation | Create | Read | Update | Delete |
|---|---|---|---|---|
| id | + | |||
| name | + | + | ||
| social_security_number | + | + | ||
| age | + | + | + | |
| tag | + | + | + | + |
As you may see, there is no role presented here and it’s impossible to understand who may perform specified actions. Or even what entity is this? In this case business analysts have to introduce groupings by entity and role.
Is that your first visit to Passionate BA?
If you have just started reading my blog, I must indicate that you can find many other helpful materials on a blog page. You will find my business analysis digest, my articles, and more! Enjoy!
Image by vectorjuice on Freepik