Enterprise IT is struggling to meet the needs of the business, and I wish I could give you a pill to just fix it. I can certainly give you software, and that will take some of the pain away, but the big improvement needs to be in peopleware and culture. Building and deploying software requires considerable collaboration and coordination by different people, teams and organizations. DevOps is a cultural movement focused on removing the barriers between the teams and organizations to deliver more value to the business faster. You can’t just buy DevOps, you have to also transform this culture.
At last week’s Serena DevOps Drive-in webcast, I spoke with Mandi Walls from Chef about keys to building a successful DevOps culture. During the webcast, we asked the attendees what the biggest barriers were for DevOps adoption, and the majority said it was lack of collaboration and cultural barriers (see chart).
Want to learn more? Check out the recording of Mandi’s “5 Keys to Building a Successful DevOps Culture” presentation. It will provide you with practical guidance on removing those barriers and accelerating your DevOps adoption.
I recently attended DevOpsDays Austin 2014 and was very impressed by the event as a whole. The conference format provides a great medium for the attendees. The combination of thought leadership and technical presentation tracks along with Open Space discussions and Ignite talks, makes the two day event both informative and very interactive. Here are my three key takeaways from the event:
1. DevOps culture is still a big topic of discussion. Tools are a great enabler, but as the opening keynote speaker Andrew Clay Shafer (@littleidea), says in his post presentation interview, you can’t buy DevOps. In Andrew’s opening keynote presentation, he shows how different languages and tribal signaling leads to disconnects in both business and technical organizations.
Culture was another discussion point in the Enterprise DevOps open spaces I attended. There was a great discussion on how to get teams, organizations and management buy in. Whether you drive cultural change from the top down or bottom up, it is all about the people. Tools can influence behavior and help change culture, but “peopleware” is just as important as software. Clearly, this is a big topic that needs further discussion. In fact, we featuring Mandi Walls from Chef at our next DevOps Drive-in talking about this very subject.
2. Enterprise DevOps still lacks maturity. We need to continue developing the “how:” the patterns and best practices of DevOps for the Enterprise. Matt Ray (@mattray) provided a very good maturity lifecycle in his presentation “Helping Horses Become Unicorns.” He covered topics such as hardware management, OS management, infrastructure management, software deployments, incident management and even disaster recovery and postmortems, stressing both business and cultural issues. His assertion is that it is possible to transform a horse into a unicorn. I would say that enterprises don’t even need to become a unicorn. A faster, stronger horse FTW!
3. DevOps has not yet crossed the chasm but it’s getting a big push. Michael Cote (@cote) from 451 Research delivered a good presentation on “When is the DevOps Unicorn Going to Sprout Wings and Fly.” Cote mentions that over the next 10 years, mobile and cloud will initiate a massive rewrite or re-platform of applications, and that is demanding a new way of delivering software (DevOps). Cote reviewed the results of a 451 Research DevOps survey that gives a good view into the maturity of mainstream IT. His reference about white collar toolchains (e.g., Word and Excel) that don’t use version control rings so true. What I found particularly interesting is that almost 40% of the companies surveyed said that the one thing preventing them from reducing cycle times is human resource constraints. I think delivering on the DevOps principles (CAMS) would help with this constraint because the high performing organizations that I’ve seen are doing more with less and not more with more.
DevOpsDays is a great event organized around trying to solve a real hard and present problem. If you are involved with deploying or releasing software from development to production, I recommend you head to your local DevOpsDays event to see what the tip of the spear looks like. And, for a special event, join Serena at the special 5th anniversary of the founding of DevOpsDays in October in Belgium. It’s also the 5th anniversary of the first use of the term “DevOps,” selected as the hashtag for that first event by legend Patrick Debois.
For our May DevOps Drive-In webcast, we’re delighted to feature Mandi Walls, author of the eBook “Building a DevOps Culture,” published by O’Reilly. Mandi is a Technical Practice Manager at Chef and travels the world helping organizations increase their effectiveness using configuration management and modernizing IT practices.
She will join me in a discussion on the impact that culture has on driving successful adoption of DevOps practices. Register and join the webcast to participate in the live Q&A with Mandi and me, as this is sure to be an interesting discussion filled with tips and tricks for identifying cultural barriers and tearing them down.
CloudBees is a Continuous Delivery solutions provider and the Jenkins expert for the Enterprise. With CloudBees focusing on Continuous Integration and Serena Software being the expert in automating application deployments, this partnership provides a great integrated value chain for Continuous Delivery in the Enterprise.
I’m often asked, “How do you implement Continuous Delivery in the Enterprise?” Continuous Delivery (CD) can seem like an unattainable goal for many IT organizations. The first thing we need to do is to make sure everyone understands, “What is Continuous Delivery?”. I like how Martin Fowler describes it. Martin also states, “Continuous Delivery is sometimes confused with Continuous Deployment. Continuous Deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day. Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment. In order to do Continuous Deployment you must be doing Continuous Delivery.” Enterprise IT usually breathes a sigh of relief once they understand Continuous Delivery does not mean Continuous Deployment because in many Enterprise IT shops that is not going to happen, perhaps not even required.
So where do you start? We actually discussed this question in our April DevOps Drive-in. In fact, we asked the attendees, “Where are you on your Continuous Delivery journey?” The results were a bit surprising as only 8% said they had no plans to implement Continuous Delivery. Most were in the process of implementing Continuous Delivery and 25% are planning to implement it in the future.
To learn more and see a solution demo check out the recording of this DevOps Drive-in “Achieving Continuous Delivery in the Enterprise, powered by Serena and CloudBees” or visit us at the next Jenkins user conference in Boston on June 18th.
I’m not a golfer but every golfer has their favorite, most dependable iron. In Enterprise IT, its the mainframe. The mainframe has lasted over 50 years because of its resilience, dependability and because it just runs! The problem is that if you mention the word “Mainframe” to most IT professionals today their eyes glaze over and they get totally confused when terms like CICS, IMS or ISPF are mentioned. Deploying composite apps that have mainframe artifacts is currently an art reserved for the highly skilled. Serena Software recently held its quarterly Mainframe Virtual User Group and gave a demo on how Serena Release Manager’s Deployment Hub automates ChangeMan ZMF package deployments from a simple, easy-to-use graphical editor. Something any duffer like myself can do at a moment’s notice!
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!