What is Virtualized UX and CRUD Functionality?
For the purpose of this discussion “Functionality” means the user experience presented by an application. It is how a user will create and maintain data. It will also be used to invoke workflow on existing data.
“Virtualizing UX and CRUD functionality” is a mechanism by which the user experience is no longer rendered by code in the application. Instead, non-technical business analysts and enterprise SMEs (subject matter experts) can configure most of the user experience as a dataset without the need of developers. The user experience will be rendered in real-time on the user’s device by combining the configuration dataset with the data to be displayed. Where a developer is required, the scope of the developer’s customization tasks will be small and well-defined. Examples of where a developer might be required include creating a custom microservice component to accomplish a single task – like “Calculate Sales Tax”.
We have recently published a blog that discusses the benefits and why you might be interested in The Virtualization of UX and CRUD Functionality.
Virtualizing UX and CRUD Functionality sounds good – but is it possible?
There are lots of benefits that virtualizing UX and CRUD functionality brings to the Enterprise, so the next logical question to ask is “How can we do this?”
At Great Ideaz, we have been working on this problem for a long time and we feel that recent advances in user experience technology have now made functionality virtualization a practical reality today.
As an industry, we have already been moving in the right direction by adopting the microservices approach. The core ideas of virtualizing UX and CRUD functionality are simply going to build on our existing success by adding a few very simple refinements.
To be clear: Virtualizing UX and CRUD functionality is not a radical departure from modern Enterprise Architecture, rather, it is a refinement of existing industry best practice.
Refinement 1: Framework level Data Agnostic Storage Services
At present, we mainly store data within the scope of an application or service. This creates lots of separate data stores implemented using a wide variety of technologies. We have many challenges including integrating data across the data stores, securing data within the data stores, maintaining the quality of the data, etc.
Our business-critical data is ever more fragmented as business users reach for the latest cloud service to create their own data stores. At the same time, we are seeing significantly increased threat levels from malware and ransomware.
The first prerequisite for virtualizing functionality is to abstract the data from the applications and services. The data will instead reside in a framework level Data Agnostic Storage Service (DASS) and be directly available to any application or service.
At Great Ideaz, we have been creating Data Agnostic Storage Service (DASS) for over a decade and have published detailed architectural documentation on how to build and maintain them.
Moving data into the DASS can happen as the applications and services are modernized.
Refinement 2: Framework level Dynamic Page Builders
With traditional applications, the user experience is mainly hard coded into our applications and services. This binds the scope and implementation of the user experience to pages of source code. If you want to change the user experience, you need to change the code. This user experience is ultimately being used to create and maintain data within the scope of the application or service. Most of this data is held as records within relational databases or spreadsheet-like tables.
The second pre-requisite for virtualizing functionality is to abstract the user experience from the applications and services. The user experience is instead configured as a dataset (“Form Definition”). An administration tool can be used to configure the dataset by non-technical users.
At Great Ideaz, we have been evolving and refining our UX Creator for over a decade and have published extensive reference documentation.
An additional opportunity with virtualizing functionality is the ability to render a user experience on any device based on the configuration dataset, the current user, and the state of the selected data created/maintained by the DASS.
At Great Ideaz, we have been working on the development of Framework level Dynamic Page Builder (DPB) technology for over a decade. The recent release of the Microsoft .NET Blazor/MAUI technology has at last made practical DPB a reality. We have published detailed guidance on how to build them and you can sign up to our portal to download the latest release of trellispark.
Moving the user experience into the UX Creator occurs as the applications and services are modernized.
Refinement 3: Changes to microservices
Many microservice implementations still encapsulate their own data and call other microservices to update the data they encapsulate. This approach creates the need for many antipatterns to solve common implementation problems.
What we need to be able to do is use our virtualized functionality to invoke a microservice using a common interface. The microservice can then connect to the DASS to directly access the latest version of the data it requires to perform its function.
This means that we can continue to use all of our existing microservice tooling and experience – we just want to move data out of the microservice and implement a common calling interface.
How can you “kick the tires” and try it out?
The Great Ideaz portal provides a free download release of the complete trellispark platform – its a complete package to see whether virtualizing functionality will work in your Enterprise.
The trellispark Implementation Approach article describes the steps involved to use the platform to virtualize your first application functionality.
Accelerate your modernization strategy
As applications and services come up for modernization, instead of recoding them, simply virtualize the user experience that you require and move the data into your DASS. For most applications and services this will be faster, cheaper, and lower risk than hard coding the functionality again and building yet another set of data stores.