Having a Governance Model, as simple as it can be, to manage an OutSystems Factory it is always better than not having any. This means there is already a certain concern and awareness for the topic. It is the criticality of the solutions delivered that makes this topic more or less relevant when setting up and managing an OutSystems factory.
There is an example I usually like to give, during the interactions I have with customers, to create the so much needed awareness for this topic: imagine the following situation where one of your developers decides (with the best intentions) to update a component from the OutSystems Forge without understanding if that new version is compatible with the applications that consume it, just because he has the right set of permissions. With the fast pace of delivery and without the proper authorization policies, this new version can go behind the curtains from development to production in a glimpse and create a substantial impact. This is just a small example why is important to have a Governance Model in place.
I truly believe that situations like the previous one happen fully due to the lack of knowledge or unawareness of the impact of the action. It is also true that if users are not allowed to perform certain actions, they shouldn’t have access to certain functionalities, however we live in a world with different realities and with different levels of governance maturity. The best way to mitigate these situations is by taking the most of those use cases and create that awareness, share that knowledge, with the expectation it will promote better actions in the future!
So let’s start!
Lifetime is the OutSystems Application that allows you to manage your OutSystems infrastructure. This tool helps you to manage the application lifecycle, from development to production and supports the creation of a Governance Model that can make you proud.
There are 3 basic concepts that are relevant when we want to create a Governance Model in our factory with Lifetime. It is the combination of these concepts that will set what each user is allowed to see or do.
Applications
Roles
Teams
From a Lifetime perspective, Applications work as a “folder structure”, that can hold modules and extensions and, be connected with Roles through Teams. Roles are set of permissions, assigned to users, that define the operations they are allowed to do across all environments and applications.
Throughout the applicability of Governance Policies in Lifetime, Teams can be created to relate the different Applications with the Users (with a proper Role). This allows a better control of who-sees-does-what.
Despite Lifetime allowing the possibility of assigning Users directly to Applications, in my opinion, that is the moment when we might need to revisit the authorization model that supports all the Governance.
Now that we went through the introduction of the concepts, let me give you my version of that Governance Model that will make you proud.
Lifetime provides out-of-the-box 2 Roles: Administrator and Developer. This allows the minimal set of permissions needed to have differentiation between these 2 roles and allowing you to start working with the platform.
There are several approaches to extend this initial setup and I cannot say which one is better. However, what I can say is that depending on the way we want to organize our factory, there are approaches that produce better results then others. Depending on the purpose of the factory, we can use the following to guide us on the selection of the approach to adopt:
The main purpose of my factory is to create applications/products connected around the same Line of Business. In this use case, Teams should reflect the different Domains that will compose the applications/products.
In my factory I will support the growth of several applications throughout the vast number of Line of Business existing in my organization. This use case promotes the creation of Teams that follow the segregation of the different Line of Businesses.
In both scenarios, Applications and Teams need to respect the principals of independency between them, in order to leverage growth and promote an healthy Release Management.
When assigning a User to the right Team, it is important to scope the action of that User and for that, you can use the following authorization matrix as a baseline:
*Default Role should be given to all users upon creation with the exceptions of the Architect and Factory Manager. In more complex situations where there is the need to scope the action of the different roles per application the scope of the Default Role needs to be adapted to fulfill that reality.
The key take away is that the governance path to follow depends on the type of solutions you are going to support. Nevertheless there is always a group of applications we have to govern and will be present independently of your model. For those I advise the creation of certain Teams and assign only the needed users with the needed role to each of them:
Supported OutSystems Assets
Unsupported OutSystems Assets
Themes and Style guides
PoC’s, Sandboxes and Demos
The situation I described in the beginning can be easily avoided, by following this approach :)
This article was written based on my experience throughout the years working in different projects from different lines of business with different levels of governance maturity and different Teams sizes. Different use cases might need different approaches and different people/processes might mean different ways of working, however, I found very helpful to have a baseline to start the conversation and/or the thinking process. This is just one more baseline — mine!
If you agree with this approach share it! Thanks.
