Whenever the words “Continuous Delivery” and “Enterprise IT” are used in the same sentence it rapidly turns into a page or at least a paragraph. That is because “Enterprise IT” generally means a big, diverse set of heterogeneous infrastructures glued together across many teams and locations that use many different tools and processes to develop and deploy software. Each enterprise has its own unique DNA that has organically evolved through generations of applications and technologies with its own historic set of artifacts and processes that have weathered the storms of innovation.
Continuous Delivery’s goal is to find ways to deliver high-quality, valuable software in an efficient, fast and reliable manner. It’s an effective pattern for getting software from development to release. However, mapping a set of automated deployment pipelines across an entire enterprise can be challenging and in many instances may take years to achieve or may never happen completely. Does that mean you should not start implementing Continuous Delivery? Absolutely not. Continuous Delivery is an ideal, an end state with continuous improvement every step along the way. This is something we are going to discuss at the next DevOps Drive-in Webinar. Don’t miss out! Sign up for “Achieving Continuous Delivery in the Enterprise, powered by Serena and CloudBees” today.
Glenn O’Donnell, Principal Analyst at Forrester paid a visit to Serena Software headquarters in San Mateo, CA this week and joined us for our monthly DevOps Drive-In webcast. IT is in its own industrial revolution according to Glenn, in part because IT is currently too slow, has poor quality and customers don’t trust IT. This revolution requires an IT fitness program and not a weight loss program where IT becomes stronger, faster and more resilient. To improve quickly, IT needs to embrace Lean principles and methodologies.
Glenn provided an overview of how IT can leverage Lean value stream mapping and the DevOps principles of automation and culture to eliminate waste, increase quality and reduce cycle times. He also outlined the “Seven Habits of Highly Effective DevOps.” These habits are:
During the webinar, we polled attendees and asked them to select which of the seven habits they thought would be the highest priority to improve their organization. Below is a graph of the results.
The majority believes automation and establishing common values and awareness between Dev and Ops would provide the most improvement to their organization. I was surprised having developers on the front line of service support and implementing feedback loops scored so low. Changing the culture is harder to do but I do like the DevOps principle of shared accountability and the “If I’m awake, you are awake” mentality. If an operations person gets woken up early in the morning, the responsible developer should work alongside them until the problem is resolved. You would get faster MTTR and improve reliability and quality.
It was a great DevOps Drive-in. Thanks goes to Glenn and Forrester. Make sure you catch our next DevOps Drive-in webcast on April 23rd. We are teaming up with Cloudbees to discuss the challenges of Enterprise Continuous Delivery.
A couple of weeks ago I had an opportunity to attend Pink14, Pink Elephant’s ITIL conference, and DevOps Day LA in the same week. What an experience in contrasts. The ITIL crowd was made up of incident, service and release managers focused on process improvements to manage IT and mitigate risk. The DevOps crowd was system administrators in charge of moving the bits from development to production. It was all about speed, quality and revolution with the Sys Admins. While initially the differences were night and day, the more I listened to these very different groups, the more I saw an incredible opportunity and the need for both of these different views of managing IT to interlock and work more closely.
The ITIL V3 set of manuals is now 1900 pages, across 5 volumes and weighs 15 pounds. ITIL needs to lean out, optimize and leverage the DevOps Principles of Culture, Lean, Automation, Measurement and Sharing (CLAMS). ITIL is not moving fast enough and IT is still struggling! DevOps is just starting to catch the attention of the ITIL crowd. Serena Software was one of the few vendors evangelizing DevOps for the enterprise ITIL crowd. I actually gave a presentation on the subject to a full house. You can view the presentation here. So, there is a lot of interest from the ITIL folks on how we can move faster, be leaner and still manage risk.
In order for DevOps to work in the enterprise, the DevOps movement needs to provide practical and pragmatic ways to integrate and evolve the current enterprise culture, processes and infrastructure. It’s about going from point A to B. That is the challenge. Not sure you will be able to burn down the silos, at least not short term. I’ve seen people try and it’s very expensive. It has to be more about evolution, not revolution, and ITIL could provide the map or blueprint for that evolution.
On April 7, 2014, IBM will celebrate the 50th anniversary of the mainframe, marking an incredible achievement. In what some consider the biggest business gamble of all time, International Business Machines invested $5 billion ($35 billion in today’s dollars) in a family of six mutually compatible computers and 40 peripherals that could work together and be expanded in multiple combinations. Big Blue ended up adding 60,000 employees and 5 new major plants to support this new system. It has been the most important product announcement in the history of IBM.
In an industry where change and disruption happens every couple of years, the mainframe’s resiliency and continued evolution has both confounded industry experts (remember Stewart Alsop’s 1991 quote) and validated the wisdom of the world’s leading businesses that continue to invest and run their core businesses on IBM’s Big Iron, the gold standard of Enterprise Computing.
The IBM mainframe played an important role in early core banking systems, the first airlines reservations system, and even the Apollo missions to the moon. Applications written for the early mainframes can still run today on the newest mainframe hardware and operating systems. This backwards compatibility, which is unique in the industry, has enabled large enterprise companies to continue to derive value from past investment in application development.
Today, IBM has continued to evolve the mainframe, which is now used for cloud, big data, mobile, and social computing workloads. With its high availability and secure platform, the mainframe processes the majority of the world’s business transactions and stores the majority of the world’s business data.
Serena Software and the IBM Mainframe
Serena Software has a key place in the history of the IBM mainframe. Serena has been supporting the largest mainframe customers for over 30 years. Serena was founded in 1980 by Doug Troxel. Doug is still working on special technology projects as an active member of the mainframe development team, and he serves on our board of directors.
From the very beginning, the solutions we’ve developed have a common theme – change. We detect change, replicate it, prevent it, log it, control it, merge it, approve it, version it, and package it. We synchronize change, track it, audit and report on it, set alerts for it, make dashboards of it, deploy it, release it, and back it out when needed.
Our first product, Comparex, was designed to compare two data sources and highlight the differences. This is critical in all mainframe production environments for checking that changes have been applied correctly. From flat files to VSAM, DB2 and IMS, z/FS, HFS, and even XML data streams and AES encrypted files, Comparex compares “anything to anything.”
Our second product is now the company’s flagship solution, ChangeMan ZMF. Recognized by industry analysts at Gartner, Forrester, Ovum, and others as the leading solution for Software Change and Configuration Management (SCCM) on the mainframe, ZMF is the heart of the development infrastructure for more than 90 of the Fortune 100 companies. Without ZMF, many household name businesses would not be able to meet their compliance and governance audits.
Last week Microsoft introduced their new CEO, Satya Nadell. I always like to read the “memo to the employees” from a new CEO. It’s interesting to hear what inspires and motivates new CEOs and how they frame the mission and vision. Mr. Nadell states: “This is a software powered world” and “that software enables businesses to engage customers in more meaningful ways.” In order to achieve this, businesses require IT to deliver a competitive advantage, not once a year, but on a continuous rolling basis.
While new companies such as Amazon.com, Etsy and Facebook have designed and delivered a “Continuous Delivery” practice, they have been largely free and unencumbered from legacy processes, platforms and environments. Large traditional enterprises are not so lucky and require a strategy that transforms the legacy development and operational processes, methodologies and tools that support the complex hybrid infrastructure environments and platforms that are unique to the enterprise.
Continuous Delivery is a competitive advantage because it puts the release schedule in the hands of the business, not in the hands of IT. Getting there for the enterprise is a journey and requires a strategy. Join us on February 19 for a live webcast with Bola Rotibi, CIC Consulting’s Research Director. She will discuss the key challenges of achieving continuous delivery in the enterprise. Learn more and register!
Serena Software released Serena Release Manager v5 back in December and I blogged a brief overview of the features and functions of the release and how it can help organizations start to transform their culture and begin to support the main principles of DevOps. The results ultimately need to transform into improving operational efficiencies and being more responsive to the business. We have seen customers improve the speed of software delivery by 3x and at the same time improve their quality by 75% with the same resources available. CIC (Creative Intellect Consulting) has also provided us a product spotlight on Serena Release Manager v5. You can get their perspective right here.
Having spent many years of my career in both IT operations and application development, I’ve seen both sides of the problem. I remember quite vividly the late night weekend heroics onsite implementing a new release or being woken up at home on a failed release. I’ve also experienced the intense deadline pressure as a developer to deliver the new features that will help ensure that the business makes its quarterly number. From each perspective I always viewed the other team as … well, “the other team.” We rarely spoke unless there were problems or we were at the very end of the release, and I had no visibility into what that team was doing or needed until it was typically too late. We had a process but it was slow, cumbersome, and fragile to say the least. Does this sound familiar? Not much has changed since my days as a developer.
Everyone has a release management process, but the majority of customers we have talked to are unhappy with the current state of release management. That is why the DevOps movement is gaining so much traction. DevOps core principles of culture, automation, measurement, and sharing (CAMS) makes so much sense. Up until now, software vendors have focused solely on solving the “A” part of the problem – automation. Sure automation is important, required, and a great place to start and get some quick wins. But just automating deployments does not address the lack of collaboration, sharing, and visibility. Automating “garbage in” will only make “garbage out” faster. Yes, failing fast is better than failing slow, but I’d rather succeed fast, wouldn’t you?
With the introduction of Serena Release Manager v5, Serena Software becomes the first and only vendor to address the challenges of the complete release lifecycle. Serena Release Manager v5 allows companies to orchestrate their entire release lifecycle by bringing together release process management and application release automation in a single product. Serena Release Manager bridges the DevOps divide by integrating with existing tool chains, and by simplifying and automating handoffs across development, quality, and operations teams. By supporting continuous delivery and production deployments, Serena Release Manager creates a repeatable and consistent release process across distributed, cloud, and mainframe applications. Serena Release Manager v5 capabilities include:
The DevOps principles of culture, automation, measurement, and sharing (CAMS) support the objective of delivering customer value faster and more reliably. While it’s true that Serena Release Manager does not change culture, it does start an important transformation by eliminating the manual steps, botched handoffs, and poor communication that reinforce stereotypes, breed mistrust, and deepen silos. With the automation of previously manual and error-prone human tasks, and with the transparency of the release process across diverse silos, smart and capable Dev and Ops practitioners are freed up to do more value-added work, collaborate better with colleagues, and communicate more effectively up and downstream.
With Serena Release Manager, organizations deploy and follow a release process that is instrumented at every step. Cycle times and stage durations are automatically measured and reported, allowing organizations to focus on continuous improvement, delivering more customer value faster and more reliably. To see the latest version of Serena Release Manager in action, tune in to the live webcast and demonstration on Tuesday, December 17. Register now!