Home > Blogs > VMware Operations Transformation Services > Tag Archives: software development life cycle

Tag Archives: software development life cycle

VMware vRealize Code Stream: Is DevOps Tools or Transformation?

By Ahmed Al-Buheissi

Ahmed_croppedIn a previous blog, I wrote about the need for DevOps to rapidly release software and argued that DevOps is first and foremost about transforming operations.

The Operations and Development teams can be a roadblock to each other’s work schedule. The Development team frequently requires infrastructure and platform to test their code, while Operations does not always have the resources readily available to satisfy Developers’ requirements. This means schedules slip and releases become few and far apart, resulting in dissatisfied developers.

Since that blog, VMware released VMware vRealize Code Stream for facilitating DevOps, which I spent some time recently installing, configuring, and exploring—and I wanted to share my experience with you. Amazingly, I found that VMware’s response to DevOps is a tool that can be described in three words: automate, automate, and automate. Yes, vRealize Code Stream automates the entire software release process:

  • Infrastructure provisioning automation
  • Software build automation, and
  • Testing cycles automation

And these automation steps can be executed across all environments: Development, Testing, Staging, and Production, with the premise that automation will ensure consistency across all environments and prevent issues due to human errors. The figure below shows examples of tools used in software development, and how vRealize Code Stream integrates and automates these tools.

vRealize Code Stream SDLC

 

So is it all about the tools?
There are several tools available that will assist in implementing DevOps, including VMware vRealize Code Stream. These tools can automate and expedite the software release process, and apply the organization’s policies. But is that all there is to DevOps? As this is a new paradigm and a new way of operating, the organization will also need to transform. After all, DevOps disrupts the Software Development Lifecycle (SDLC) as we know it:

  • The process is not always linear (or circular); for example the Design phase does not always precede Implementation; sometimes the design is written as the code is being developed.
  • Testing cycles (Unit Testing, System Testing, and User Acceptance Testing) are executed concurrently, and will test only random pieces of code.

Organizations implementing DevOps must also apply operational methodologies, which will clearly define the transformation processes and document the evolving roles within the IT organization.

Why transform operations?
Even though the deployment and release processes are automated, we still need to tranform operations from both people and process perspectives, including:

  • The need to define the relationship between Operations and Development (as well as other teams). Development will depend on Operations only when creating the automation workflows, and subsequently they can release the software themselves using these scripts. Operations will focus more on automation project work, and much less on reactive day-to-day operations.
  • While the focus is on automating the release process, there is little emphasis on post-release monitoring. Developers need to have access to monitoring tools to ensure deployed software is performing adequately.

To conclude…consider these operations-related steps prior to adopting tools to implement DevOps:

  1. Determine the scope of your DevOps implementation; which teams, which applications, and which environments will be impacted.
  2. Document the process that will govern the interactions between various DevOps tasks and roles.
  3. Define the roles, for example Development, Operations, and Quality Assurance, as well as their responsibilities.

The figure below depicts the process of implementing DevOps, and steps required to roll out such environment.

DevOps Blog2_Implementation_Process_v0.1

 

Also, this short video below will provide you with high-level information about VMware vRealize Code Stream, along with technical white paper: “Releasing High Quality Applications More Quickly with vRealize Code Stream.”

====
Ahmed Al-Buheissi is an operations technical architect with the VMware Operations Transformation global practice and is based in Melbourne, Australia.

Code-stream-video

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