Leverage teams to effectively govern your OutSystems factory.
In the last article I wrote, Lifetime — Create a Governance Model that will make you proud, the main idea was to create awareness around the Governance topic and how to enhance the out-of-the-box model that OutSystems provides in Lifetime. I have leveraged the experience of setting up these models and shared a small, but still more complete baseline of roles that you can use to govern an OutSystems factory.
All these roles alone are not enough to govern your factory, but a big step in doing it! The next one to pursue is to create Lifetime Teams to organize your Lifetime Applications. There are many ways of doing it and clearly depends on what you are going to build. However, there are a few Teams that will always be present:
Supported OutSystems Assets
When OutSystems provides a new Development environment (e.g. when a new license is bought), it already has installed a significant number of applications. These applications are OutSystems UI and its templates, OutSystems Maps, OutSystems Charts, Users, System Components, Platform Extensibility, and the App Feedback.
Another good example of applications that can be added to this Team, which nowadays is frequently seen in OutSystems factories, is the Architecture Dashboard (Arch Dash) probe applications. I will leave Arch Dash (OutSystems technical debt monitoring tool) eventually for another article, but these applications are only installed in the OutSystems environment that is being monitored by it.
Unsupported OutSystems Assets
All the assets that are downloaded from the OutSystems Forge, and are not supported by OutSystems but still land under the responsibility of the factory where they are installed. In some situations, you might even want to segregate this Team by creating a new one just for the mobile plugins. There are businesses, due to their criticality, that have internal processes to verify the plugin’s code, before making them available to the developers.
PoC’s, Sandboxes, and Demos
Throughout the projects, it is common to test concepts and validate assumptions and for that, developers create sandboxes applications. Also, it is common for the OutSystems Forge Assets to have demo modules that most of the time come in the same Lifetime application and since they shouldn’t be deployed in production, need to be moved to a different application. Proof of Concept apps is also another type of application that can be added to this Team.
Themes and Style Guides
Depending on the size of the factory, the maintenance of Themes and Style Guides applications is owned by a subset of developers. The best way to enforce those restrictions is by creating a Team in Lifetime and adding those applications to it.
Now that you created the minimum number of Lifetime Teams and added the right applications it is time to give the proper access to your developers. In the last article, I suggested a baseline of permissions accordingly to the roles that commonly work in the factories and by now all your Lifetime users should have the default role set. The last step of this process is to assign those users to the right Team with the right role, depending on the permissions they will have on each Team.
Once all this is in place you close the loop on the Governance model.
Every time a new application needs to be created should be analyzed to which Team should be added. In case of a new concept and a new Team should be created. Once the Team is in place users can be assigned and with the right role.
This article was written based on my experience throughout the years working on different projects from different lines of business with different levels of governance maturity and different Team sizes. Different use cases might need different approaches and different people/processes might mean different ways of working, however, I found it 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 clap and share it! Thanks.
