#Service Engineering
| Capability Level | Capability Name | Description | Observed Behaviour | Project Scope |
|---|---|---|---|---|
| 0 | Service Engineering: Minimum viable Capability | Development focused team define their own standards. | Development have accepted internal standards and guidelines but not shared them. Test and operations capability are not considered necessary for new feature development. There is little-to-no trust between software, operations and test engineers as teams don’t understand or value each other’s domains, expertise, experience or contribution. |
Codify development standards include language choices, style guides, code review processes as well as IDE, LINT and other tool choices. Share these standards with operations and test engineers. Apply development standards to existing operational scripts and automated tests and store all operations and test code in the source control repository no matter how bad it is. Initiate code reviews for operations and test code. |
| 1 | Service Engineering: Universal Standards | Technology standards are shared across the the whole technology organisation. | All engineers use the same tools and adhere to the same standards, trust grows between engineers. Software and test engineers don’t understand or trust the environments. Operations and test engineers still excluded from application development. Software and Operations engineers lack understanding of test coverage or quality. |
Apply coding standards to configuration management elements. Perform code reviews on configuration management and deployment code. Rotate the duty among several software engineers. Have software and operations engineers work with test engineers to contribute automated tests for application and environment build and deployment activities. |
| 2 | Service Engineering: Peer Review | All engineers contribute to improving quality and standards. | Informal collaboration and pairing will begin with small projects. Operations and test engineers still take an ad hoc approach to software development. |
Include operations and test engineers in software design and planning activities. Test engineers should be tasked with designing and coding the tests for the new features being built. Operations engineers should be tasked with assessing the impact of new features on infrastructure and updating configuration and deployment mechanisms. |
| 3 | Service Engineering: Collaborative Design and Development | New feature development is collaborative and standards evolve naturally. | New features receive improved testing and suffer no regression bugs. New features provide high quality feedback and suffer less performance and capacity problems. However significant effort is still required to build, test, deploy and support changes to core components. |
Develop the capability to deploy service changes to groups of customers in specific geographic regions or to percentages of the customer base. Create feature toggles for all new features or significant changes to features allowing code to be deployed at all times regardless of it’s state of completion. |
| 4 | Service Engineering: Continuous Delivery | Feature toggles and targeted and partial deployments | New features can be deployed before they are ready, in an offline state. Launch of new features is now a configuration task not a deployment task. Enabling and disabling features does not cause incidents as the service is fault tolerant. |