Service components in this zone provide secured access to the Data at Rest across multiple channels which serves as a basis for an omni-channel user experience.
Data presentation components would typically include:
- Native Mobile applications
- Desktop client applications
The role of the Data Presentation components is to simply display the records held in the Data at Rest components.
If the user experience requires business logic to be executed, then the functionality will be delegated to a Data in Action micro-service.
The ideas discussed below will replace our traditional approach to developing user experience and eliminate most of the code associated with the standard Create, Read, Update and Delete (CRUD) processing. For our Insurance Policy example with 100k lines of code, this could eliminate 30-40k lines of user experience code and another 30-40k lines of test code. This should cut our development costs by a further 30-40%. Again, we will improve the quality of the solution we are producing – smaller and simpler solutions are inherently faster and more stable! We can also significantly reduce the time to market for the solution.
Dynamic Page Generation
A consequence of storing business information in a data agnostic Data at Rest service is that we are running our CRUD+ model on XML. This means that we don’t have to tie the user experience to a table/attribute-based data model. The obvious next question is, do we still need to hard code the user experience forms against a fixed data model or can we leverage the XML representation to create user experience on demand?
Traditional Development Approach
When you think about our traditional application development approach, the fact that our user experience overlays a table/attribute data model constrains our implementation choices. Our database CRUD functionality extends beyond the database and into our presentation layer. We will have forms that enable us to search/filter, display and edit each of our concepts. Each of these forms builds on an associated set of business objects to abstract the database. If our data model encompasses 20-30 concepts, we are likely to have 40-60 forms in our user experience – most of the code behind these forms will simply be rendering the underlying data and then writing back updates as the user makes changes. In many applications, the actual business logic can also end up in the form’s code behind intermingled with the presentation. This increases the complexity of the solution and increases dependencies between the data, its representation and usage.
User Experience On Demand
Our Data at Rest service is serving XML so we are no longer bound to a fixed table/attribute data model. We can instead think about user experience in terms of the forms we wish to present. We can create a set of Form Definitions which determine how the XML is represented to the user. Our user experience then becomes a simple matter of matching the XML data with the appropriate Form Definition and rendering a user experience. We can do this by simply associating the ConceptGUID from the instance metadata with the Form Definition used to represent it the two become synonymous.
We can now take maximum advantage of the CRUD+ functionality exposed by our Data at Rest service to provide additional functionality in our user experience. Since our Form Definitions will also be stored in our Data at Rest service they can be exposed to provide the same user experience across, client, web and native mobile applications – all at the same time. This gets around a major versioning issue when release solutions that target multiple platforms and present an omni-channel user experience.
Not all platforms have the same capability when it comes to creating a user experience. One dimension of our Form Definition will provide a mechanism for selecting an appropriate representation for each possible platform. In some cases, it may be a reduced capability, in others it may be to suppress the representation completely.
User Role and Domain Driven Design (DDD)
When constructing the Form Definition, we need to be able to take into account the role of the person who will be using it.
Let’s consider our Insurance Policy example, if the person is a broker Rating the Policy, then they will need to see a different representation of the Policy than a person in the Claims department processing a claim.
In a DDD solution we might have separate Domains and ultimately services for Rating and Claims. The brokers will be using the Rating service and the claims adjusters will be using the Claims service. The two different groups of people will have two different roles but will be accessing the same set of common Policy records. To provide this functionality, we simply must assign each user to one or more roles and then set up our Form Definition to provide an appropriate representation of a Policy to each user role.
When rendering an instance, we should also be considering its state. In our Insurance Policy example, a Policy that is still being rated shouldn’t have the ability to be claimed against.
This means we need to extend the Form Definition to take into account the instance state. Then when we load the instance XML we can use its state to determine its representation. As the state of the instance changes over time so does its representation.
Having a single Form Definition rendering platform means that we need no longer create many separately custom-built forms for all possible combinations of platform, user role, and instance state.
This means that it is easy to change Data Presentation. We sometimes do this in real-time during a requirement gathering meeting - this enables us to be sure that the users are getting exactly the presentation they need to do their jobs effectively.
Having a single Data Presentation service means that we are also deploying fewer components with a shared overall user experience. This makes it easier to move employees between roles – they are essentially using the same application, in the same way, with the same data – just seeing different representations and functionality based on their new role.
It also makes it easier to onboard new resources. There is less software to learn and most of the user experience changes they will need to make can be done in data within impacting any code.