SOLUTION WHITE PAPER. Take a Holistic Approach to Your Cloud Implementation By Lilac Schoenbeck, Director of Cloud Computing Marketing, BMC Software

Transcription

1 SOLUTION WHITE PAPER Take a Holistic Approach to Your Cloud Implementation By Lilac Schoenbeck, Director of Cloud Computing Marketing, BMC Software

2 With a move to the cloud, much will remain the same, but the changes that do occur will affect people across the organization. A holistic approach to cloud implementation takes into consideration all of the people, processes, and technology involved. Ann, the VP of Infrastructure for her company, watched people get on the elevator at work as she contemplated the change the company was about to undergo. She was responsible for all technology changes, and her company viewed the upcoming switch to cloud as just another technology change. Ann knew it was so much more than that it was a change in the way she did business. What internal processes would need to shi with the implementation of a cloud? What would it take to upgrade the skill sets of her sta ff to provide cloud services? DOES THIS SCENARIO SOUND FAMILIAR? While much stays the same with a move to the cloud, several things do change and affect people across the organization. These changes should be taken into consideration holistically; special care should be taken to make sure all impacted parties are involved in the cloud design and implementation. But who should be included? And what does change? How can these changes be managed well? Many people inside an organization will be using the cloud and should be considered. These people include the development team of so ware engineers, research and development (R&D) groups, and business users, and the application team in charge of building and maintaining internal applications. Others should be included who are involved in the design, implementation, and day-to-day running of the cloud, such as the virtualization administrator, storage manager, network manager, application development team, capacity planner, and server and database administrators. Once everyone who should be included has been identified, some key questions need to be answered regarding access, flexibility, options, service levels, and provisioning. What changes and what stays the same? Some things should move seamlessly to the cloud, including the processes that were built and policies that were created. Others are o en new, including new hardware, storage resources, and network, as well as new stack elements such as virtualization. There are also o en new components, such as customer self-service and the service catalog. As the machines collaborate, so must the people. For a smooth transition, IT needs to consider these key relationships:» The relationship with the user Given the proper initial planning, the infrastructure team has a better sense of their customers and a new set of processes to address the collaboration.» The relationship that delivers the service The process of configuration extends not just to the VM but also to the entire application stack to match the environment and the user s needs.» The relationship of operations Resizing and moving of services, new provisions, new decommissions, and new services all impact operations in the environment. 1

3 PEOPLE, PROCESS, AND TECHNOLOGY: THE WHO, WHAT, AND HOW OF GETTING TO THE CLOUD The cloud changes the operating model. Consequently, it is helpful to think about the impact of the cloud holistically on the IT infrastructure and the services that are delivered. Cloud gives the power to automate a tremendous amount of the process of procuring IT resources, but that automation should always be done in the context of the users and their needs. Building the wrong cloud quickly does not meet anyone s objectives. So, it s important to consider who should be involved so that you can build a cloud that meets the needs of your stakeholders. WHO IS INVOLVED The first step of building a cloud is defining the target audience. Who will be using the new cloud? Some common candidates inside an organization include the development team of software engineers, R&D groups, business users, and the application team in charge of building and maintaining internal applications. Each of these customers will have a completely different set of requirements for their cloud offering. Developers would most likely want a whole copy of the multitier application on which they are working. They probably would need a few copies at different times for testing purposes. They could easily use, and would prefer, a self-service portal to request such an instance. Development managers would most likely wish to ensure that each developer is working with the latest, properly configured version of the environment. Variability leads to bugs and, therefore, configuration management is even more critical in this environment. Cloud users may be less inclined to return resources than paying customers of public cloud services. Consequently, development instances should be stamped with a decommissioning date to ensure the timely return of resources into the greater pool. The applications teams tend to have a different set of goals. They need an underlying operating system with a solid service level associated with it. They might also want to provision middleware, monitoring, security software, and other components into a multitier, often multi-vm, environment. They will typically load the application themselves but want everything else in place and working properly first. Since most application stacks, or even the underlying components, are not identical, a flexible provisioning solution is needed to serve these disparate teams. The IT team needs elements from both of these options. Business users usually need access to a wide variety of services, such as SharePoint and Microsoft Office. However, it is rare to find a user that requires access to the entire range of services. Therefore, it is easier for both IT and the user to limit the configuration options in order to lessen confusion and prevent underutilization. The key is to know the customer first, and then design the product. Otherwise, the result is a magical solution with no customers. Once the customer has been identified, it is time to design the cloud. Who should be involved in determining the design? These might include the virtualization administrator, storage manager, network manager, application development team, capacity planner, and server and database administrators. 2

