If you are charged with creating cloud architecture, you need to start with the business. Why? Because the business drives IT, not the other way around. Although we all know that fact, it’s too often ignored.
The sad truth is most cloud projects are driven more by technology than by strategy and business objectives. It’s fun to talk about technology, while leaving the business and strategy discussions for later.
When I meet with enterprise IT folks, they want to talk about the joy of containers and Amazon Web Services, not the forces that drove the move to cloud in the first place.
This is backward.
It’s supposed to go like this: Business drives the vision, which drives the strategy, which drives the architecture, which drives the technology.
The business requirements are typically known, and they’re easy to gather in a quick survey of the company: what they do, how they do it, and how they make money.
The vision comes from the business needs, and it provides direction for IT in terms of what the “to be” state should look like. You must create a strategy, which is a clear path to get to that vision.
Finally, and correctly last on the list, is the cloud architecture and a list of enabling technologies that make up the architecture.
The “technology first” crowd is out there in a big way, and it currently dominates conversations. That does not bother me as much as it once did, because I pretty much gave up on arguing with that crowd. After all, you can work from the bottom up. But if you do, figure that there will be a few round trips along the way. If that is OK with you and your leadership, then have at it.
However, I can’t help but advise that the better path to a successful cloud implementation is to go through the “requirements first” process I outline in this post. It’s less work when all is said and done and puts IT in the business’s good graces.