A colleague at the State of Oregon recently told me that "Oregon is taking very seriously the adoption to the cloud" and it was hard not to roll my eyes. Over the last 10+ years of working with Oregon, I've seen all sorts of fumbles in our technology strategy including multiple past missteps in technology adoption, plus I've heard that they're "serious" about "the cloud" twenty times before. I've met guys jockeying for State CIO who have told me, "We'll be completely on the cloud within 2 years" and that was 5 years ago. I've seen behind the curtain with the State of Oregon, and there's a lot of reason to be afraid - but this new vision, "Cloud Forward" largely hits the mark and is overall exactly what we need.
The report from Enterprise Information Services is published here: https://www.oregon.gov/das/OSCIO/Documents/EIS_CloudForward.pdf
Nearest I can tell, there's been no publicizing or popularizing of this strategy or fan-fare. Nothing from TAO or OAGITM, so certainly nothing from The Oregonian - and it's not like The Mercury is going to publish a 600-word piece on this. This all around isn't too surprising, why should seemingly inconsequential forward looking policies like this make the news?
You might be saying, "Fidelity, I don't give a flying fuck about technology, why should I care?"
Oregon does make the news when it comes to failed IT projects, like the Cover Oregon debacle. Congress published a report in 2016 detailing criminal allegations against Cover Oregon and Gov. Kitzhaber's team. This was such a huge problem that the fallout led to resignations and some restructuring of the State's IT strategy at the top - unfortunately most of those changes were trivial.
And of course keeping this all relevant to today, many of Oregon's agencies are plagued by legacy systems - most notably the crisis with the Employment Department that has impacted hundreds of thousands of Oregonians trying to get benefits during COVID.
There's also legacy systems within DMV that have caused issues with Real ID and Oregonians traveling.
Most people have no idea the level of irresponsibility and corruption happening within Oregon's IT decision making. A shitty IT strategy means a shitty government. What's in this Cloud Forward document is a very clear simplicity. It's aligned to what modern corporate IT is also doing.
Also consider that shitty IT is expensive:
In the most recent biennium, the state had 1,300 IT employees spread across 100 agencies, boards, and commissions and the state spent over $750 million on contracted IT services.
These numbers are not including "Tech Debt" a very real cost of maintaining systems plus the inevitable cost to modernize those systems. To understand Tech Debt, imagine you run a fleet of delivery vehicles - as your vehicles get older it becomes more difficult to find spare parts, it becomes more difficult to find mechanics who know how to effectively maintain your old vehicles, plus various operational costs of the vehicles increase, such as miles per gallon fuel compared to what a modern vehicle can get. In other words, think of this problem as if the State of Oregon is maintaining a fleet of 1973 Ford F-350's that get 8 miles to the gallon compared to us buying some new modern vehicles that get 20+ miles to the gallon, if we upgraded our systems the difference in fuel savings alone would non-trivial, especially when thinking over 4~5 years. Imagine too that our old 1973 trucks can only go a maximum of 45 miles per hour, and while that's fine in many circumstances, it's a big problem traveling on the highway compared to a modern vehicle and how much time employees spend in a slower vehicle. All of this is the Tech Debt: you need to buy new vehicles, and every day that you don't just buy a new fleet, the cost to upgrade increases. While we have outlays of $375 million dollars a year in IT services, there's another $2-$5 billion dollars in debt (that I'm estimating) that we need to pay in order to modernize all of our systems. The overall cost going to vendors (and the amount of staff we need) will increase in the short term, but longer term likely decrease. Even if costs don't decrease longer-term, investments in technology should be more fruitful in terms of efficiency.
Let's go back to the document.
The Guiding Principles of this document are exactly what you'd expect as a long-term IT strategy.
I guess I can find a few small things to critique, but nothing all that big. My biggest critique is that this document and our government's IT leadership isn't mature enough to really make efforts toward culture. But since we haven't yet adopted the cloud, it's really putting the cart before the horse if we dive too deep into cloud-first or cloud-forward culture.
From a technical perspective it's debatable if the best path forward is SaaS over PaaS - these are basically different approaches of how to handle the technical underpinnings of the business systems. SaaS fundamentally has less customization, whereas PaaS and IaaS offers more customization at higher cost. There's sort of a fallacy from within cloud immature organizations about SaaS that it's always easier and lower cost. Oregon will learn this isn't true.
There's no specific call outs for custom built applications, and reading this it appears they're trying to shy away from software development in favor of off-the-shelf/SaaS. While that's understandable, in many situations today off the shelf technology requires such a high degree of customization and integration that it truly comes with the same (and sometime higher) costs/risks as custom built solutions. I see this all the time in the enterprise space where a "solution" is actually a "platform" and the fundamental platform isn't nearly as robust as the marketing materials and demos made it seem. This is particularly true when it comes to the life cycle and migrations, even big vendors like Microsoft can leave you high and dry when it’s time to replace that aging software (looking at you, InfoPath!). Increasingly, conversations with software vendors become, "Oh, to get that feature you just need to integrate with an API, then have your React developer deploy this custom package" even though you bought it to avoid needing a developer.
There's no mention of things like DevOps or development oriented culture within State Agency business units. And that's fine. As the State matures it's cloud adoption and processes, somewhere in like 2025, there will need to be a revision of how the State of Oregon uses cloud computing. In addition, if “every company is now a software company” the same will be true with the State of Oregon and a future Governor will need to know what CI/CD means. We will need to develop a pedigree, comfort level, and culture of being a tech-forward government.
Plus, there's new iterations of technology that are extremely common in software companies and are slowly being adopted in Enterprise IT and will eventually come to government. These are technologies such as "Infrastructure As Code" ("IAC") that is enabling more customization and a lower cost through automation, or "Serverless computing" architecture which can bring an even lower cost to custom solutions. Some of these new technologies are passively mentioned in this document, which means the government at least acknowledges their existence, which is great.
This is a good template for your state/city/county/municipal government to follow.
The document has a lot of very boring IT organizational structure components, like how different work groups will allocate and consider tasks. This may seem really trivial to anyone working in private-sector IT, but there's a lot of cities, counties, and other States that haven't figured this out yet. For example, when some non-IT unit wants to do an Artificial Intelligence project they're going to need a whole bunch of technical services they need to procure and clear processes to align those procurements to cost centers. Not having this controlled process for procurement is one of the biggest reasons Oregon avoided the cloud in the first place - our Legislature dictates how much DHS can spend every two years, they can’t just kick IT expenses to a different agency, so every expense must go back to the right agency. While this document can't ensure every process works out perfectly, it at least outlines who will be responsible for elements of that process - and this is a better start than having none of those processes outlined.
It's pretty common that these high-level documents start out with fairly clear guidelines and statements, but in the lower levels of bureaucracy things get muddied, lines become blurred, and priorities conflict with promises - all of that is going to happen as Oregon gets closer to an enterprise strategy of cloud adoption. Road bumps are ahead, but that’s just part of the journey.
Will this Cloud Forward policy actually fix anything?
It's unclear, there's many statements in this document identifying problems and solutions - for example page 15:
In some cases, there is continuing reliance on 20- to 30-year-old “green screen” legacy systems developed using nearly-extinct programming languages (e.g., COBOL), whereas in other cases, agencies have already started investing in a cloud-defined future.
While traditional notions of IT modernization are limited to the migration of legacy systems to new applications or platforms (i.e., “rip and replace”), IT and application modernization increasingly encompass improved user interfaces (UI), enhanced user experience (UX), use of integration points or APIs, cloud-native or server-less infrastructure and a shift away from monolithic- to modular-IT systems comprised of loosely coupled micro-services. To support IT modernization and enterprise application rationalization, EIS is partnering with state agencies to develop an application inventory and assess current-state cloud utilization by policy area vertical—establishing a baseline for cloud adoption.
The document then provides a spectrum of solutions biased upon a triage of the problem. There is a policy to identify the thousands of applications used at the State level and begin a rudimentary path toward modernization and migration. That's a positive thing. We'll see how it plays out.