4 Each of these people has a role to play in building even the most rudimentary cloud environments. Each is needed to meet the requirements of the cloud customers. The team will need to answer these questions:» Will there be a one-size-fits-all approach to the cloud services, where everyone gets the same amount of everything, or will the user be able to choose from small-medium-large sizing or some other parameters?» How much flexibility can a user have in commissioning resources along each dimension?» Will all users have the same options, or will some be limited in their choices?» How will service levels be tiered to address different performance requirements in the cloud environment?» How far up the stack will the cloud be provisioned? The final question is the critical one that pulls in the application team. Certain applications, intended for business users, will need to be provisioned and fully configured to be useful to those users. Consider instances of statistical software packages or R&D applications. Others clearly are the domain of a sophisticated user on the application team, such as a customer relationship management (CRM) or supply chain application. WHAT CHANGES, WHAT STAYS THE SAME Now that you have determined who should be involved in designing a cloud, what precisely has to change in order to make a cloud work? Fundamentally, everything has to change in a pervasive, non-disruptive way. IT often sees cloud as a clean slate upon which a whole new, well-run, solidly architected infrastructure can be built, unencumbered by the multitude of processes, poor decisions, and legacy madness that exists today. For some, the cloud feels like that opportunity, but for most, it is not. The switch to cloud does involve new, or reasonably new, hardware, storage resources, and network, as well as new stack elements such as virtualization. There are also often new components, such as customer self-service and the service catalog. However, cloud is still part of the IT infrastructure. It is still serving many of the same customers and hosting most of the same applications. It is still bound by the same security guidelines and audited according to the same regulatory compliance rules. It is probably even utilizing some of the architectural realities of the same datacenter, network configurations, procurement processes, and approval rules. All the processes that were built and policies that were created should move seamlessly to the cloud infrastructure. There is no need to redefine compliance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA) for the cloud and congeal those guidelines into governing policies. No need to start again with a change management process; just modify it to address the cloud use cases. No need to build a second configuration management database (CMDB) that would create potential redundancy and confusion; just add the cloud resources on top. A great deal does not have to change. But what can change? The speed of delivery of new services, the primary motivator for cloud, increases, and with the increase come greatly improved agility and flexibility to business demands. Layering and configuring the desired components of the service stack helps meet the different needs of a variety of users. This necessitates greater collaboration across IT. And finally, the hybrid footprint changes to leverage resources outside the organization to design a cost-effective and flexible environment. 3

5 HOW DOES IT ALL CHANGE? Cloud, even more than virtualization, has brought together infrastructure and software into a cohesive business service. Cloud treats these as converged resources. The machines are collaborating. The people, therefore, follow the machines and must also collaborate. THE RELATIONSHIP WITH THE USER The business user used to grapple with business analysts, forms in triplicate, and theoretical requirements. Now the user is on the other side of a portal. The users have become real far more plentiful than before. Given the proper initial planning, the infrastructure team has a better sense of their customer and the new set of processes needed to address the collaboration:» The request process moves to self-service.» The service design process is often led by a cloud service designer in IT, who works with users to define their needs.» The needs of the user are better communicated, as they consider their outside alternatives (e.g., Amazon Web Services) compared to their internal options from IT. THE RELATIONSHIP THAT DELIVERS THE SERVICE Servers, storage, and network are often lumped together as resources being provisioned as a conjoined pile. However, the stack extends upward now. Middleware, databases, application servers, Web servers, and enduser applications are all being defined as a single cloud service. Full stack is end-to-end collaboration of all the resources, both hard and soft, of IT. The process of service design extends to include inputs from not just infrastructure but also applications and platforms teams. The process of delivery is not just a VM clone activity but actual provisioning of the entire service needed. The process of configuration extends to include not only the VM but also the entire application stack in order to match the environment and the user s needs. THE RELATIONSHIP OF OPERATIONS Cloud also brings a great deal of collaboration among the ongoing operations of a cloud service: performance, capacity optimization, configuration management, and compliance. Resizing and moving of services, new provisions, new decommissions, and new services all impact operations in the environment. Consequently, a key set of processes is changed:» Identifying performance challenges and their root causes in location, change, and configurations» Placing new workloads based on capacity and compliance requirements» Maintaining cloud services in the private, public, or hybrid cloud Cloud does change everything. But, in doing so, it turns the organization into a collaborative team, working with the end user and business service at the forefront of IT operations. Cloud touches the entire gamut of IT. The cloud provides the opportunity to shortcircuit processes, grease wheels, and collaborate toward the goals of delivering quality, appropriate cloud services to meet business needs and streamlining IT operations for ongoing success. If everything is going to change, it may as well change for the better. 4

6 ABOUT THE AUTHOR Lilac Schoenbeck is Director of Cloud Computing Marketing at BMC Software. She has more than 12 years of experience with product marketing, strategy, business development, and software engineering in the grid, virtualization, and cloud domains. Schoenbeck has worked for IBM, Fortisphere, Innosight, and the Globus Alliance, and she holds an MBA from MIT Sloan School of Management and a computer science degree from Pacific Lutheran University. BUSINESS RUNS ON IT. IT RUNS ON BMC SOFTWARE. Business runs better when IT runs at its best. Tens of thousands of IT organizations around the world -- from small and mid-market businesses to the Global 100 rely on BMC Software (NASDAQ: BMC) to manage their business services and applications across distributed, mainframe, virtual and cloud environments. BMC helps customers cut costs, reduce risk and achieve business objectives with the broadest choice of IT management solutions, including industry-leading Business Service Management and Cloud Management offerings. For the four fiscal quarters ended March 31, 2013, BMC revenue was approximately $2.2 billion. *441410* BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners BMC Software, Inc. All rights reserved.