🔠 E - Blueprint the BRYTER Application

How to create a blueprint for your use case

Applications like an HR Absence Tool or a Client Due Diligence (CDD) Assistant require several modules and require case databases to be set up. They also cater to several different stakeholders. In the HR Absence Tool, both employees and their line managers use different modules to raise vacation requests which are subsequently approved or rejected while all inputs and decisions are stored in a case database. Similarly, a Client Due Diligence Assistant could be used by a General Counsel (GC), the Due Diligence team, and a business user or assistant who starts with an initial assessment of a potential client.

To illustrate the required components of this Application, we suggest using the following symbols and creating a high-level process map that displays the case databases, modules, and the stakeholders using them in a swimlane diagram:

Symbol or shape	Type or name	How and when to use
	BRYTER Module	This symbol represents a standalone BRYTER module. This module can be connected to another module or generates or reads gathered information out of a database or
	BRYTER Case database	This symbol represents a BRYTER case database.
	BRYTER Data views	This symbol represents a BRYTER data view that is derived from a case database.

In the CDD example, the business user or assistant uses a first module that helps to understand which type of CDD check is required for client XYZ. Based on this initial result, the case for client XYZ is either

1. completed (simplified CDD check sufficient)
2. prompts the business user to an enhanced CDD check in a separate module
3. escalates the case to the Legal team if an escalated CDD check is necessary
4. informs the General Counsel if any Red Flags have been detected and escalates the case to the GC for further assessment in a separate module.

While all these modules and the steps required are completed, the gathered data flows into two separate case databases:

1. one case database is used to gather all cases and contained data can be updated by all stakeholders
2. one case database only contains red flag cases and can only be updated by the General Counsel

The starting point thus differs across the stakeholders but generally starts with the business user starting the first module and CDD check for a new case. It ends with either the result of the first assessment, the escalated check, and guidance or the red flag report.

The steps and modules above could be depicted as follows - including some additional data views so GCs and the Legal Team can easily keep track of all cases - in a very high-level process map. The black arrows are used to explain how different modules are connected whereas the blue arrows indicate the direction that information or values are flowing into or from case databases:

Best practices

💡 Before sketching your blueprint, ensure that you know where the process starts and ends (and have ideally created a detailed process map). How (and by whom) is the process triggered and what does the last step look like?

💡 Start with a very high-level, simple blueprint or architecture map. For a BRYTER application with several modules, concentrate only on the sequence of the modules and how they might be connected with databases or redirect results.

💡 The blueprint is very likely not your final BRYTER architecture! Keep it as lightweight as possible by only leaving in the necessary details. You do not need to include every email action or inputs. Focus rather on the parts in your modules that represent the key 'junctions' and lead to very different outcomes (next steps/modules/documents/guidance)

💡 Think about all the stakeholders that are involved in the process. Consider using a swimlane diagram to clearly show which modules or steps in the application will be used by whom.