Digital technology tends to develop at a pace that many large organizations find challenging to assimilate. We’re seeing that situation in real time lately, with recent advances in generative AI.
But I think cloud is a better case study for establishing asset management programs for enterprise architecture, given the wide-ranging capabilities it democratized.
Plus I have a good story to tell.
When the public cloud’s comprehensiveness of enterprise-grade computing services arrived on the market, it could supplant many corporate IT functions (e.g., infrastructure), at least in some ways. And the speed at which the cloud providers brought all of this to market really did shake things up, in both good and bad ways.
Early in the cloud era (somewhere between Debut and Fearless), at a time when several cloud providers had a reasonably complete—but still incomplete—line-up of services, I worked with a company that had found itself in a serious, unsustainable predicament.
The organization discovered that it had teams building and hosting solutions for customers, around the world, on most public cloud provider platforms, well beyond the Big Three, or, more precisely at the time, the Big 2.5.
These systems were not aligned to the company’s policies (e.g., policies for cybersecurity and operations), although some teams had made reasonable attempts to, for example, implement basic security controls. The cloud provider’s platforms were also still a developing story in terms of critical infrastructure capabilities, as well, so we were operating on a foundation of sinking sand.
The situation was prolific, not just a few isolated instances. It was also urgent because each of these solutions could place the company’s brand, position in the market, and legal and regulatory compliance at risk if something were to go wrong.
It was at this time that I realized, importantly, that asset tiering doesn’t just solve an architectural governance problem, what we were focused on. It can also solve Shadow IT problems as well.
How Asset Management Contains Shadow IT
Asset tiering doesn’t just solve an architectural governance problem; it makes Shadow IT visible, classifiable, and ultimately governable.
In other words, an enterprise architecture function that takes asset management seriously can actually solve Shadow IT problems, not just complain about them.
What Shadow IT Looks Like in Practice
Shadow IT is fairly straightforward to define. It’s simply the use of technology systems, software, or services without formal oversight. That oversight is typically provided by an organization’s technology function, although these organizations can have Shadow IT problems of their own, as well.
Not involving the technology organization in technology solutions can be intentional or unintentional. It can be as comprehensive as hosting workloads in the cloud, as I just described. But it can also be done by people in the technology organization, for example, by using free, open source software instead of standard, vetted components, open source or otherwise.
Shadow IT is an issue for most technology organizations. But it’s also not necessarily a problem that needs to be solved, in a sense that it stops. In many organizations, it just needs to be contained, aligned to risk and governance models, and, possibly embraced once the “shadow” part goes away.
In the previous post, Effective Asset Classification for Enterprise Architecture Governance, we outlined a tiered asset model with four general levels: 0 – Untrusted; 1 – Appraised; 2 – Reviewed; 3 – Assured. This is just an example, and, for now, we will just focus on the first one: Untrusted.
Classifying Shadow IT as Level 0: Untrusted Assets
I mentioned in a previous post that, “each tier in the asset classification model will tie to a phased construct of architectural review criteria” and added that we haven’t defined that yet. We will start doing that, but just conceptually for now, to help facilitate moving through the first step of asset management as the base structure for Enterprise Architecture.
When we “find” something that we didn’t already know about—big or small—like the previous examples, we catalog that thing as an asset and enter it into our asset inventory.
We also ask that the entire organization help in this regard by adding their use of any technologies in the asset inventory. Maybe they will, and maybe they won’t, for any reason or for no reason at all. We’ll handle that in a bit.
At this point, we’re just collecting a minimum set of attributes about each new asset, which, at this point is a relatively mundane endeavor. In that manner, we probably know who the owner is (i.e., who is using the technology or collection of technologies) and what it is that’s being used.
From there, we may know something about the source technology, and, what, if anything, it is connecting to on the network. We should also assign each asset a GUID, because we’re innovators and are thinking long term.
The asset is named and classified as Level 0 – Untrusted. And that’s it.
Except, from that point, the asset will show up as an untrusted asset—including who the asset owner is—in whatever way we are reporting operational metrics on the asset management program that Enterprise Architecture is built upon, possibly, including compliance related matters.
Hopefully you’re seeing what’s going on. . .
Level 1 Asset Reviews: Moving Untrusted Shadow IT into the Light
Moving an asset from the Level 0 – Untrusted status happens by completing a Level 1 architecture review of the asset.
Completing, of course, means successfully meeting all of the evaluative criteria of the review. But at this stage, think triage, like in an ER, where your vital signs are checked at intake, versus a full evaluation by a physician, to determine if you advance immediately or sit and wait in the lobby.
As an organization, including stakeholders (e.g., Finance, Cybersecurity, Operations, Architecture), you should decide on the absolute minimum collection of evaluative criteria that make sense to figure out at this point. Save the decades-in-the-making list of all the things that have made you mad for Level 2 reviews, or beyond. (But please don’t actually do it at that point, either, which we’ll discuss in time).
Here’s a baseline to start from:
- Trusted Source – The vendor or project is reputable, identifiable, and traceable (i.e., no anonymous or suspicious origin).
- Critical Vulnerabilities – No unpatched high/critical Common Vulnerabilities and Exposures (CVEs) in the current version.
- Maintenance and Support – Actively updated software with a track record of timely security patches.
- Access and Authorization – Can operate without unnecessary elevated permissions; least-privilege possible.
- Data Handling – Uses encryption for sensitive data in transit and at rest; no insecure defaults.
- Licensing – License terms are known, valid, and compatible with organizational policies (e.g., no unapproved, restrictive, or risky open-source licensing terms).
Figure out what makes sense for your organization at this level of asset review. Remember that we’re just establishing a minimum standard that serves as the first line of asset maturity.
Traversing the Asset Classification Model: From Untrusted to Assured
Just because an asset has been reviewed doesn’t mean that it’s no longer untrusted (i.e., that it’s trusted). While we want to keep the evaluation criteria to a minimal set, they have to be met.
Kind of how lawyers prefer asking questions that they already know the answer to, prospective asset owners, if wise, will want to make sure these conditions are met before stepping into asset ownership. Or not, and we’ll get to the authority part in a moment.
So, for a potential asset owner, there is risk in this model for not making sure these conditions are met before moving forward with a solution. That’s important.
It’s important because there’s always the possibility that the conditions cannot be met, even when kept to a minimum set. We’ll cover waivers at the more advanced tiers of the asset model as well as moving up and down the tiers. But at this level, waivers shouldn’t be part of the tiering model. If an asset cannot meet the criteria it just remains untrusted.
But what happens to untrusted assets and their owners?
Making Asset Owners Accountable for Shadow IT
In my opening story, those Shadow IT cloud systems were met with automation that would reparent accounts (using AWS terminology here, generally) within our domain structures and organizational hierarchies and then cascade policies and controls that had to be met from that point. It’s a lot easier to do this sort of thing now, but it was challenging at the time.
But even though I find that story useful as an extreme example of Shadow IT, it’s not the trickiest. Once we figured things out, it was pretty straightforward to deal with.
But what about those “lesser” things? You know, the ones like SaaS products, software libraries, custom-built executables, plug-ins, and such? You know, the ones you have little visibility or control over that can fucking ruin your business because of vulnerabilities, exploits, and attacks?
Well, it depends…
Are we providing reports, trying to lead by influence, or do we have a mandate? If a business really wants a strong Enterprise Architecture program and to call bullshit on Shadow IT in the process (sorry, I’m from Texas), asset management is an organization-wide, C-Level strategy.
So, if the business decides that untrusted assets are not allowed, if there is an asset management program in place that establishes ownership, and if there is a rigorous effort to identify and report on things that are in use, being the owner of an untrusted asset will not be exciting. It could, in effect, become career limiting.
In this nonnegotiable way, with the use of asset management as one of the foundational constructs of the Enterprise Architecture function, you can get a lot done, which we will continue to explore, and build upon, as we move on.
But first we will backup a bit—a lot, actually—to define what we mean by Architecture and Enterprise Architecture.
Notes:
- Image generated by Google’s Gemini 2.5 Flash.
- Interestingly, when Gemini was generating images that were wildly off mark from what I was asking for, I was given this hilarious comment when I challenged it: “I’m just a language model and can’t help with that.”
Leave a Reply