"You do not have to be Albert Einstein to handle your IT assignments 'On Time' (i.e. To Schedule), 'At Cost' (i.e. To Budget) and 'To Specifications' (i.e. To Scope)"
Yaacov (Jack) Bar-Tor
Information Technology
YBT Services Pty Ltd
Trust
Trust is a massive component of achieving a DevOps culture. Operations must trust that Development is doing what they are because it’s the best plan for the success of the product. Development must trust that QA isn’t really just there to sabotage their successes. The Product Manager trusts that Operations is going to give objective feedback and metrics after the next deployment. If any one part of the team doesn’t trust another part of the team, your tools won’t matter. Additionally, if you don’t trust the people who work for you, why are they working there? Why are you?
In systems, a trusted component has a set of properties which another component can rely on. If A trusts B, this means that a violation in those properties of B might compromise the correct operation of A. Observe that those properties of B trusted by A might not correspond quantitatively or qualitatively to B’s actual properties. This happens when the designer of the overall system does not take the relation into account. In consequence, trust should be placed to the extent of the component’s trustworthiness. The trustworthiness of a component is thus, not surprisingly, defined by how well it secures a set of functional and non-functional properties, deriving from its architecture, construction, and environment, and evaluated as appropriate.