With great power comes great responsibility. And so, with the great power of low-code comes some serious pitfalls. You might be curious on how to avoid the sub-optimal performance, quality or maintainability for which we warned you in our last article.
Previously, we’ve talked about carefully analyzing the ideal user experience before designing an interface and adding business objects and use cases to your Design Sprint to enrich your requirement gathering.
Now, you’ve gathered the business requirements and you are ready to rock. Time to move to full-speed development, right? Not yet. Great products aren’t built on thin air, they are instead built on carefully thought-out fundaments. While we love being agile, planning is the beginning for solid, high quality and effective solutions.
You are almost set to translate great ideas in actual deliverables, but first you need to put in place the fundament of the development environment.
For this purpose we built a blueprint of what we’re aiming to build: our Quatronic Solution Canvas.
The Quatronic Solution Canvas is a combination of the 4 Layer Canvas (4LC) from OutSystems and a Solution Architecture.
Let’s start at the beginning. OutSystems’ 4LC is an architecture design framework that enables to build a product in a reusable (micro)services fashion with a high degree of functional independence.
Each functionality falls in a different layer given its functional nature:
the user interfaces that the users will interact with are organized in the Interface layer, while services around business concepts like data core registers and reusable business logic in the Registers & Core Services layer. Non-functional requirements like connections to external systems or extensions of your products belong to the Libraries.
The 4 Layer Canvas enables a more independent lifecycle of different modules, making changes easier and lowering the required maintenance.
We have added two important elements to enrich the 4LC: processes are split in Core and Support to promote functional simplification and User Roles are added to the top 3 layers so that specific data, logic and interfaces can be made available only to a subset of your users in an easier way.
A robust solution canvas is the result of a proper conversion of your Design Sprint deliverables. Thereby, your Solution Architecture will be able to cover the functional requirements of the product.
During the Design Sprint, a clear and definite long-term goal of your product has been defined, together with more detailed Sprint Questions.
The process that the users will execute through your product has been mapped and visually translated in a User Map, which in turn has been completed with a Use Case diagram covering additional required features.
Last but not least, the Business Objects have been gathered to define the main concepts, their relationships and attributes.
You got all the ingredients to define our Solution Canvas layer by layer.
Your top layer, Interfaces, contains all the elements that enables the user’s interaction with your product. Analyze the dependencies between different users, data and processes so to decide if you want to separate the interfaces by specific roles. Take into account that it’s a good idea to arrange a separate interface for administration tasks such as monitoring, user management and configurations.
Continue leveraging the User Map to consider which Processes you have to include in your product. Define them as Core if needed for users to achieve their goals while Support Processes are needed to enable or enrich a Core Process.
The Core Services layer is where you register the data that needs to persist across the defined business processes, complemented by the logic that modifies the them and reusable business logic. The business objects are the starting point to set up the core services and create the data.
Now here comes the magic. To avoid issues in the maintainability or scalability of your landscape, it’s crucial to not have upward dependencies. No Core Services that depend on Processes or Interfaces, no Processes that depend on Interfaces. Additionally, interfaces and processes should not have side-dependencies either. If interfaces or processes should be connected, it needs to happen in an Orchestration Layer.
Where were we.
The User Roles needed in your product are the selection of your user map actors that will interact with your application, plus supporting ones (for example, the administrator).
Those components which are usually imported from other environments or set up to be easily reusable in later projects (in the same application environment) will be technically regarded as Libraries.
With most development platforms, UI components & Logic Extensions can be included on the fly. You can furthermore define the graphic appearance of your product by defining a custom Application Theme and/or Template.
You may include Integration Services, identified in your organization’s IT landscape, to take care of all the communications with the external systems.
There you are. After taking the time to define all these components that will make up your application environment, you have set up your Solution Canvas. While filling the canvas for the first time, it might feel like a theoretical exercise. Soon you will find out that it will drastically increase the flexibility and stability of your landscape, allowing you to easily scale and maintain your products.
We’ve now covered how to prevent the User Experience pitfall and how to be sure that low-code does not lead you to pour maintainability and scalability. That leaves us with two other pitfalls to tackle: quality and performance.
Business Technology Consultant