General consideration

Warning:
Some parts on this site are outdated and will be revised.

The fact that the name of a role can be arbitrary is very disadvantageous in many ways. It is therefore clear which relationships exist between the roles. In addition, the risk of performing redundant tasks increases with the number of roles. That is no problem for Ansible, because the tasks are idempotent. But the multiple execution of tasks costs time and it is possible that a role (re-)configures something different from another role. Finding and fixing the bug can be very complex in this case. In a small infrastructure with only few roles, it may be possible to manage their content and relationships. But in an infrastructure with many roles it can be very confusing.

Another problem with arbitrarily named roles is the reusability of them. If a role of a project is to be used in another project, it can also be very complex to adapted this role for the use in the new environment. The reasons for this are again multiple execution, different configuration of same things and unclear relationships with other roles. Sometimes it may be easier to develop a new role than to reuse an existing one. In both cases, rewriting or adapting a role can be a very expensive tasks.

The SDM framework eliminates these problems because it defines a role hierarchy with a clear relationship between different roles. The goal is the simple use of roles in multiple infrastructures and a clear overview of all roles. Another goal of SDM is the management of entire infrastructures. In order to achieve these goals, the SDM framework divides the mentioned role hierarchy in a horizontal and a vertical hierarchy.

Variables are also an important part of these hierarchies and are mentioned in the following section. A detailed description of the variables in the SDM framework can be found here: SDM Guide/Variables