Panel Discussion, Taken from our Ascot CIO Event, October 12th 2017
Dr Richard Sykes, Chairman, Cloud Industry Forum (Moderator)
Alan Morgans, Programme Director, NHS
Chris Carrigan, Cloud Transformation Lead, Maersk
We do a survey at the Cloud Industry Forum asking at what stage people are with the cloud and my feeling is that the uptake of the cloud is still at quite early stages. The place with the more dramatic change has been in the vendor community where the changes are starting to become more radical at times.
Chris Carrigan, Cloud Transformation Lead, Maersk-
What you need to know about Maersk Transport and Logistics is that we are huge. We have 600 ships the size of supertankers carrying approximately ? of global trade from 600 sites across the globe ranging from small officers with a few people and a telephone to through to major ports.
So a massive, complicated global business. And again, that complexity ranges from managing and monitoring a single refrigerated container through to running an automated port, and our core systems run thousands of transactions every second to do that. Everything we do is big, which is why the Cloud is of great interest to us because of the scalability.
Where are we on the journey? We are a big beast, so we have things that are happening in the cloud, such as very advanced stuff around blockchain, systems in multiple clouds across multiple areas all the way through to mainframe still sitting on the floor back in the data centre. What I am interested in is how do we shift from that to a fully cloud native business.
Alan Morgans, Programme Director, NHS-
So my background is engineering originally, then I moved into tech, I ran Digital Agency for 14 years and then moved into Government Digital Service back in 2015, so that was the cloud journey for me.
So the Exemplar programme was in full flight then and we were looking to break the cycle of dominance of SI legacy and provide a more consistent user experience for the public which needed to be built out on different technologies. So we started the government journey into consistent standards and patterns and underpinning cloud technology at that time. I worked with Skyscape, DVLA and DVSA during that time there and I’ve had a lot of exposure to the cloud transferring whole systems in some cases.
Now I am in NHS Digital which initially was looking at the transformation of NHS Choices which was already in the cloud but we needed to move it a more dynamic transactional service. Full Stack is in Azure and it is pretty well formed and large scale with 45 million views from around 30 million viewers every month and a lot of transactions and social impressions (around 10 million a month between Facebook, Twitter etc.).
So a lot of different interoperability considerations there between the local, the regional and the national in the NHS and interfacing with the spine as well. It is fully cloud native now and it’s really a mix through the NHS estate. In some localities you have some legacy technology and some systems built on really old tech.
I think one of the most interesting things about cloud is that correlation with software engineering. ‘Why are you getting into cloud?’ ‘What’s the value proposition for being in cloud?’ It’s not in general a cost saving infrastructure play. It’s about what platform as a service capabilities enable your software engineers to do fundamentally differently.
And if you are going to do that, you need a fundamentally different approach to the way your developing software. It’s about how you build to agile models and how you get agile models to operate at scale.
I think the transition to agile is a problem in it’s own right. I think people overplay the need for millennials in that space. Actually I think you can get some pretty brilliant programmers to adopt it very quickly because actually it’s the way they have always wanted to work and the system hasn’t let them.
So I think if you take those constraints away, actually things can work pretty effectively pretty quickly. The issue is actually the middle managers who are used to operating in a way where they are not servant leaders and that I think is the real cultural transition.
And then also obviously the transition of the business as well, because again you have to untrain the business from the waterfall structures that you have trained them into. But again once they realise how much better the new world is, it ceases to be a difficult conversation and the pressure switches the other way to ‘how quickly can you move to this?’
And at that point, it’s the legacy technology that’s starts to get in your way rather than the people, because the moment your cloud native systems need to go and talk to a traditional system, you’re into a very different kind of change cycle. Particularly if you have a large legacy estate like we have because you hit fundamental issues of coupling down at the legacy level.
If you are building cloud native, then it’s very fast and you can do continuous integration and deployment. The moment those systems need to talk to a legacy system, you have to do systems integration tests because those systems were never designed for that kind of level of change and they don’t tend to have the wrapper around them that allows you to do the simple things.
So for me actually the cultural stuff is easy and the real challenge is creating the technical environment that will allow people to behave in that modern way.
It’s interesting. Agile is not a new thing, it’s been around for decades. It’s just become more mainstream. I think as cloud technology has evolved, as more business transformation has happened, as more things are consumed through the browser and as organisation gravitate towards transacting digitally and communicating digitally with their users, which is driven by user behaviour, it has just enabled more people to consume and transact at the point of need or desire.
So the culture and the interfacing with legacy technology is interesting. As long as you plot that journey, there are key decisions to make there. So in the first iteration with GDS, a decision was taken to do a shallower transformation piece where that interfacing and pressing data back to legacy systems would happen, but it wasn’t fully understood about something of the things we would run into along that journey.
For example, the visual default service standard said that transactional systems should be available 24/7 and we saw this with vehicle management with DVLA for example. A lot of smaller auto traders like to do their management of transactions in the evening but the legacy tech did batch updates.
So we needed to build a capture area for those things and be able to play them back in. And the way we did that was by drilling straight into the database portal and capturing them in middleware that we had to create. And further down that strategic transformation journey will be a plan to retire that legacy tech
I think cloud is interesting because it helps you keep on top of tech depth better and if you can go towards a continuous delivery type model, then you can start to adopt things like Blue/Green deployment, deploying into a new stack which is built infrastructure from code or serverless technology.
And that really helps you manage your tech depth better and helps manage vulnerabilities because you don’t get things dating and you don’t see random defects creeping in. So I think investment in that platform, automation and software delivery lifecycle and making it as generic as you can while still leveraging the power of some of the cloud platforms, is very important.
So there are a lot of decisions to take on that journey but there are a lot of business advantages for migrating to cloud at least into a hybrid way and having that rapid delivery capability if your processes and cultured are geared around delivering into that.
Some people are more resistant to change. Agile is a much more dynamic, fast paced, democratised kind of environment and I suppose if your governments as an organisation is more legacy, then working on that interface between legacy and agile governments is important.
When you manage through ceremonies on the ground and you don’t have very detailed sets of requirements upfront, the advantage is that you can pivot mid-project, because you learn things about user behaviour and about the business need as you go along on that journey and it’s helpful to be able to accommodate that need, otherwise you build things that people won’t use.
So it’s a great methodology for that, but you also need to be able to govern and keep track on planning, spend and quality, so it’s a bit of a balancing act. But I’ve seen a lot of benefit in the projects in government that I’ve been involved with through using cloud technology.
And it’s really enabled a much more rapid pace of delivery, a much more flexible model of delivery and it’s enabled us to roll with and accommodate change as we deliver it, which ultimately gets back to delivering a better experience for the user, which is a catalyst for channel shift which you want to unlock the benefit of delivering digital transactional capability.
I think you have to think about the interface. Also, you have to think about ‘why isn’t it agile? What do you feel it is about that means it can’t be operated in an agile way?’ Agile is fundamentally a time boxed methodology. The fundamental difference with agile is in a traditional project you flex on quality. In the old set of time, cost, scope and quality, waterfall flex is quality in general. What agile does is it fixes time and it flexes scope.
Now with GDPR, you might say ‘well it’s a fixed thing, it has to be done’, but then that’s just a simple matter of making sure you have the capacity within your agile model to deliver against it.
Yes, there are certain things that you need to run a project or a programme for, but actually if you are using something like Safe, that fits in quite well. You just have to understand the deliverables you’ve got to hit and you’ve got to get your product managers and owners lined up to that. Because it simply becomes a prioritisation conversation. If the organisation has to deliver on this thing by this date, then that drives the backlog prioritisation and then the system works.
I think one of the problems we’ve got as a CIO community is that the Gartner Bimodal model has got very deeply into our culture and I think the time for that has actually passed now. I think that that was a very transitional model that was useful in the early days of digital, but we’ve now reached a level of maturity of the technology and our understanding of agile where it’s now a milestone, and we now need to put it to the side and start just talking about the way we ought to be building systems.
I agree. I’ve worked in time box environments extensively in government. It is a question of scope, capacity, capability and design. It’s about constructing core control artifacts in terms of planning with your service or program backlog and your portfolio plan, which will lay down your workstreams reflected in that backlog and then it’s a case of how many units of delivery in bring in broadly.
It does get messy to manage if you are talking about 20+ teams delivering against a very aggressive timeline, but I would argue it’s a better methodology to deliver against a tight timeframe than a more traditional waterfall methodology, because by the time you capture all the requirements you are not gonna accommodate change and you’re not gonna understand everything until you are on the journey.
And with agile you can flex, switch teams on and off and bring them into that model effectively. So scope, capacity, capability, the right culture and the right governments wrapped around it.
Particularly with something link GDPR, agile can be very useful because it’s not necessarily a fixed scope. GDPR is about continually reducing the risk of doing the wrong thing.
So actually you can build a risk prioritised backlog so instead of having a fixed date where the problem is fixed or not, you can be constantly reducing the risk of breaching that requirement over time as your programme progresses. And that’s got to be a better way of approaching something like that.
The capability that you build up to deliver against a scope and agile teams are the unit to delivery so your capacity is basically scaling. So the capability you build up typically comes from staff, specialist and vendor and if you have too much of you one you can skew the model.
I like to have an approach, typically with the type of projects I’ve been delivering, where you look to build sustainable capability in house as much as you can. It’s very difficult to recruit and retain the whole DevOps culture, so you need to mesh together to operate, improve and support something sustainably over time.
The vendor landscape is interesting because GDS (previous employer) wanted to break the deadlock of system integrated contracts because they had gone too far one way. So those big vendors have had to reinvent themselves. some of them have done that very successfully and those companies have grown with an ingrained culture of agile delivery, so they have an advantage in that regard.
I like to use multiple vendors and blend them together but not too many. This concept of completely rainbowed teams is difficult to manage, you don’t really get an integrated culture and you don’t really shift the risk onto the vendor if you work in that model.
It’s OK in a mature, downstream Service Ops type of state but to deliver big outcomes I like to work with 2-4 expert vendors that compliment themselves culturally and I like to drive them so hard that they don’t worry about their ingrained cultures.
Yeah, it’s not moved enough yet I would say. There are certainly still opportunities in that market but you’ve seen the growth in some companies who are a DevOps culture company to the core, they understand the business of delivery and they have the experience to be able to deploy cohesive teams that can work together and will work into the methodologies.
So there is give and take there. They need to be prepared to work with you and they need to be able to roll and flex. And I always put an outcome on the vendor to enable the internal teams because that’s where you get the sustainability and the cost savings downstream.
So an internal team operating the service over 10 years is gonna be 30-40% of the cost of an outsourced team and that’s significant over time. So the vendor needs to teach the internal people and the organisation needs to bring in a mix of people from experienced to graduate to apprentice and even move people from other professions as well into agile and give them the chance.
Let me shift the question to talk about the platform vendor. So in a cloud context, has the platform vendor as opposed to the software vendor landscape changed and evolved?
And I think we have some interesting things there because you have Amazon and Google who are effectively new entrants as vendors. Microsoft is a big player and then you have the IBMs and Oracles of this world who traditionally would have been your platform vendor who are effectively now building their own clouds. So that is a fundamentally different vendor landscape to the one that we would have been in if we were going out and buying infrastructure 5-10 years ago.
The thing that interests me at the moment is that as we shift into platform as a service as opposed to infrastructure, we are beginning to get the conversation that we used to have around Oracle or DB2 which is ‘if I go into Azure and use their platform as a service capabilities, a lot of those are wonderful but they are fundamentally committing me to that environment.’
That then becomes are really interesting debate because is that a lock in you are comfortable with? Or do you want to keep that independance that allows you to operate across multiple clouds? Or actually for someone of our scale, you want to have that conversation with multiple suppliers because they will have different advantages in different spaces, so you need to start building things that are interoperable across clouds.
And the vendors are currently still positioning a ‘put everything in our cloud’ policy. And their pricing models are very specific around that. You look at how easy it is to get data into somebody’s cloud and how difficult it is to get out from a cost perspective and the mechanisms that are being put in to do that.
So I think in the cloud vendor space, that is actually still quite immature and I’d be very interested as a community how you feel about the trade off of ‘actually we’re just gonna go partner with Vendor X because it’s difficult enough as it is and I can build the skill base etc.’ as opposed to ‘actually, I need to run a portfolio of people and be interoperable between them.’
Because for me, that seems to be one of the massive decisions we are all going to have to be taking over the next 2-3 years that there isn’t a particularly large body of industry documentational thinking on at the moment.
You have missed out some details, please try again.