There is a risk that we, as technologists, may become drunken with the power that knowledge gives us over the non-technical folk. They look to us for answers because we have the Dilbert Knack, and they trust us to really know.

And just when we fall through the rabbit hole of illusion that such power creates, when we have decided that we are gods, knowing and seeing all, those pesky humans, mere mortals they, go off and make a business-driven decision that runs contrary to every tenet of elegant design and best practices that we have graciously delivered to them at great sacrifice to ourselves on digital tablets for their own good because they cannot possibly know what is good for themselves.

Our ego blinds us to the truth. We are not gods. And when the business people reject our ideas, only humility will prevent us from making complete fools of ourselves. 

Indeed, we can only be truly effective when we come to understand that we serve at the pleasure of our employer, and we want to serve their interests but understand our place as a servant. We can gently persuade. We can teach. And we can be there when things go south, having the wisdom to never say, "See. I told you so."

AWS Architecture and Azure Architecture sites provide a variety of resources for architects including reference architectures. With AWS you get a brief one page PDF diagram for each scenario. With Azure you get a more in-depth documentation style following the infographic. Here are two examples. The first is an AWS financial services grid computing architecture.

The second here is an Azure machine learning architecture.

The reference architectures and additional architectural helps provided by your cloud provider can be very valuable.

And here's the BUT.

But you should not simply copy and paste. Use these guidelines to provide you with ideas and help you to think of things that you are missing in your own cloud architecture solutions. Take the good ideas and use a skeptical eye to pick and choose what works best for your organization's use cases.

Think of it as if you're building a car. Do you look at how other cars are built? Or do you put on blinders and make the same mistakes as everyone else had to make before you came along?