Software update process (dependencies) in organization

Question

Wondering how other organizations manage software update process.

We are a startup, were we try to define components owners, which should update them (security updates etc).

This does not to seem to work well. People leave, components are left not updated.

How to organize effective and working update process in the organization?

We have also Security Champions and Security Team.

I would think we should focus on updating external components first, dozen of them.

How do other do it? What is the process? Structure of it? Should there be a centralized or decentralized approach? Who should drive it?

Preferred Scrum based approach/agile.

Thanks,

Answer 1

There is no answer possible. Many struggle with this and almost nowhere it actually works.

The point about component owners is perhaps the most important one. Every component must have a component owner. When people leave, someone else needs to pick that up (this is actually hard). In my experience, some form of hierarchy in the components (not necessarily in the organization!)help. For example: you may have a component-owner for all servers. He then delegates his Linux servers to a linux-component-owner and a windows-component-owner. When the Windows-component-owner leaves, it is clearly the responsibility of the servers-component-owner to appoint a new windows-component-owner. Likewise, if the server-components-owner leaves, the windows and linux owners will need to reelect a new server-owner. Do not rely completely on the fact that a leaver correctly transfers all his responsibilities within the organisation.

Any organization has some form of hierarchy. Ultimately, the top must be responsible for all IT.

Another challenge is how to make sure that your component owners actually update their components. And preferably without setting-up a huge administrative process. As a thought experiment: try to imagine such a process without a spreadsheet. Many just put-up with an administrative process though.

The remark "preferred Scrum based approach/agile" means that you are not looking to the structure, but only to its execution. You will need a structure that is independent of your scrum. Otherwise, you are down to forcing every team to put 2 story points (or whatever your scale is) for updating per component on their sprints.