I deal with computing architectures by first laying out requirements, and then laying in any constraints for it's success. Only then do I bring in computing elements to apply to the system. As an example, a requirement might be "world-side availability" and a constraint might be "with less than 80ms response time and full HA" or something similar. Then I can choose from the best fit of technologies which range from full-up on-premises computing to IaaS, PaaS or SaaS.
I also deal in abstraction layers - on-premises systems are fully under your control, in IaaS the hardware is abstracted (but not the OS, scale, runtimes and so on), in PaaS the hardware and the OS is abstracted and you focus on code and data only, and in SaaS everything is abstracted - you merely purchase the function you want (like an e-mail server or some such) and simply use it.
When you think about solutions this way, the architecture moves to the primary factor in your decision. It's problem-first architecting, and then laying in whatever technology or vendor best fixes the problem.
To that end, most architects design a solution using a graphical tool (I use Visio) and then creating documents that let the rest of the team (and business) know what is required. It's the template, or recipe, for the solution. This is extremely easy to do for SaaS - you merely point out what the needs are, research the vendor and present the findings (and bill) to the business. IT might not even be involved there. In PaaS it's not much more complicated - you use the same Application Lifecycle Management and design tools you always have for code, such as Visual Studio or some other process and toolset, and you can "stamp out" the application in multiple locations, update it and so on.
IaaS is another story. Here you have multiple machines, operating systems, patches, virus scanning, run-times, scale-patterns and tools and much more that you have to deal with, since essentially it's just an in-house system being hosted by someone else. You can certainly automate builds of servers - we do this as technical professionals every day. From Windows to Linux, it's simple enough to create a "build script" that makes a system just like the one we made yesterday. What is more problematic is being able to tie those systems together in a coherent way (as a solution) and then stamp that out repeatedly, especially when you might want to deploy that solution on-premises, or in one cloud vendor or another.
Lately I've been working with a company called RightScale that does exactly this. I'll point you to their site for more info, but the general idea is that you document out your intent for a set of servers, and it will deploy them to on-premises private clouds, Windows Azure, and other public cloud providers all from the same script. In other words, it doesn't contain the images or anything like that - it contains the scripts to build them on-premises in private clouds or on a public cloud vendor like Microsoft.
Using a tool like this, you combine the steps of designing a system (all the way down to passwords and accounts if you wish) and then the document drives the distribution and implementation of that intent. As time goes on and more and more companies implement solutions on various providers (perhaps for HA and DR) then this becomes a compelling investigation.
The RightScale information is here, if you want to investigate it further. Yes, there are other methods I've found, but most are tied to a single kind of cloud, and I'm not into vendor lock-in.
Poppa Bear Level - Hands-on
Windows Azure Virtual Machines 3-tier Deployment - http://support.rightscale.com/09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure
Momma Bear Level - Just the Right level... ;0)
Baby Bear Level - Marketing
Just to be clear - you'd rather be locked into Rightscale than a cloud provider. Interesting.
Jeff - just to be clear, at some point you have to pick what you want to do and how you'd like to do it. :)
No, I'd prefer not to be locked into anything. And I think even if you use RightScale (or anything else) it's completely OK top do something else as well. It's not a binary choice, thankfully.
Thanks for reading!
I particularly like how you described your method of architecture using abstraction; I think the same way but hadn't managed to express it so clearly.