Creative Shorts: Twelve lifecycle management principles for world-class cloud development Foundations for optimal development on and for the cloud A Creative Intellect Consulting Shorts Report Series (ALM) In this report from our Creative Shorts series on Application Lifecycle Management, we suggest principles for Cloud development and lifecycle management that will ensure maximum benefits for multiple Cloud computing models. Bola Rotibi, Research Director, Creative Intellect Consulting Ian Murphy, Principal Analyst, Creative Intellect Consulting January 2012 Creative Intellect Consulting Ltd 2012 Page 1
Shorts Overview IT budgets get tighter every year. Simultaneously, in order to stay competitive, business units are demanding greater flexibility, responsiveness, and accountability from IT. This means shorter delivery cycles and increased pressure on delivering low cost, high quality solutions. Cloud computing is seen as a model that can help IT organizations to efficiently deliver quality solutions which are more in-line with business needs and change dynamics. Already, the Cloud computing model is proving itself effective for software development and testing. As we move towards extensive delivery of Cloud services and applications, especially within the corporate market, IT organizations will need to make Cloud development and lifecycle management a first class focus rather than a bolt-on to existing IT practices and processes. The demand for Cloud development and lifecycle management principles Much of the emphasis around Cloud benefits has focused on cost transparency. What has not been talked about significantly is how IT teams should align or modify their existing development and lifecycle management processes for Cloud development and deployment. More specifically a Cloud development and lifecycle management process strategy is required to: Improve IT and Business engagement: In many organizations the backlog of delivering new functionality is the driver for business units to look elsewhere. However, stepping outside the remit and governance control of the IT organization even to address immediate needs and productivity concerns creates hidden challenges for both the business and IT. Most notable are the increase in IT complexity and the overall reduction in the long-term scalability and performance of application systems. Often referred to as Shadow IT the act of sourcing IT requirements and functions without the knowledge or collaboration of the IT organization places pressure on integration, data access and management, and long term maintenance. All of this creates a financial drain raises a technical debt that must be cleared at a later date and causes a drag on business agility. Cloud-based development models look to address the productivity gap by delivering a development and tooling framework and infrastructure that focuses on ease of configurability and use, whilst retaining the integrity of coding and governance policies, performance and scalability requirements, and underlying security rules. This remotely managed and maintained environment means that IT teams can focus on how technologies can be applied and applications created to meet the needs of the business rather than the skills required to implement complex technology configurations or address operation concerns. Employ the most effective processes and team structure: The managed environment of Cloud development services establishes a separation of skills, role functions, and development concerns. Specifically, the abstracted configuration and declarative development framework typical of a Cloud development service will allow business domain experts greater involvement in the application development process. Not only will this change team dynamics, but it must be managed well to ensure that people with the right skill focus and development capabilities are assigned to the right areas. All of the above requires a reevaluation of key development process dynamics and governance strategies. The separation of concerns instilled by Cloud services will require a more dynamic and lightweight governance model and realignment of ownership and responsibilities within the lifecycle management process particularly around design and release management. It will also require greater awareness of the propagation of updates to the Cloud development service to ensure application behavior and performance is not disrupted and enhancements are adopted in future application design. Creative Intellect Consulting Ltd 2012 Page 2
Maximize the Cloud development and testing models: Moving to the Cloud can open up considerable challenges for organizations. Unless IT teams plan their cloud development processes carefully, they are unlikely to maximize all of the benefits and opportunities from the various Cloud computing models and Cloud-based development and testing strategies. Worse still, IT teams may in reality overburden the development and delivery processes with unnecessary detail, negating the potential for business process and application innovation, and lessening the gains in improved development quality, delivery speed, and cost savings that the Cloud computing model can provide. Apply the most appropriate execution methodologies: Improved development and delivery speeds are some of the benefits of the managed environment of a Cloud development service. Ensuring the right development methodology to manage the dynamics of development and delivery will be important. Cloud is a perfectly viable deployment platform for enterprise applications and should be considered as part of any application deployment option. But in order to get the most from the Cloud, IT teams need to ensure that they bring it into their existing processes and governance approaches, making acceptable adjustments to those processes where necessary. Cloud software development and lifecycle management in a nutshell Four Cloud deployment models There are four main Cloud delivery models supporting the Cloud development service strategies that have so far been established. Each of these models is being used to deliver applications today but with significant differences, especially around process and lifecycle management: Private Cloud: This can be either wholly owned and operated by the enterprise IT department or operated by a third party. A private Cloud means complete control over processes, services, or applications that are installed, all of which can be applied as and when required. It is the existing datacenter evolved. Public Cloud: This model is little more than a resource sharing option. Access to a virtual machine (VM) is acquired for IT teams to install their applications. There may be some shared services available to them, but they will be required to manage key services such as backups. There is no control over the platform and a service level that is likely to be no more than 99.9% at best. It s regularly used by development teams when they need to extend their test and development platform. While easy and often cheap to configure, the lack of controls and processes around the platform are significant governance failings. Hybrid Cloud: This is a combination of private and public managed Cloud services. It is most commonly used to either deploy part of the enterprise stack onto the Cloud while retaining core applications inside the datacenter. The most common use is to provide additional resources for when demand internally outstrips capability especially during sudden surges. Here applications or application instances that have been moved into the cloud are started when user demand suddenly grows. Often referred to as Cloud bursting, teams have little control over the processes for managing the underlying Cloud platform. Typical use is the deployment of a new business website where it is hard to predict demand and the worst case scenario is having the website offline due to excessive demand. Another use has been to deal with surges of internal application use such as email or to move less critical applications away from the core datacenter hardware. Managed Services Cloud: Run by a third party who provides access to applications and resources, such as disaster recovery, shared application platforms, and for high availability. IT teams do not own the applications. They simply have a private instance on what is a multi-tenanted environment. Creative Intellect Consulting Ltd 2012 Page 3
Patching and upgrading are carried out by the Cloud owner and there is no control over this. Enterprise IT departments often move test and development environments onto a Managed Service Cloud platform because of the higher performance of the platforms and access to testing tools and services on demand. Third party control, however limits the extent of internal governance and process control models. Four Cloud development strategies There are four models for Cloud development strategies which should be matched to both your existing development processes and your development budget. Model 1: Hosted, managed development, and deployment: The Cloud platform provider provides the integrated environment for developing applications (Application Platform) and the runtime on which those applications are executed (Platform as a Service PaaS). A typical example of this model is Salesforce.com s Force.com platform. Model 2: Develop locally, deploy locally, and/or to the Cloud: The Cloud platform provider has a deployment platform that closely matches the platform used internally by the IT team. This allows them to develop applications using their existing tools and then choose where they want to deploy them. An example of this is Microsoft Visual Studio where development teams can choose Microsoft Azure as a target for applications to be deployed to at the end of the development process. Model 3: Cloud-based augmentation of tools portfolio: Using tools from the Cloud platform provider to extend the IT team s existing development tools portfolio. This is a common model for Cloud test provisioning services and Cloud-based delivery of Source Configuration and Change Management (SCCM) facilities. It is a particularly useful model for those who want a more flexible and cost effective way of accessing the latest versions of the tools or who want to be able to provision multiple environments and expand their testing scope and performance loads. Model 4: Open development and deployment: In this model, IT teams develop their application either locally or within a Cloud development platform, but with no restrictions on where the application might finally be deployed i.e. locally, within the same Cloud platform it was developed on, or on an alternative Cloud platform. While there is no commercial option here as yet, the Simple API for Cloud Application Services is working on making this happen. Provided IT teams are not planning to use any services provided by the Cloud platform provider, this model will allow them to develop anywhere and simply deploy inside the virtual runtime environment of any supporting provider s Virtual Machine. Cloud development and lifecycle management foundations: Once IT teams have decided on a model for Cloud development they will need to address a complex set of issues that change depending on the model chosen. These focus areas form the foundations for Cloud development and lifecycle management concerns and require an adaption of existing approaches: Application architecture Development and delivery process Developing for virtualized platforms Analytics and instrumentation Portability and security Release, change, and deployment management People and roles Creative Intellect Consulting Ltd 2012 Page 4
Guidance strategies Cloud platforms, as explained above, use Virtual Machines (VMs) as the application container and the widespread use of virtualization means that applications are already been deployed into VMs. As a result, the basics of deployment are known, therefore the challenges center for the most part on process and lifecycle management. In many ways, Cloud is not a big bang change to software development and delivery. Whilst there may be differences in the dynamics of the management and governance processes, many of the principles for developing and delivering application remain unchanged. As with any other development strategy, proper planning and testing must be part of the Cloud adoption process. While it might appear easy to just jump in and use it, past lessons from adding mobile applications and even web-based applications to the enterprise, demonstrate that haste is not only inefficient it can be very costly. Cloud is expected to reduce costs so plan, experiment, and choose your applications to deploy to the Cloud carefully. In addition to the criteria outlined in the Cloud development and lifecycle management foundations above, IT teams need to consider the directions listed below. People and processes: Once you have decided you want to move to the Cloud you need to treat it as any other platform on which you would develop applications on or deploy them to. Process and governance still vital, but a change in dynamics required: The application lifecycle management governance model is still an important requirement in ensuring the quality delivery of applications that customers want and expect. However, the increased pace of development and delivery that can be achieved through Cloud development services, and the widening of the development pool with the involvement of less traditionally skilled developers, calls for a different approach to the governance process. Greater agility as a result of more direct interactions between the development team and its clients requires a level of governance control to ensure that strategic goals are upheld. More importantly the governance processes can prevent inefficiencies and reduce complexity from unnecessary application extensions as a result of business domain experts being better able to participate in the application development and configuration process. Review lifecycle management support services: Change Management, Configuration Management, and Release Management all pose specific challenges as you may no longer own or control the platform. However strong management controls and clear visibility into the change processes remain vital. Look at what elements of your existing processes you can adapt. For example, with Configuration Management you can still change the resource level for the VM. With Release Management you can control how the VM is configured but not dictate the underlying hardware platform. If you are ITIL compliant, you will need to find out what is supported by the Cloud service provider and how it can be integrated into your monitoring console. Where there is a mismatch between the existing policy and what can be supported by the Cloud model you have chosen, you need to then define rules as to what applications can be developed and deployed onto that platform. Prepare for a change in team dynamics, skill distribution and a blurring of capabilities: The managed environment of most Cloud development services delivers a framework that broadens the scope of the developer audience and skill set. As business domain professionals and business analysts are able to participate in the configuration and development process it will require careful deployment of the right skill sets for specific development and deployment requirements. Employing business domain professionals as power users for configuring applications will reduce the development burden for more traditionally skilled developers. It will allow the latter to shift their Creative Intellect Consulting Ltd 2012 Page 5
focus onto more complex development and integration requirements. However the blurring of the developer and business role will create challenges with respect to ownership and responsibility. Understanding the architecture of any applications you intend to migrate: Lower costs are a key Cloud benefit. Inside the datacenter you do not pay for network traffic but in the Cloud you do. If you have a highly distributed application you will need to reconsider the architecture to see if the components can all sit on a single VM. Expect to re-architect for the Cloud: With Cloud development, IT teams need to completely rearchitect their applications and resolve any dependencies that might apply or start from scratch with a fresh approach. It will require a greater emphasis on the upfront design phase. The IT team will also gain from having a good knowledge of developing scalable distributed applications. Those used to building large scale successful web and e-commerce applications will already have in place a lot of the skills, development and lifecycle management processes for taking advantage of the Cloud model. Integration complexity does not go away: Few Cloud developed solutions will work in isolation. Integration dependencies with legacy application systems and infrastructure services will raise the complexity that could see a slowdown in execution and delivery especially in the face of poor governance controls. This is all the more reason for appropriately targeted governance and process execution models. Greater business savvy from the development team: Cloud development services on the whole promote greater engagement with the business and client stakeholders. This will require teams to be more conversant in the business processes, commercial goals, and customer satisfaction measures. This is especially important for identifying risks in the development process and application service as a result of client or business requests. Agile lifecycle practices align well with Cloud development and delivery: In environments where a mix of process methodologies are employed, it will be important to assess the methodology that is most appropriate for developing on and deploying to the Cloud. Agile and iterative development processes naturally align well with the fast pace of Cloud development environments and application delivery. But Agile and iterative practices must be applied consistently across the lifecycle to minimize the disruption of bottlenecks within the execution process. It will be important to assess whether your organization is capable of and able to adopt methodologies that fit best with Cloud development and deployment. Collaborate and communicate: Extensive use of a single Cloud platform is an opportunity to treat the Cloud provider as part of the line-of-business processes. Shared repositories for analytics and problem solving should include Cloud provider as a separate role. A Cloud platform provider s support services are likely to be of a different level to an organization s on-premise development tools provider. Even when using services provided on the Cloud platform, the team may have to rely on email rather than phone support and response times in days rather than immediate. A Cloud provider s support services are critical to the overall satisfaction of a Cloud development service. Tooling and technology strategies: Much of the Cloud preparation tooling already exists within the datacenter. Management suites, analytics, virtual machines, application architecture design tools, and development tools are already inside the datacenter. The changes here to tooling strategies are around planning for deployment of existing applications and development of new applications, especially those delivered through Cloud development platform providers. Creative Intellect Consulting Ltd 2012 Page 6
Monitoring and analytical tooling will help assess Cloud development and lifecycle management strategies: Without understanding existing applications it is possible to incur excessive, unplanned costs when moving to the Cloud. This is where the use of analytics and workload profilers is critical in the preparation stage. Use of deep analytics to understand application lifecycles and resource usage: this will show the resource demands and workload demands of an application over an entire lifecycle. Understand the Cloud development environment and provider: Take into account any limitations in their service offering. Look to support out of the box services and tooling to minimize spent effort and allow for new approaches that focus more on the requirements of the business process than limitations in the deployment environment. Existing application architecture and lifecycle management were designed for an environment you own. In the Cloud, that is not the case. While not precluding the migration of existing applications, it makes a better case for developing applications from new when adding Cloud as both a development and deployment platform. Put in place a tooling strategy for addressing both Cloud and on-premise environments: Not all applications will be suitable for Cloud deployment nor will all IT teams look to transition their entire development stack to the Cloud model. Therefore it will be important to evaluate your tooling strategy in line with your Cloud and on-premise requirements and commitments. Some vendors are bringing in development tools accessed via the Cloud or installed on-premise that can be used for both on-premise and Cloud base development, allowing the developer to set the target deployment environment for the developed application at the start. The tool then takes care of all the underlying configurations for the respective deployment environment. Business engagement The business case for any development strategy or application requirement must always be made. Before planning any development around the Cloud model, IT teams need to decide on why they are going to the Cloud. More specifically IT teams need to ensure that their development and application strategies do the following: Align with strategic goals of the business: New applications need to add business value and satisfy customer and business expectations. The fast pace of delivery mean that new features can be quickly added but may not necessarily deliver to the wider business goals. Deliver confidently and demonstrate the value proposition and potential by starting small: Prove to the business and other key stakeholders the capabilities of a Cloud development strategy and service and raise the level of confidence by extending the services that work successfully for the organization. IT teams must ensure that they can monitor Cloud based applications from within existing management tools. They therefore need to understand the impact on costs of all the management traffic. New forms of Service Level Agreements (SLAs) will need to be created and ways to effectively monitor those SLAs must match existing control processes. Creative Intellect Consulting Ltd 2012 Page 7
About Creative Intellect Consulting Creative Intellect Consulting is an analyst research, advisory and consulting firm founded by Bola Rotibi, an experienced and renowned expert analyst in the field of software development, delivery and lifecycle management processes, technologies and tools. The company s key areas of analysis are software development, delivery and lifecycle management across the Software and IT spectrum along with their impact on, and alignment with business. At Creative Intellect Consulting we combine our independent technology and supplier expertise with our knowledge of enterprise needs to help vendor clients: optimize their market propositions position themselves against the competition validate their solution definitions and roadmaps For end-user organizations, our research reports and consulting services help to make technology choices and implement strategies that are right for them whilst maximizing the value from existing software investments. We pride ourselves on our accessibility, flexible approach and high levels of knowledge and experience. Read more about our services and reports at www.creativeintellectuk.com Creative Intellect Consulting Ltd 2012 Page 8