In Part I of ”Do You Need a Cloud Strategy?”, I described three inter-related steps that you will need to think through to develop a business-focused enterprise cloud strategy. In this post, I will discuss how to plan and implement your cloud computing strategy and roadmap through the lens of Enterprise Architecture (EA) and Service-Oriented-Architecture (SOA).
Enterprise Architecture (EA) is a holistic management discipline and a way of planning, controlling, and aligning your IT organization with the needs of the business. Notionally, it includes everything from how you manage your services, data, and applications, to how you manage governance and people. Service-Oriented-Architecture (SOA) is a subordinate concept to EA that adds an element of agility to the architecture. In essence, SOA defines a service abstraction layer on top of the infrastructure and platform layers and allows you to deal with system changes much more effectively in response to emerging business needs without having to constantly re-architect and re-design these systems.
While it may be appealing to think of Cloud computing as the new way of doing architecture, in reality, it is just one part of your architectural and technology strategy. It is one type of deployment strategy and one more tool in the IT toolbox. It is undeniably a powerful strategy and tool that provides unprecedented agility, flexibility, and scalability in a very cost-efficient way. However, given all the current hype, be aware that cloud computing is like an irresistible new toy and technology enthusiasts will be tempted to solve every business problem with this “new hammer.” Don’t forget the law of the instrument: “If all you have is a hammer, everything looks like a nail.” If you toss projects into the cloud without a strategic business-focused enterprise architectural approach based on SOA best practices, you are very likely to end up with a siloed system that is fragmented and can later cause you more headaches and issues with governance, security, integration, and migration.
Notably, there isn’t much notion of governance, control, or implementation of policies in cloud computing today. But considering that you are extending your services and systems out of your firewall, it’s critical to design your architecture using SOA principles so that you can securely connect and abstract out services, processes, and data—both from inside and outside of your building.
However, it seems that this is much easier said than done. If you ask any CIO how well understood his/her architectural and applications landscape—including interactions and data flow between and among applications—most CIOs will say they have more work to do in that space. No doubt, there is going to be reluctance to change, a fear of breaking systems that are working fine by moving pieces around. But tweaking system architecture in pursuit of greater efficiency was never painless, even before the cloud came.
“People are concerned that such a re-architectural effort will take years,” says David Linthicum, CTO of Blue Mountain Labs and author of Cloud Computing and SOA convergence in your Enterprise, “but in reality it does not really take that long to figure out a strategy and roadmap to migrate your systems into the cloud. It’s hard to get people to focus on strategy and architectural planning but it’s imperative that you do it with cloud computing because of the major business impact of this game changing technology.”
A thoughtful architectural plan will help your organization in the long run and will drive successful cloud adoption, which in turn, will directly lead to profitable business outcomes. Here are some steps to consider:
- Map the “As Is” model of the current architecture: Perform an inventory of the current system and develop a logical model of the existing architecture including all relevant systems, data, applications, processes, functional components, and services. As part of this exercise, analyze what’s working and what’s not working; what’s core to the business and what is not; what’s driving innovation and what’s cost-inefficient; what’s driving business value and what’s not; how the systems are coupled and interoperate with each other, etc. This analysis not only gives you a snapshot of your current architectural state, but it also provides you with crucial information to create a business case based on the new architecture. Without doubt, the cloud deployment options in the architecture will drive down cost inefficiencies and improve agility and scalability among other things. “An exercise like this typically take no longer than 4-6 weeks for a couple of architects in a mid-sized company,” says Linthicum, “It provides a foundation for creating a conceptual ‘To Be’ architectural model and the corresponding business case.”
- Model the “To Be” architectural vision: Once you have a clear understanding of the current state of architecture (“As Is” model), the pain points, and the cost inefficiencies, you can then begin to map out the vision of moving purposely to a “To Be” state. You will also want to include what it looks like and which architectural components, data, applications, systems, services, and processes will move to the cloud in what order and how much de-coupling is required to isolate the components etc. As part of this exercise, you will need to design a reference platform that leverages cloud technologies for highly scalable automation, low-cost hardware, middle ware, and application servers to connect new and existing applications. An enterprise architectural analysis will consider not just the technology piece but also the people, process, and the cost piece including areas such as hiring new skills, building an architecture group, QA/Test group, budgeting, TCO, SLA, governance, compliance, and so on. Even if, for example, the cost of moving to the “To Be” state from the “As Is” state is $5 million, most CIOs will move ahead with the initiative if the “To Be” architecture generates cost savings of more than, say, $10 million dollars per year.
- Develop the roadmap: You then need to figure out what to move when and where before detailing with the specifics around how to move them. It’s not necessary or practical to move everything all at once. You need to create a roadmap over a longer time horizon (say 3 years) and map out how these architectural components will move over to a much more effective and efficient architecture in a staged manner. Linthicum says, “This roadmap exercise also shouldn’t take more than a month to map out in a small to medium business. This includes a cost and benefit analysis for each stage of the roadmap.” Typically you focus on the low hanging fruit with the most business value and place them on the roadmap first. For example, you pick a relatively less critical application that is currently not being run cost efficiently in-house and move that to an external cloud quickly and gain significant business value. Then you pick the less valuable and more risky systems that are still worth moving and place them at the back end of the roadmap. Another consideration is to review the project portfolio and identify new and innovative revenue-generating projects that will benefit from faster time-to-market advantage using cloud technologies. The Chief Architect at an Energy company we interviewed as part of our “Leaders in the Cloud” research study, said: “We go after one or two big things each year, and [we] make sure we drive adoption off of them and then get $50 million to $100 million worth of value per by driving them. We look for stuff that’s promising and take it from there.”
- Executing the Roadmap: This represents the bulk of the work with the most risk and effort. It involves a deep dive into application re-factoring including potentially a reverse-engineering and data dependency and complexity analysis. Much of the work at this stage will involve hands-on re-factoring of the applications and data, moving them over to the cloud platform and then testing to make sure that the migrated applications continue to perform as they did before. The key thing is that application architectures should be highly parallelizable, virtualizable, and resilient to failures to work in the new world of clouds. The application developers now (in the cloud world where they are now “in charge” of the deployment as well) have to deal with the “real” world of infrastructure issues. They can’t just point a finger at those infrastructure guys and say that something in the infrastructure went wrong and therefore the application stopped working. It also creates a new type of intermediary similar to an application infrastructure developer who can provide the expertise for the underlying infrastructure and layer of abstraction for the application developers. Finally, as with any modernization or migration initiative, don’t be surprised if more than 50% of the work involves testing of the functionality, performance, scalability, and reliability.
So what are the implications of cloud computing on the architects and their skills and profession? Certainly, they need to learn about the technology—how it can work for them—and understand the opportunities that it represents. They will of course still be responsible for the overall conceptual architecture but they now have to deal with the fact that some percentage of that architecture will no longer be under their control. Furthermore, they have to contend with the emergence of virtualization and private cloud. In order to do so, they need to take advantage of these technologies to consolidate and streamline their previously stove-piped systems and applications. “The architectural approach is still the same with private clouds,” says Linthicum, “With the private clouds, you are basically replicating the cloud environment within your own data center with its associated technology benefits, but you may not get the same business benefits since you still own and maintain the hardware, software, and staff. At the end of the day, going to a private cloud is really more of a control issue than anything else.”
Our study indicated that the biggest growth will be in hybrid clouds (from 13 percent now to 43 percent in three years). Companies are looking to seamlessly migrate/interoperate their data and applications (both legacy and new) between clouds and their datacenters based on their own business needs, risks, and architectural considerations. The cloud strategy and roadmap should therefore include a strong security and governance model that ties in all the services running inside and outside the firewall.
“Large enterprises and government agencies are starting to build their cloud strategies and roadmaps, while small and mid-sized companies are already implementing cloud projects,” says Linthicum. “Companies that don’t adopt the cloud will lose market share to those that do adopt the cloud. We are seeing another inflection in the market like the one we saw with the Internet 10 years ago.”
Quotable Quotes on Cloud Computing I have spent countless hours in conversations with leading-edge enterprise CIOs and vendors who have shared in confidence a variety of perspectives on their cloud experience. Here is a selection of the choicest unedited quotes from these leaders on a range of hot topics in the cloud computing market. The individuals and company names are confidential.
“One of the bigger barriers to cloud adoption is application architectures. If you ask any CIO how well they understand the applications landscape and their mutual interactions, most will say they have more work to do that in that space. There is going to be a business reluctance to move things and risk breaking things that are working fine. It’s one of those ‘Don’t fix it if it ain’t broke’ kind of things—even if it is technically possible to improve the situation.” – CIO, software vendor
“Make sure you don’t get into an ‘us vs. them’ contest with your internal team. Don’t say, ‘See how easy and cheap it is to get stuff done externally?’ Bad mistake. It depends on which level of management you talk to, but generally our data center guys don’t want anything to do with the cloud conversation. They are focused on operating and running the data center—not focused on providing a service to the customer that could be delivered either through internal or external means. We have to get that switched around to where they have ownership over what they have. But it’s a big, big, big hurdle. Whenever I talk to the datacenter team, they say, ‘Oh, we can do that… We can do that… We can do that.’ But when we look at the cost issue and the capital requirements, the reality is that they can’t.” – Architect, Energy company
“The integration issue is more mythical and theoretical than it is a reality. This is an issue that companies have always created for themselves. Most companies have decided which vendors they are going to align with from a technology perspective and they are going to over-invest in a set of common things that they use—whether it be from Microsoft, IBM, Salesforce.com, Oracle, open source or whatever. That’s their IT model. Companies will have a set of choices and options within their model. You can’t move from one model to another easily. That’s been the case for decades now and there’s nothing new in the cloud that would make this situation unique. But the move to cloud will encourage more interoperability and standardization even within a single model.” – CIO, software vendor
Parts of this blog post are based on discussions with David Linthicum, CTO, Blue Mountain Labs and author of Cloud Computing and SOA convergence in your Enterprise. Thanks to him for talking with us and sharing valuable insights on cloud strategies/roadmaps and the connection between cloud computing, Enterprise Architecture and Software-Oriented-Architecture.
Kamesh Pemmaraju heads cloud research at Sand Hill Group and he helps companies—enterprises and technology vendors—accelerate their transition to the cloud. His blog has been recognized in the top 50 bloggers on cloud computing and also in CloudTP’s best cloud computing blogs list. He welcomes your comments, opinions, and questions. Drop in a line to kamesh@sandhill.com. For updates on news, views, interviews, webcasts, events, and blog posts, follow me on twitter @kpemmaraju.