Why did you move to the cloud? There's a reason. Today I share with you the reason we gave to a health system in 2010. Why is this important? Because we are in another recession and that means we are looking for budget cuts or efficiencies. The path to efficiencies in IT is a planned architecture. Today we discuss the characteristics of the cloud that make efficiencies and power possible.
Today in health, it why you moved to the cloud? My name is bill Russell. I'm a former CIO for a 16 hospital system. And creator of this week health set of channels, dedicated to keeping health, it staff current and engaged. We want to thank our show sponsors who are investing in developing the next generation of health
Gordian dynamics, Quill health Taos site nuance, Cayman, medical, and current health. Check them out at this week. health.com/today. All right today, I'm going to riff a little bit. , no new story. Just some conversations I've been having over the last couple of weeks. And it really stems around this whole concept of a dev ops dev sec ops and those kinds of things.
, and, but it also stems around some conversations I'm having with. , health system leaders who are, , going through a budget cycle, right? So as they're going through the budget cycle, they are trying to explore how they can reduce expenditures. And still deliver the same level of service and it took me
Took me back to 2008 and it's been a long time since we had an economic downturn. Like the one we are currently experiencing and they're very different downturns by the way. , but I'm not going to go into the economics of it. What I want to focus in on. Is. How you, how architecture plays a role.
In preparing you for times like And the term we keep using is agility. It's the ability to respond and react to situations. That arise either in the economy or the business climate or, , or the. , , user requirements or quite frankly, consumer. , consumer requirements, consumer demands, as they shift.
And so agility is, Hey, we've got to move. We've got to move quickly. We've got to do things. How do we build agility into the model and the, the answer? And no one really likes the word, the whole architecture word. Probably cause it's not easy to do, but I'm going to try to simplify it a little bit. And I am actually reading from a presentation I did to St. Joseph health in 2010.
, so I became, I became interim CIO in 2011 and then in 2012, I became the full-time CIO. And so this is 2010. This is, , forward thinking stuff in healthcare even today, but it's 2010. I I've heard a lot of people say, yeah, we've moved to the cloud, we're moving to the cloud. And, you know, cloud has sort of gotten the buzzword status in healthcare. And my question to people is why.
Why did you move to the cloud? It may be the right answer for your health system, but why did you do it? And I think it comes back to the essential characteristics. Of the cloud, and this is from 2010. This is what we were talking about. Okay. , the essential characteristics of the cloud from this deck that I presented to the St. Joe's leadership team one.
Self service provisioning. Meaning. Anyone with a credit card can pop on and spin up a server. And I didn't want everybody across St. Joe's to pick out their credit card and, and spin up a server or spin up storage or spin , AI or something to that effect. I just wanted to demonstrate the fact that it was accessible to anyone anywhere in the world. They could provision a server, , if they had the credentials and if they had the, , budget.
For doing So self-service provisioning. , rapid elasticity, meaning it can, it can scale up. Very rapidly, which goes to the next one, which is meter service pays. You go, it can scale up. It can scale
And so one of the things we did not have. At at, at the health system I was presenting to was any kind of elasticity. If the economy was up, we spent more money. If the economy was down, we spent the same amount of money. There was never a, a retreat if you will, of our cost model. And so we wanted some elasticity. If the economy pulled back and we had fewer needs for.
, licenses and resources, we could actually pull back. And so we were looking for a little different model than the one we had both on the hardware side and on the software side. Okay. So we were looking for a little different approach to licensing. Now, some of this stuff played out in some of it did the costs of cloud computing continue to rise as
, You know, these large players in cloud realized, , more and more people were moving there and they are publicly traded companies. So they were trying to Their profitability. So similar stuff played out really well. Some of them didn't play out as well as we would have liked, but regardless you get a certain amount of.
, flexibility, agility. If you will, self-service provisioning, they can do it anywhere. It lasted city and meter service pays you go gave us, , elasticity. It gave us a agility in terms of our licensing models and our ability to scale up and scale down the number of resources we were looking The next one.
, it is just ubiquitous ness of the cloud, right? So we were talking about consumers back then in 2010 that the healthcare consumer was a conversation we were having. And we were saying, where are our healthcare consumers? And the answer was today. They're in these markets. , but they could travel and they could be somewhere else. And in the future we envisioned.
The ability to have consumers outside of our markets. And the nice thing about that was the cloud gave us access to those consumers wherever they were literally in the world. If we architected our environment, Correctly. So we could have internet of medical things, internet of things, internet of, you know, you name it
The tele-health you name it wherever they were in the world. We could get to them and access them. And that played out in the pandemic for a lot of health systems. Bye.
, let's, let's just say they were required to, so it played out. , but you could have stepped into it with a plan ahead of time to say, look, we need to reach our patients wherever they were at. That's what our model was. And then I really want to talk today about that this last one. , essential characteristics for cloud and a lot of people overlook this one.
And it is a application accessible application, programmable interface, API APIs. Right. So we started talking to them about the fact that the infrastructure was software.
The software defined a data center, the software defined architecture. And it was addressable through APIs. And so you would start to, , hire more programmers. Dev ops dev sec ops, who would, , essentially come in and start writing code that would automate things. And the automation would allow you to go much, faster, much quicker. So you were, you would be able to see a, an intrusion and shut off ports. You'd be able to see a compromise on a server and spin down that instance of that virtual server and spin up a new instance that wasn't compromised.
It was those kinds of things that we were looking at and saying, , you know, your every year it kept coming in and asking for more resources because it took more resources to manage the additional servers and workload that were coming in. And our concept, which really does play out because I've seen it play out over and over again is if it is software and not hardware, first of all, it's not as fixed. And second of all,
, you don't need as many people to run it. I saw a major, major financial institution go from a team of about. You know, 10 networking people to, to. And, , people were like, how are you going to do this? Well, you know, back in the day, all the, all the routers, the Cisco switches routers and hubs were all accessible via a central model and they could roll things out and they could, they could do.
, a ton of things through. The API. Essentially, what was an API at that time that was proprietary so forth, but the two of them could monitor the entire network. And they could roll out all sorts of stuff across that network and still have time to go to lunch. And still have time to see their families on the weekends. It wasn't like we just dumped a ton of work on them.
We did work differently and that created that environment. And with that. That model in, in hand and seeing it work out in other industries who said, look, We can do this in healthcare and we could do this first of all, by virtualizing the entire stack in the, , in the data center. So we actually turned it into software. We're spinning up resources.
, around that. And we were using VMware. , at the time and probably are still using VMware today, but we were able to virtualize all those resources. We were able to programmatically access, access all those resources and able to spin those up. That was the, that was the original. , model for taking our data center and turning it into software. And then we had to look at some things which were fixed.
And so some other things we had to start moving those out. , fast forward to today. And by the way, 2010. To 2009, 2010 we're we're we're , just coming out of the 2008. Recession the 2008 recession was harsh. , it was a very deep recession and the reason it was, , well, I, it doesn't matter what the reason was. It was very deep recession. We were just coming out of it. So we were talking about how you are preparing yourself for the next one down the road.
Next one down the road happens to be happening right now, which is why I dug this deck out. And so if you have a, so the conversations are happening right now with it leaders, with leaders across the health system, how can we be more effective, more efficient? And it comes back to this same model self-service provisioning, rapid elasticity.
, page to go for services, , ubiquitousness of access and resources. So you're actually growing your capabilities as you're doing some of these things. And. , and API, but I come back to API because I had two conversations recently, one, , with a security, , leader for a smallish health system. And to give you an idea, there was a bunch of CISOs in the room.
And some had teams, , You know, 25 to 30 and some had smaller teams and this person was a part of a smaller team and they were a hands-on CISSO and I think their team was 6.1 people. Literally, he kept saying 6.1. Have a 0.1. , FTE that does a bunch of stuff. And I guess 0.1 FTE would be a misnomer when it anyway.
, But he was talking about all the things that they had done through programming, through automation and automation. Sits on top of this whole concept of API APIs. And they they're able to shut off a workstations that show signs of compromise all programmatically. And he was just talking about all these use cases where they had, , they had looked at.
You know, the, the work that they used to do by hand and the, the amount of time it would take. And then they automated that task. And took it down to next to nothing. Take it down to, you know, Took something that used to take two and a half days and took it down to 45 minutes or even less like , to actually pull this stuff
And that's all because their environment is API accessible. They have the tools and they have programmers, Python, programmers, actually going in and writing the code. To, , automate their security thing. And, , I tell that story because that's one story. The second story I'll tell you is had a great conversation.
With a CTO. Who, , first of all, he gave me a great quote. He said, you know, Why did it only take, , six days for God to create And he said there was no legacy. And he said, you know, when you w he had just come into this organization, He said, rather than rebuild the entire legacy, he stood up a new and they're in the process of bringing, , capabilities from one of the old legacy to the new, not necessarily bringing the software from the old to the new, but bringing new capabilities.
, or bringing the capabilities that are required and moving them into the new. And he said, all the people who are in the new environment, they operate in their own, get their programmers.
They are programmers. They essentially are writing code. And the main thing he talked about was their agility, their ability to imagine envision with wonder, they go, Hey, could we do this with whatever? And from that wonder, from that question. To actually invention and, , implementation is very rapid in their organization. And so they're constantly doing, , iterative cycles around.
, user experience, , internally and externally. And moving things forward very rapidly.
That is what's possible. And so as we are having these conversations,
We need to, , consider the role that architecture plays in preparing us, maybe not for this one. , for this, , Current economic downturn, but potentially for the next And saying, look, we got caught flat-footed in this one. We can't get caught flat-footed in the next one. And that was this presentation St. Joseph's looking at me saying,
, in every area we had to cut, but we couldn't cut in it because if you know the fact that it was such a static architecture, it was such a, you know, in cement kind of situation, we had data centers, we had servers and that kind of stuff. And so we presented this model and this model was meant to give the organization the kind of agility they needed.
So this was a 2010 fast forward to today. 2022. If this model were in place and actually all on the And we saw this, we were able to reduce the number of resources we needed in certain areas. , as we rolled out some of these capabilities and the, , The CA capabilities were just far. Superior to the things that we did
, in fact it, I come back to security. , you know, security is happening so fast. It's a rapidly, , that you have to automate it. You have to make it for dramatic. And the only way to do that is to really look at a, at a dev sec ops and the ability to automate that entire platform. , from end-to-end.
Because you're not going to be looking at the log when the problem happens. But the system, can the systems looking at the lock as it's writing the log? Right. So there's an opportunity there to get ahead of this. All right. I rambled on a little bit more than I wanted to, as I said, Just wanted to riff this morning.
On. Those who are looking at, , financial challenges and reductions. This may not help you for this one, but it should help you for future ones. And the other thing I will say is if you move to the cloud and didn't know why this is why. And you may want to look into, if you are being asked for some of these things, ask your team about the, , automation factors, the API factors.
, really around your let's start with architecture, you should be able to, to reduce your, , overall need for resources in some of these areas. , network system storage. , , I mean, just that aspect of it very quickly and then security as well. You may not need as many people, if you can automate some of
, mundane tasks anyway. I continue. Sorry. That's all for today. If you know someone that might benefit from our channel, please forward them a note. They can subscribe on our website this week. Dot com or wherever you listen to podcasts, apple, Google, overcast, Spotify, Stitcher. You get the We want to it's ubiquitous. It's everywhere.
, we want to thank our channel sponsors for investing in our mission to develop the next generation of health leaders, accordion dynamics, Quill health tau site nuance, Canon medical, and 📍 current health. Check them out at this week. health.com. Slash today. Thanks for listening that's all for now