When working with IaC, there are 3 important roles that work closely together: the enterprise architect, the solution architect, and the support engineer. In my work as an infrastructure consultant, I see how each of these roles contributes to the success of cloud solutions. At least, ideally. Because there are also sometimes misunderstandings about who is responsible for what.
To prevent this, I outline what the ideal picture looks like for me.
Enterprise architect and solution architect: clear responsibilities
The enterprise architect sets the framework for the entire organization and, for example, makes crucial decisions about which cloud platforms to use and which not to use. This has a huge impact on the implementation of IaC. That simply works differently in a multicloud environment than in an organization with a “Microsoft unless” policy.
It is also the responsibility of the enterprise architect to make a decision about naming conventions, network setup and use of subscriptions. As a solution team, for example, you receive 1 subscription from the architecture for development, 1 for test and 1 for production. In practice, I see how important this is: such guidelines ensure that all teams work within the same framework.
Within those frameworks, it is up to the solution architect to design the concrete IAC implementation. Because, in my opinion, infrastructure is simply part of the solution. The solution architect knows what the solution should be able to do and chooses which components, network configuration and authentication methods go with it. The developers then roll that out consistently, because they use the same code for every environment they set up.
The support engineer no longer needs to know all the details
The third role that is important at IaC is that of the support engineer. A support engineer is usually responsible for multiple solutions. If all those solutions use their own infrastructure guidelines, that's no fun. Because it is completely impossible to know all the details about it.
The great thing is: thanks to IaC, that's no longer necessary either. At least when the enterprise architect and solution architects have done their job. Because everything is then set up according to fixed patterns, all solutions work in the same way, so it doesn't matter which solution the support engineer should work on. Everything has predictable, clear names, everything is connected in the same way, and all software components are where the support engineer expects them. That saves a lot of searching and calling.
The financial side of infrastructure requires conscious choices
And then there is actually another role missing: that of higher management. Because a crucial aspect of IaC, and cloud infrastructure in general, is the financial impact. In my experience, CEOs are often very focused on the functionalities of their software and pay less attention to the infrastructure. This is understandable, because from their perspective, infrastructure is a precondition. It's the features that help them attract customers and stay ahead of competitors. So it is often up to architects, developers and support engineers (and, of course, me as consultant) to 'sell' IaC to higher management.
Not necessarily a difficult job, depending on what stage the product and company are at (more on that in part 3), because a cloud environment costs serious money and if you don't organize it properly, the ROI of your project is quickly at risk.
Financial responsibilities in the team
The solution architect must also take the costs into account in the design. “We need an SQL database” isn't specific enough. Because that can be a Mercedes from an environment, while a Ford Focus might be enough for you. So it's about finding the right balance between functionality and costs.
The support team also plays an important role in cost control. A support engineer who has to maintain the software in the later process also sees the costs and can intervene where necessary: “Hey guys, I see that this server costs 5000 euros per month, is that right? Or is that less possible?” Such a proactive attitude helps to avoid unnecessary costs.
Smart differentiation with iAC
One of the major advantages of IaC is that you can easily create different variants of an environment. In a development environment, for example, a small, simple server is enough, while in production you know that 10,000 people work on it every day, so you need a more robust machine. This flexibility allows you to optimize costs without sacrificing quality, while still benefiting from the predictability of IAC environments.
In the next part of this series, I'll delve deeper into the practical implementation of IaC and discuss concrete examples of how to approach this in your organization.
.jpg)
