Key Characteristics of a Modern Software Delivery System
Overview: In the first episode of Compuware’s podcast series, Building a Better Software Delivery Platform, DevOps Solution Architect Rick Slade covered the key characteristics of a modern SDS and how organizations, regardless of their industry, can benefit from its implementation.
Last week I had the privilege of talking to Compuware Executive DevOps Solution Architect Rick Slade in the inaugural episode of Rick’s new series, Building a Better Software Delivery Platform. Rick draws on his years of experience helping companies modernize and mainstream their software delivery systems (SDS) in a weekly podcast, with new episodes posted on Compuware.com each Monday, and a live Q&A session, Office Hour with Rick Slade, each Friday at 11 AM EDT.
In the series’ first podcast, Chapter One: Key Characteristics of a Modern Enterprise Software Delivery Platform, Rick discussed eight critical components to consider when building your modern software delivery system:
- A Modern IDE
- Iterative/Agile/Lean Processes
- Continuous Integration/Continuous Delivery
- “Shift Left”
- Test Data Management
- Measurement and Monitoring
I’m a newcomer to the world of mainframes, having only been at Compuware for a few months, but I’ve had jobs in IT support and working on websites. This can leave me slightly lost when getting into the technical aspects of coding, but also gives me a clearer perspective—I’m not bound to any one way of doing things. And my past experience has introduced me to some of the concepts discussed.
A Different Way of Looking at Things
A modern, graphical IDE, for example. In this past Friday’s Office Hour, Rick was asked about more experienced developers moving from 3270 green screen to graphical environments, and younger developers being more accustomed to working with Eclipse-based IDEs. Drawing on his own experiences switching from 3270 to a graphical environment, he discussed his initial hesitation at such a drastic change and how he came to view the graphical IDE as a better use of “screen real estate.” He also pointed out how having a common look and feel throughout an organization’s development teams can be incredibly valuable.
This reminded me of my own experience learning to work on Unix servers, after years of working on Windows-based systems—and then being introduced to the graphical interfaces of Linux. Switching between GUI and non-GUI systems could get jarring. It became necessary to find the common points between the systems—after all, they’re dealing with the same files and commands, just delivered in a different way. When you’re used to working a certain way, resistance to change is natural. But embracing that change, and adapting to it, can very quickly create new habits—ones that can be more productive and efficient than the old ones.
Add Agile, Add Velocity
The introduction of Agile methodologies has also been of particular interest to me. In past jobs, I’ve worked with developers who discussed “sprints,” and “minimum viable products.” As I encountered these terms at Compuware, though, I thought they must have been talking about something else entirely. You see, the terms were being used, but their usefulness and the spirit behind them was lost. Any new task was added to the current sprint. If it wasn’t finished, then it was simply moved to the next sprint – in some cases, many times. Sprints were treated as to-do lists. A piece of software might be developed as part of a sprint, but then left to sit for months, even years, until other pieces were developed around it, or until testing became a priority.
Adopting Agile methodologies with continuous integration and delivery of new code jumps out at me as being extremely important. I’ve seen projects languish for years because requirements weren’t defined, or perhaps changed during the long course of development. A clear definition of requirements, the establishment of a minimum viable product, and iterative progress can turn long, monolithic projects into short-term successes, and improve quality along the way.
Nip Problems in the Bud
Likewise with a “shift-left” approach. In the past, I’ve been told that new features would be ready on a particular date, only to find out that bugs were found in testing (usually the day before the launch date) and that code compiled over the course of months or years had to be examined to determine the root of the problem. Learning about shifting testing left, and automating it, hit me like a “Eureka!” moment. It didn’t take convincing for me to see the value in applying a narrower focus to testing, then resolving problems before they became “lost” in the project.
Concepts like modern development environments, iterative development, and earlier testing seem obvious, but changing workflows and old habits requires commitment and hard work, which can be daunting. Luckily, you don’t have to do it alone. Each week Rick’s podcast will touch on a different aspect of the SDS. Listen in, bring your questions to the Office Hour each Friday, and develop a plan to build your software delivery system to be the best it can be. Heck, I’m learning a lot from Rick, and I don’t even have a mainframe background. Imagine what his expertise can do for you.
This week, in Chapter 2: Modern Enterprise Software Delivery Architecture, Rick and I are joined by Compuware Vice President of Product Engineering David Rizzo. Rick gives an overview of some key components of software delivery system architecture and David explains how Agile and DevOps techniques helped reinvent the way Compuware delivers software. To hear this week’s episode, listen to past episodes, watch previous Q&A sessions and set reminders for the next Office Hour, visit compuware.com/goodcoding.