I’m a cloud computing architect. I get to draw impressive diagrams, meet with cloud providers, pick security approaches and technology, deal with governance, and then turn the whole thing over to other people to actually do the work. Nice work if you can get it.
Many cloud architects believe that their job ends at the PowerPoint delivery, but I’m telling you that you need to dig into operations as well. In other words, design not only what the cloud will be, but how to run it long term.
This is important for a few reasons:
First, nobody has any idea how to best operate a cloud solution without those who created the solution chiming in about the why, how, and what of the solution itself. For instance, cloudops needs to know why we picked this type and brand of cloud storage, and how we intend to operate cloud storage over time. Missing details means that they need to fill them in, and the risk of getting things wrong goes way up.
Second, you may have made a mistake as an architect—it’s been known to happen. The cloudops folks are charged with daily operations, thus your mistake will come down on them. You need to work with them to make sure the cloud solution continually improves, going forward.
What’s an architect who wants to move on to the next project do? Understand that you’ll have to deliver an ops playbook as part of the architecture. Tell the cloudops team how you expect them to drive the cloud architecture long term and how to deal with issues regarding performance, security, and governance, using best-of-breed monitoring and management solutions.
If this sounds like something you’re not skilled in doing, I would argue that it needs to be part of your training. Keep in mind that most don’t agree with the architecture-to-ops link and might push back on the concept I’m advocating. However, I really don’t see any way around it, if you want your cloud solution to last more than a month.