DevOps - February 27, 2020
As a “seasoned” payments industry veteran, I have spent a lot of years and covered a lot of miles traveling across the globe. It has been a great run, helping in some small way to advance the growth and evolution of electronic payments from very humble beginnings to where we are today. However, as the years and miles continue to pile up, I find trying to describe those early days to today’s new payment professionals can be somewhat difficult.
For example, I was speaking with a colleague the other day about the early days of payments, and had to work pretty hard to explain the concept behind Tymshare, one of my early employers. As someone born in the Internet/Mobile age, she found it difficult to fathom a time when there were very few computers and they were so expensive that companies could only afford to buy fractional time to run their most important computing jobs. To connect our customers to our computers, Tymshare built their own proprietary network called Tymnet (definitely not the Internet). My job at Tymshare involved using Tymnet to connect point-of-sale terminals with authorization systems.
This is how we managed e-mail in those days:
The Need for Speed
So, coming from a time and place where a Waterfall approach to software development was the norm (i.e., define, design, code, test, deploy), I struggle at times with the concepts of Agile and DevOps. I have read the Agile Manifesto, read the Phoenix Project, read lots of whitepapers and blogs and other reference materials; but given the almost mystical nature of Agile and DevOps, I have had a hard time forming a solid mental image of what these concepts truly mean. The way that companies delivered software in those days was also very different. Even as consumers embraced the idea of electronic payments and transaction volumes continued to increase, progress could be painfully slow. It could take years to design, develop and deploy a new release of software. And perhaps more interesting is that a 2 or 3-year release cycle was too fast for many financial services companies to handle. In those days, it was not uncommon for organizations to skip a release cycle (or two), meaning that they could go 5 or even 7 years between releases. My, how things have changed.
Consequently, I was excited when I came across a blog that broke the three different disciplines into a single diagram:
Yes, Waterfall looked right to me. For the design phase, I remember engineers would pull together a high-level estimate that a customer would review, revise and then sign-off on so we could estimate the project. From there, an even more senior engineer would produce a detailed specification that could be used by a developer to write the code. The specification is what would also be used during the testing phase to help validate that the newly developed code did what it was supposed to. And ultimately a group of new enhancements would eventually get tested simultaneously with the existing code base to ensure that it all worked together.
So to add this up, we have 2 or 3 months for the high-level estimate, another 2 or 3 months for the detailed specification, 2 or 3 months for coding, a month for unit testing, 3 or 4 months for regression testing, 2 or 3 months for re-work, 3 or 4 more months for release planning, documentation, and the rest -- and we have a new release in precisely 14-20 months. Oh wait, I forgot to mention vacations and holidays, code freezes, new/changing requirements, card scheme mandates, technology upgrades and all sorts of other things that can happen over such a lengthy period, and the total estimate is more like 24-36 months. That’s how I remember it.
Using the newly found diagram, I could start to see that Agile is all about coding and testing in smaller chunks. OK, that seemed to make sense. Smaller coding windows, faster (perhaps automated) testing cycles would make it easier to develop software more quickly and cleanly than before. But wait, the picture shows that deployment of the new software seems to be happening in about the same timeframe as with the Waterfall approach. I was thinking code would be coming off the assembly line much more rapidly. I must not have understood something correctly.
The DevOps line in the picture seems to be closer to what I was thinking Agile is. Coding, testing and deployment are happening much more quickly, which is what we want, but where is the line between Agile and DevOps? I wondered what happened between these two lines and if I would ever be able to figure this out.
Paragon's Methodology
The good news is that Paragon has been an Agile shop for several years. Mark Medlin, one of our founders and our current CTO, has been shepherding Paragon through our own Agile transformation and engages with our customers and prospects on issues related to Agile and DevOps on a regular basis. I showed Mark the diagram above and asked him to help me unravel the mysterious nature of these concepts.
After an hour on the phone with Mark, I started to see a new image emerge that defines both Agile and DevOps. In our next blog, I will post the picture with my comments and we will see if you think I made any real progress.
