In part one of this series, we discussed the beginning of the Executive Breakfast sponsored by NVISIA on May 24, 2016, in the Willis Tower in downtown Chicago. Software development professionals from different industries gathered to share stories about their implementation of various DevOps practices. NVISIA's own Dru Henke presented on what, exactly, "DevOps" means, and then Clyde Balneaves from Accuity shared details of how his company was able to complete more than 7,000 build/release cycles using these methods.
During the second half of the breakfast, NVISIA asked four panelists to talk about their experiences with Agile development and DevOps. Balneaves and Henke joined two distinguished Chicago IT executives, Len Servedio and Casey Hossa, to discuss the ins and outs of continuous deployments and the impact of adopting DevOps had on their projects and organizations. Servedio serves as the divisional vice president of application development, QA and architecture at Dearborn National, and Hossa is a divisional vice president at Blue Cross and Blue Shield of Illinois, Montana, New Mexico, Oklahoma and Texas.
Some of the discussion topics included: business drivers for accelerating software release cycles, the relationship between Agile and DevOps, how to break up monolithic applications into RESTful APIs or microservice architectures, and the role of DevOps in driving a shift in focus from project to product.
Here's a more in-depth look at these topics:
"DevOps is the foundation for the cultural changes required to make Agile work."
Business drivers for accelerating software release cycles
This is a recurring theme from the "business side" of any organization – there are tangible reasons applications are created in the first place, and if it takes too long to build and release these products, there could be real consequences related to revenue and profitability.
DevOps vs. Agile: What's the relationship?
DevOps and Agile development aren't the same thing, but they work together to accelerate development cycles while ensuring better products that customers actually need. Agile grew out of a need for shorter feedback cycles between developers and business users while DevOps creates the foundation for the cultural changes required to not just align business and development, but accelerate software development cycles across business, development, QA and technical operations. The common goal is to get the cross-functional team's product in front of real users quickly. So, if you want better software released faster, both Agile and DevOps are necessary.
Breaking up monolithic applications
The panelists agreed that in order to speed up delivery cycles, large monolithic applications that traditionally ran on a mainframe or unix/windows application servers must be broken up into smaller, independently deployable parts. Hossa and Servedio both commented on how they started adopting service-oriented architectures many years ago to break up their large operational systems. Now in the move to the DevOps world they are using RESTful services and looking at microservice architectures with container-based platforms for service development, deployment and management.
The appeal of microservices is how they run independently as a separate component to a pieceof software, according to DevOps expert Martin Fowler, allowing these services to be independently deployable.
Where's your focus: Project or product?
One topic addressed in the DevOps panel discussion was the shifting focus from the project toward the product mindset. While Agile techniques began introducing concepts like product, product backlog and product owners, DevOps cross-functional teams now rally together to deliver the entire product over its lifetime. This differs from the project mindset where business threw a requirements specification over the wall to development, who then threw their code over the wall to QA and then QA to operations. This process not only took a long time, but created a committee-like atmosphere where the business owned the specs, development owned the code, QA owned the bug resolution and operations owned the deployment platform ... But no one owned the overall success of the finished product and associated customer experience! There is where the difference lies – the product focus promotes the overall success of the product and associated customer experience the primary daily responsibility of everyone on the team.
The process itself, too, feels different. When you start with the business case and employ a cross-functional team – no silos here! – to take the product from inception to production, you get better software faster and a product that has been tested at every step of the development process.