The optimisation of business value delivery - DevOps value-stream management

I have always been rather fond of ASG Technologies, a Rocket Company. It was one of that breed of big-systems vendors which was well respected in its space but that almost no one outside of that space had heard of. I first became interested in its document management platform – Mobius Content Services, which no doubt I’ll be revisiting – but I soon noticed ASG-Enterprise Orchestrator (AEO), which claims to offer “true cross-platform DevOps orchestration” from ES-3 (the modernised mainframe) to hybrid cloud.

ASG has many other products in the fields of content services, data intelligence, digital automation and IT systems management (which includes performance and capacity management, operations management, and mainframe applications management for, for example, COBOL and IDMS databases). I think we will hear a lot more about ASG in the future, as it has now been acquired by Rocket Software, which has a similar focus on large enterprise systems and their modernisation. Two medium-sized vendors of roughly equal size and complimentary cultures, merging to form an even bigger vendor. Rocket’s culture was built around empathy, humanity, trust and love, and ASG’s around the idea that customers matter, people matter and results matter. It will be interesting to see how these cultures merge.

ASG’s focus is supporting the large scale enterprise across all platforms via hybrid cloud and eliminating legacy silos through modernisation, rather than replacement, of existing platforms – which fits well with Bloor’s agenda for the Mutable Business and Enterprise Server 3.0.

At the moment, I am particularly interested in DevOps and its anti-patterns – many companies adopt DevOps “successfully” and create yet another silo, meaning they don’t get the business outcomes anticipated. How can anti-patterns be addressed dynamically, before it is too late to do something about them? In short, one needs to concentrate on business value at all the DevOps stages (code does not always equate to business value, especially at scale), but the devil is very much in the detail of what this means. So, I was very interested in the opportunity to discuss DevOps value stream management with Anna Murray (Director of Product Management Systems at ASG) at an ITLeaders workshop event in October 2021 – Passcode to view: 5sn8#Sna.

Anna is keen to point out that DevOps is a “philosophy of collaboration and communication between Dev, Ops, Security and other teams outside IT,” not just a toolset, although the DevOps tool chain (interoperating tools that support DevOps), is important.

I think Anna’s views fit well with Bloor’s view of DevOps, that all appropriate stakeholders should be involved as early as makes sense, and that continuous integration/continuous delivery (CI/CD) is an important part, but not the only part, of the DevOps tool chain. Anna also emphasises the importance of keeping a security mindset going, and of building security into every stage of the DevOps pipeline. I very much agree, although I personally dislike the term DevSecOps – it implies that there might be a DevOps where security doesn’t matter, and I don’t think there is, although not all developments require the same level of security, of course.

Fig 1 – ASG DevOps

Anna sums up ASG’s view of DevOps quite nicely in a slide (fig 1) and I was pleased to see the open-source tools I expected to see as part of the tool chain.

Anna goes on to explain how ASG Enterprise Orchestrator (AEO) could build disparate products into a DevOps Toolchain. Easy to say, but not always so easy to do in practice.

The imperative is to extend value streams across hybrid cloud architectures and to remove silos – e.g., the integration of (modernised, ES-3) mainframe development and modernisation into DevOps flows. I think that DevOps is probably the key IT silo-buster, these days.

Anna envisages a productive journey, from workload automation to DevOps-oriented service orchestration platforms. According to Wikipedia, “a platform is a group of technologies that are used as a base upon which other applications, processes or technologies are developed.” I like this definition, but I also think that platforms should be part of whole ecosystems, including a collaborative, independent on-line community supporting the platform.

According to Anna, there are two types of value streams: operational (value to internal or external customers), and development (value to potential customers we don’t have yet – new offerings, for new operational value streams). ASG already offers automation tools but AEO will begin to offer value stream mapping to show the sequence of events required to deliver customer value to connect operational and development value streams and further remove operational and development silos.

Value stream mapping is well worth researching further, and the ASG eBook in the previous link is a good start. Even so, I think that much (but not all) of the value can be achieved simply by always relating what you are doing to the value it will deliver for the business. Always explain objectives, problems and fixes in business terms (even if there is also a dig-down to the technical components).

Anna talks about how AEO provides the ability to visualise and choreograph value streams with drag and drop onto a virtual white-board; in other words, to orchestrate cross-platform value streams. After a few acquisitions/mergers, most enterprises have a wealth of different tools, often siloed, overlapping and badly understood generally. A rich environment for AEO orchestration, bringing order to chaos. And, of course, as soon as DevOps tool chains get to any size, they are crying out for AEO Automation to make sure that consistent good practice is followed. Finally, AEO facilitates visibility of the progress of value-streams, in real time and in forms appropriate to each of the impacted stakeholders.

As an aside, I think that schedulers are the great hidden secret of the ES-3 world, and as the silos break down, the sort of scheduling tools that mainframers have taken for granted for decades are becoming available for everyone. AEO is basically built on top of a mature workload automation and scheduling engine.

There was a lively discussion in the chat during the presentation – no names reported, as we were under Chatham House rules – including a timely reminder that we are still building on what came before.

Gene Kim’s The Phoenix Project novel was mentioned as a good entry guide to DevOps culture and practice.

There was talk of scaling DevOps and someone suggested that DevOps scales up to Dunbar’s number (150) and then Enterprise Agile kicks in with SAFe and an overall waterfall architecture. This received some support: “SAFe was created by a key UML contributor (but that’s another thing!) but I can see the goal, what it is attempting to do. SAFe is a great way to see where your constraints or bottlenecks are in value streams – and then decide what to do with them… or nothing” OK, I like SAFe (the Scaled Agile Framework) but I did ask which waterfall he was thinking of, the iterative mini waterfalls in the original Royce paper, or the abomination implemented by some last century IT groups? The incremental version of course – but even if you are Agile, having some idea of “requirements,” of what the business wants to achieve, is still a good starting point, especially at scale.

At that point, we moved on to the final part of the evening, with an excellent virtual wine-tasting and cheese party agilely orchestrated by ITL and Vineking. It was an excellent workshop and, thinking of the wine and cheese, all knowledge is good knowledge.