The use of road maps to illustrate technology plans is fairly widespread. Whether it's a vendor explaining its product plans or a technology architect showing the evolution of a particular area of the infrastructure, road maps are great for communicating what happens when. And when plans as illustrated by the road map get sign-off, they can become a useful tool in change management as well. Someone wants your key resources for a special project? Fine, but all the dates on that road map they just approved just shifted six months to the right. Road maps tell the story of what to expect an organization to accomplish for the foreseeable future, and that's what makes them powerful.
That's why road maps that link traditionally difficult-to-explain areas of technology, such as those related to information management, to specific and highly desirable business outcomes can be a major win for architects looking to communicate what they're doing and why. There's always been a Catch-22 about explaining the value of complex technologies to audiences with no appetite for technical complexity -- but with needed sign-off authority for key resources (like funding). If the EA team has credibility (OK, that can be a big "if"), just showing the interrelationships between business outcomes, business capabilities, IT projects, and required activities in the various EA domains can satisfy the need for "explaining" that complex technology. Or for explaining the need for that not-well-understood architecture process that requires business involvement, such as information architecture development or governance.
Out of all the inquiries I get from Forrester enterprise clients, the above question is by far the most common these days. However, the question shows that we have a lot to learn about true public cloud environments.
I know I sound like a broken record when I say this, but public clouds are not traditional hosting environments, and thus you can't just put any app that can be virtualized into the cloud and expect the same performance and resiliency. Apps in the cloud need to adapt to the cloud - not the other way around (at least not today). This means you shouldn't be thinking about what applications you can migrate to the cloud. That isn't the path to lower costs and greater flexibility. Instead, you should be thinking about how your company can best leverage cloud platforms to enable new capabilities. Then create those new capabilities as enhancements to your existing applications.
This advice should sound familiar if you have been in the IT business for more than a decade. Back in 1999 we did the same thing. As the Web was emerging, we didn't pick up our UNIX applications and move them to the web. We instead built new web capabilities and put them in front of the legacy systems (green screen scrapers, anyone?). The new web apps were built in a new way - using the LAMP stack, scaling out, and being geographically dispersed through hosting providers and content delivery networks. We learned new programming architectures, languages, and techniques for availability and performance. Cloud platforms require the same kind of thinking.