wurstbrot
Team-based assessment
DSOMM currently assesses whole organizations. Every dimension can be adapted to meet organizational requirements and needs, but the implementation level diagram is always an assessment of all processes at once.
Team-based workflows can be modeled in one of two ways:
- Find the dimensions and sub-dimensions pertinent to every team's work and model them accordingly
- Use DSOMM for each team individually.
The former approach brings with it a lot of organizational overhead.
- If teams have individual responsibilities without overlap, these can be modeled easily in their respective dimensions, but it is not easy to assess an individual team's performance within the organization.
- If team responsibilities overlap and several teams have the same task in a dimension level, the assessment becomes more complex. Is a requirement considered fulfilled when it is part of one team's processes or only for all teams? Respectively, is a requirement listed only once per dimension or once per dimension and team? Each solution either introduces complexity or minimizes the overall assessment's accuracy.
Therefore, DSOMM should be able to model and assess processes for individual teams.
- It should be possible to define teams with a name and associated metadata.
- It should be possible to sub-divide an individual requirement by teams and track each team's status.
- Each team should have its own matrix of tasks and its own implementation level diagram that only lists the dimensions and sub-dimensions defined for this team.
- The main implementation level diagram should model the whole organization's state and account for teams and their status by sub-dividing requirements. A dimension level should only turn green if all requirements are fulfilled by all pertinent teams.
One possible implementation can be a separate yaml schema for team definitions and an according array of teams per individual requirement. A requirement should only be considered fully fulfilled once each team implemented it.
Example of a per-team implementation level diagram with only team-relevant categories.
Hi @corrupt and @wurstbrot The above design change looks good, But if we select 2 internal steps and select team 1 and Team 2. it means both teams are executing those 2 steps.
But Team 2 doesn't want to execute one of the steps of the selected ones. At this time we are not giving the option to the user to execute the specific step for an individual team.
Can we have the something like one below where we select the team and then select the operation to be done?
The above design is for, when we want to do the process at the team level.
if a user wants to go with the organization level. we have separate Teams and Organizations separated like below. where all steps will be executed at org level
Whereas in organizations we will have the same look as we have currently.
when the user selects a teams level, we will disable the organization and team 1, team 2 will be coming under it
Please let me know your opinion or suggestions. As of now, I am writing the proposal,I will include the design changes and work in my weekly deliverables based on the decisions.
Having used DSOMM a bit Im not convinced this is the way to go. While you could do this for "team-based activities" it wont cut it for other "dimensions". Most organizations are complex with many different teams, environments, applications and systems. Examples of granularity:
- Hosting environment: A (on-prem), B (cloud provider 1), C (cloud provider 2)
- Teams in all shapes and sizes
- Different types of systems: Frontend, backend, VM-based, Container-based, Desktop, Mobile - with varying stacks, requirements ++
For example a team can be responsible for many different systems/apps. Will you add a new list there?
To me it seems like it would be worthwhile to take step back and look at it from a more atomic "activity" point of view:
Which context are we in?
- Context: Organization: security training for all employees - true
- Context: Environment A: Filter outgoing traffic - true
- Context: Team 1: security champion - true
- Context: Team 2: security champion - false
- Context: System C: Coverage of client side dynamic components - true
This would be flexible as well - you could say that your organization has one context or many. And you can appropriately adjust depending on your needs. It would then also be nice say "system c runs in environment A, maintained by team 1" - therefore it has this score. Say you moved system c from environment A to B - perhaps you got a lot of new security features as a result - it would automatically be adjusted.
@kjartab I think what you wish is already there. You can perform the assessment with the YAMLs and use the application to display the results.
See https://github.com/wurstbrot/DevSecOps-MaturityModel-custom . You can have different YAML files with the data. Some for org, some for env. A some for teams. The YAML files will be merged in the end.
The downside with this new feature is (currently), that you have to update all teams for each activity. We can think about grouping teams and use the group name for the attribute teamsImplemented and value true/false which inherits the value to the teams in the group. What do you think?
In the long run, attaching AzureAD is an option.
@wurstbrot yes that is essentially what I am looking for. Merging the different contexts. But if you change the model in the yaml files to accomodate the team dimension, it will have to be used for all activites? Its already a bit time consuming to do the checkboxes when going through this.
I see the yaml files under src/assets/YAML/default as the model btw - and this seems like more presentation/input logic rather than a part of the maturity model. I might be misunderstanding something here, but seems smart to keep these things separate.
The way I see it combining context specific assessments make the most sense - and then you have parent child relationships. This way you can focus on more than just teams - but also different platforms, systems and products.
Depending on the size of the organization you might want to slice and dice the data in different ways - also having "contexts" that are owned by platform teams - inherited by a team or system - could be a powerful visualisation for where to invest time and effort to "lift all boats".