Tag Archives: ITIL

Making IT Go Faster – Forrester Research Sheds Light on How

By Kurt Milne

kurtmilne-cropToday’s IT managers face increasing pressure to be more responsive and move faster. However, most IT organizations have built their IT organization to promote control and safety. People, process, and tools have traditionally been deployed to strictly limit change in order to optimize service quality and efficiency. In fact many of the most successful IT organizations have built their reputation by deploying elements of ITIL or other control frameworks to ensure critical system uptime.

Latest Forrester Research lays out a path forward for IT organizations that want to increase agility without losing control

orrester coverIt is easy to say – “Let’s use the cloud to move faster and be more responsive to the business.” But how do those with investment in ITIL, or who have thoughtfully developed process control methodologies, adapt to new demands for speed? Demands forcing IT to do things it may not be comfortable with? A new Forrester study based on interviews with 265 IT professionals in North America and Europe sheds some light on the best path forward.

Forrester found that:

  • IT organizations are quickly moving to on-demand, dynamic IT infrastructure
  • Users demand faster provisioning and want IT to be easy to consume
  • Those companies that have already deployed more dynamic change models are moving away from a centralized CMDB strategy
  • Developers are the primary consumers of ready-to-use application middleware stacks
  • IT can support rapid change without sacrificing configuration, compliance, and governance controls

If you have investment in IT process maturity and are looking to improve IT agility and deploy more automation without sacrificing control, then read the full Forrester report.
—-
Follow @kurtmilne on Twitter.

The Evolution of the SDLC

By Kai Holthaus

kai_holthaus-cropThe definition of SDLC is changing. SDLC often stands for the “software development life cycle,” a methodology to develop and implement software, currently in use by many IT organizations. IT organizations have realized, however, that this narrow focus on software is insufficient in today’s IT service delivery.

Figure 1: The SDLC Continuum

Figure 1: The SDLC Continuum

In my opinion, the next logical evolutionary step for an SDLC is to look at a “solution development life cycle,” which not only considers functionality requirements for the software, but also requirements for the underlying hardware and infrastructure systems, such as storage or networks. Solution development focuses on a more complete solution, but there is still further to go in maturing the approach. Ultimately, SDLC should really stand for “service development life cycle,” with a goal of developing, implementing, maintaining, and supporting all aspects of an IT service in order to bring real value to IT customers.

Software Development Life Cycle
Project teams often use a form of a software development life cycle to provide functionality in the form of software to users. The goal of the SDLC in this form is to use repeatable, predictable processes that improve software development productivity and software quality. Project teams will commonly incorporate aspects of project management frameworks into the SDLC, because without effective project management, it is very easy to deliver software projects late and/or over budget.

This approach to SDLC typically uses a methodology that will take the software development through multiple phases, such as planning, requirements, design, building, testing, deploying, and maintaining. The phases may be organized in a waterfall model, in a spiral model, or a combination of the two. Additionally, project teams may incorporate rapid application development or agile methods, such as SCRUM. There are a number of publicly available standards that can be applied to the SDLC, such as ISO 12207 (the international standard describing the method of selecting, implementing, and monitoring the life cycle for software), as well as process improvement guidance, such as the Capability Maturity Model Integration for Development (CMMI-DEV) or ISO 15504 (Information Technology Process Assessment).

It is important to note that the software development life cycle is really only concerned with software functionality. The framework provides guidance for developing this functionality, regardless of underlying systems, such as servers or the network that the software will need to be functional. While the SDLC in this form might (and should) be describing the requirements for such systems, the provisioning of such systems is typically not a part of this form of the SDLC. This does not necessarily mean that these requirements are not addressed at all, but typically the project team deals with them in a very separate way. This can potentially lead to miscommunication and a lack of coordination between different groups, and eventually to poorly delivered results. Another pitfall in such an approach is that the infrastructure side is done in an entirely ad hoc way, which can lead to struggles for the project team to be forced to fix things up in production, or severely under-performing services, because the infrastructure cannot support what is truly needed.

Solution Development Life Cycle
In a solution development life cycle (sometimes also known as systems development life cycle), the scope of the methodology is expanded from a narrow focus on software functionality to include the underlying systems, such as hardware and infrastructure.  The SDLC in this form is seen as a process to develop an information system, aiming to produce a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, and is inexpensive to maintain and cost-effective to enhance.

The solution development life cycle approach will be similar to the software development life cycle, in that phases for requirements, design, development, building, testing, deploying, and maintaining will be defined by the project team, and in that guidance from project management methodologies or process improvement methodologies can also be incorporated. However, the focus here is still on providing software functionality to users and customers at a given point in time, and not business value in the form of delivering ongoing services.

The benefit of a solution development life cycle over a software development life cycle is that requirements for underlying systems are defined along with requirements for software functionality, and the entire solution will be developed, thus reducing the risk that these underlying systems can derail the delivery of the desired functionality late in the life cycle. The solution development life cycle therefore ensures a more complete view of how the software functionality is delivered, thereby improving the user experience.

Service Development Life Cycle
Further maturing the SDLC leads to a true service development life cycle, which, while still concerned with the software application(s) needed for success, focuses on the definition, design, build, operation, and improvement of a complete IT service, providing outcomes that customers want to achieve. This view is much bigger than the view being taken in the software or solutions development life cycle. The central idea is for the project team to figure out the end results that their customers need to accomplish and then deliver and manage IT services to achieve those outcomes.  This holistic approach requires the team to consider not only the technical aspects of the service, but also the non-technical aspects such as training, documentation, support, communications, or processes.

