Series: How to Kill the Architecture Department? Part 6

Part 6: The Senior Operations Engineer

Architectural activities tend to focus on the initiation and design phase of a project. In the previous post, we already pointed out the importance of architectural thinking during the development of software. In classic organizations, there is relatively little attention for the operations department. The architecture of infrastructure is essential for the success of software.
The only valuable software is software in production. This means that for software to be valuable, you should focus on getting it in production as quickly as possible. Many agile practices help in speeding up the development part. But if you limit yourself to these agile practices, you may still hit a wall when you want to deploy your software on the live systems.

For example, a large development team has been developing software for half a year in an agile way with biweekly demos of potentially shippable software. At the end of the project, after customer approval, the software is planned to go live just before the end of the year. Then the operations department says there is no capacity in the next three months to bring the software to production. They say a request should have been made right at the start of the project to make sure the capacity would have been planned.
In classic organizations, there has been a clear separation between development and operations. Organizational separations like these lead to handovers. In agile and lean thinking, handovers are undesirable, because handovers involve waste and increase the complexity of the process.
The title of this series is “How to Kill the Architecture Department”. It might just as well have been called “How to Kill the Development Department”, “… the Operations Department”, “… the Test Department”. Our previous posts urges architects to leave their ivory towers and take a part in the development team.
Similarly, we ask operators to take part in the development team. And the other way around, we ask software engineers to take part in operations. When both operators and developers start working together as a team, they can shorten the Time-to-Market to get software into production. This is part of the DevOps-philosophy. (https://en.wikipedia.org/wiki/DevOps)
Now you may wonder what this means for the employee formerly known as architect: the (chief) technical product owner and the senior software engineer. So far, in our posts, we described specialists focusing on the architectural aspects of software in each of the phases of realization of a user story, except in operations.

In operations, there is also architecture: one of data centers, hardware, networks, switches, firewalls, caches. Making the right choices here requires specialized knowledge and experience. To facilitate this process and guard that the decisions are in line with the overall vision, you need a Senior Operations Engineer.
The Senior Operations Engineer works closely together with the Senior Software Engineer. Both take part in the development team. For some changes, the Senior Operations Engineer needs decisions to be made earlier on in the process. For example, when old software is problematic in production and new features are increasing the problem. For more strategic decisions, the Senior Operations Engineer works together with the chief technical product owner, whose task it is to convince higher business managers that a larger technical change is required.
The most important points of attention for the Senior Operations Engineer are: manageability and maintainability, regardless of whether the organization is doing DevOps. The Senior Operations Engineer can be a good sparring partner for the Technical Product Owner to improve manageability of software. Infrastructural knowledge is scarce and specialized.
The other way around, choices in the infrastructure may affect the development of software. This way, there is a relation between the Senior Operations Engineer and the Senior Software Engineer.
So far, the series described a model for architects to take part in an agile organization. Some of the changes required to start doing this, have a large impact. The question is: how can you as an architect contribute towards this new way of working? The next post will address questions like these!
Stay tuned!