For Example…
Here’s an example to further illustrate the difference between these three approaches. Let’s take a look at a payroll application. When using software development life cycle methods, the project team’s focus is on functionality provided by the application. For instance, an improvement to the payroll application might be to expand state tax calculation from handling a single state to also include other states, because the company will now also open offices in more states. The focus is solely on the calculations in the software.

Moving to the solutions development life cycle approach, more aspects are looked at for this change. Since adding this functionality most likely means more users and more employee records being managed by the application, the project team would also consider additional space requirements for the database storing the information about employees, additional network bandwidth that may be required for additional users, and more CPU power being needed for those users.

Taking a service development life cycle approach would require that the project team understand the outcomes customers want to achieve (e.g., “process payroll for all employees”), taking a holistic view of the current IT service landscape, and then determining how those outcomes can be best achieved within that landscape. Besides just application functionality, other aspects of service delivery come into focus, such as availability or continuity requirements, training, support, and even marketing new capabilities in the organization.

In conclusion, the evolution of the SDLC takes us from the traditional “software development life cycle” with its focus on developing and implementing functionality provided by software to defining, designing, implementing, and maintaining services that provide value to IT customers. Doing so means expanding the processes and roles described in these life cycles to ensure this value can be realized.

====
Kai Holthaus is a transformation consultant with VMware Accelerate Advisory Services and is based in Oregon. Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags

DevOps and All The Other “Ops Religions”

By: Kurt Milne

I didn’t wake up yesterday thinking, “Today I’ll design a T-shirt for the DevOps Days event in Mountain View.”  But as it turns out – that is what happened.

Some thoughts on what went into my word cloud design:

1. DevOps is great. This will be my 4th year attending DevOps Days.  I get the organic, bottoms up nature of the “movement.” I’ve been on the receiving end of the “throw it over the wall” scenario. A culture of collaboration and understanding go a long way to address the shortcomings of swim lane diagrams, phase gate requirements and mismatch of incentives that hamper effective app lifecycle execution. Continuous deployment is inspirational, and the creativity and power of the DevOps tool chain is very cool.

2. EnterpriseOps is still a mighty force. I remember an EnterpriseOps panel discussion at DevOps Days 2010. The general disdain for ITIL, coming from a crowd that was high off of 2 days of Web App goodness at Velocity 2010, was palpable. The participant from heavy equipment manufacturer Caterpillar asked the audience to raise their hand if they had an IT budget of more than $100M. No hands went up in the startup-dominated audience. His reply – “We have a $100M annual spend with multiple vendors.” The awkward silence suggested that EnterpriseOps is a different beast. It was. It still is. There is a lot EnterpriseOps can learn from DevOps, but the problems dealing with massive scale and legacy are just different.

3. InfraOps, AppOps, Service Ops. This model developed by James Urquhart makes sense to me.  It especially makes sense in the era of Shape Shifting Killer Apps. We need a multi-tier model that addresses the challenges of running infrastructure (yes, even in the cloud era), the challenges of keeping the lights on behind the API in a distribute component SOA environment and the cool development techniques that shift uptime responsibility to developers, as pioneered by Netflix. Clear division of labor with separation of duties, and a bright light shining on the white space in between, is a model that seems to address the needs of every cloud era constituent.

4. Missing from this 3-tier model is ConsumerOps. Oops. Too late to update the shirt design. Many are consuming IT services offered by cloud service providers; there must be a set of Ops practices that help guide cloud consumption. Understanding and negotiating cloud vendor SLAs and architecting multiple AWS availability zones immediately come to mind. Being a service broker and including 3rd party cloud services as part of an integrate service catalog is another.

5. Tenant Ops. As far as I can tell, this term was coined by Kevin Lees and the Cloud Operations Transformation services team at VMware. See pages 17 and 21 in Kevin’s paper on Organizing for the Cloud. It includes customer relationship management, service governance, design and release, as well as ongoing management of services in a multi-tenant environment. VMware internal IT uses the term to describe what they do running our private cloud internally. They have a pie chart that shows the percentage of compute units allocated to different tenants (development, marketing, sales, customer support, etc). It works. It may be similar to ServiceOps in the three tier model, but feels different enough, with a focus on multi-tenancy and not API driven services, to deserves its own term.

6. Finally CloudOps. This term is meta. It encompasses many of the concepts and practices of all the others. This is a term that describes IT Operations in the Cloud Era. Not just in a cloud, or connected to a cloud. But in the cloud era. The distinction being that the “cloud era” is different than the “client server era,” and implies that many practices developed in the previous era no longer apply. Many still do. But dynamic service delivery models are a forcing function for operational change. That change is happening in five pillars of cloud ops: People, Process, Organization, Governance, and IT business.

So while some of the sessions at this year’s DevOps conference are focused on continuous deployment. I’d bet that all the topics of the “Ops religions” will be covered.  Hence the focus on the term CloudOps.

We’ll be live tweeting from DevOps next Friday. Follow us @VMwareCloudOps or join the discussion using the #CloudOps hashtag.

Consider joining the new VMUG CloudOps SIG or find out more about it during VMUG June 27th webcast.