A theatrical stage plot is a beautiful piece of technical shorthand. It tells the roadies exactly where the drum riser sits, it tells the lighting tech where the gels need to be swapped from amber to bruised purple, and it tells the monitor engineer which wedge needs more of the lead singer’s ego. It is a complete geometric representation of a performance.
Yet, you can stare at a stage plot for a decade and you will never find a single notation indicating who owns the publishing rights to the bridge of the third song. You won’t find a mark signifying the ASCAP fees or the contractual rider that demands the green M&Ms be incinerated. The plot is about the physical capability of the show, not the legal permission to exist.
We have exported this selective blindness directly into the heart of enterprise information technology.
The Ritual of the Design Review
I have sat through hundreds of design reviews where a Lead Architect stands before a projected slide, laser pointer dancing across a field of boxes and arrows like a caffeinated firefly. We spend forty-five minutes debating the latency between the load balancer and the web tier. We spend another twenty minutes discussing the failover triggers for the SQL cluster. We scrutinize the “how” until the air in the room becomes heavy with the smell of recycled ozone and expensive coffee.
During these ninety-minute marathons, every single component and every single connection is interrogated. But there is a void on the canvas. Not a single pixel is dedicated to the obligations that make the connections legal. There is no notation for an entitlement. There is no standard UML symbol for a “Right to Use.” Because our representational conventions are treated as neutral, we assume that if it isn’t on the diagram, it isn’t part of the design.
Closed Systems and Open Refrigerators
I found myself staring into my refrigerator for the third time in an hour just before writing this. I wasn’t even hungry. I was looking for a version of reality where the leftovers had spontaneously evolved into something more exciting, perhaps a slice of cold pizza that hadn’t been there at . I was looking for something new in a closed system.
Design reviews are often the same ritual. We look at the same Visio stencils, hoping that by rearranging the boxes, the underlying cost of the software will somehow evaporate. We look at the diagram and see a finished city; we forget that every road in that city is a toll road, and we haven’t checked if we have the right currency in our pockets.
The problem is that the tools we use to think-the diagrams themselves-dictate the boundaries of our professional scrutiny. In every discipline that reviews by drawing, what cannot be drawn cannot be reviewed. If a civil engineer draws a bridge, they include the stress loads of the steel. If they forgot to include the fact that the land on the other side is owned by a hostile foreign power, the bridge is technically sound but practically a disaster. In IT, we are masters of building bridges to nowhere because our “Obligations List” is a separate spreadsheet that lives in a folder no one has opened since the procurement phase.
The Fantasy of Clean Remote Access
Consider the specific agony of the Remote Desktop Services environment. On an architecture diagram, an RDS deployment looks remarkably clean. You have your Gateway, your Licensing Server, your Session Hosts, and your users. It’s a series of neat, nested rectangles. The arrows show RDP traffic flowing smoothly from the external client to the internal resource. It looks like a solved problem.
However, that diagram is a fantasy. It ignores the “grace period”-that countdown timer that is the tectonic plate of the Windows Server world. The diagram shows the capability of remote access, but it ignores the contractual obligation of the Client Access License. When the grace period expires, the arrows on that diagram don’t just turn red; they cease to exist. The system doesn’t care that the architecture is “highly available” if the entitlement is “unavailable.”
The “Grace Period” countdown: In architecture diagrams, this progress bar is invisible until the system ceases to function entirely on .
“In my world, if you don’t time the silence, the text that follows it feels like a jump-scare. You have to account for what isn’t being said, or the rhythm of the story breaks.”
– Hayden S.K., subtitle timing specialist
Our architecture diagrams are missing the “timed silence” of licensing. We draw the “text”-the servers and the databases-but we ignore the gaps where the obligations live. We treat the software as a static asset when it is actually a recurring permission.
When you are deep in the weeds of a deployment, especially something as finicky as remote access, you realize that the technical configuration is only 40% of the battle. The rest is ensuring that when the 121st day hits, your users aren’t met with a black screen and a “No license server available” error. This is where the gap between the diagram and the reality becomes a chasm. IT teams are often time-poor and under immense pressure to “just make it work.” They deploy the server, they see the users logging in, and they tick the box on the diagram. But the “Obligation” remains unfulfilled.
The $40,000 Resilient Engine (Without a Key)
We need a new notation. We need a way to draw a “Contractual Bound” around our clusters. We need to stop pretending that the “Licensing Server” box on the diagram is the same thing as having the licenses. One is a piece of software; the other is a legal right. Confusing the two is like confusing a map of a restaurant with a meal.
I remember a project where we spent $40,000 on redundant hardware for a terminal server farm. The diagram was a masterpiece of N+1 resilience. We had redundant power, redundant networking, and a storage area network that could survive a direct hit from a meteor. But on Monday morning of the fifth month, the entire system went dark.
The architect had forgotten to account for the fact that the “User CALs” were not part of the enterprise agreement. We had a $40,000 engine and no key to start it. When we looked at the diagram afterward, searching for where we went wrong, the diagram still looked perfect. That was the most frustrating part. According to the “Rules of Drawing Architecture,” we had done everything right. The failure was invisible because our representational language had no word for “permission.”
This selective blindness is a comfort mechanism. If we don’t have to draw the obligations, we don’t have to own the complexity of procurement. We can stay in the “pure” world of logic and flow. But logic and flow are secondary to the reality of the software’s heart-the entitlement.
The next time you are in a design review, and someone points to a connection between two systems, ask a question that isn’t about protocols or ports. Ask: “What is the name of the document that gives us the right to make this arrow exist?” Watch the room go quiet. Watch the Lead Architect look at the diagram, then at the ceiling, then back at the diagram. They are looking for a symbol that isn’t there.
We have to start drawing the invisible. We have to start treating the Obligations List with the same reverence we give the Architecture Diagram. If we don’t, we are just artists painting pictures of machines that we don’t actually own.
I am going to go check the fridge one more time. I know there is nothing new in there. I know the inventory hasn’t changed. But at least I am aware of the deficit. In IT architecture, the greatest danger isn’t a missing server; it’s the missing realization that every box you draw comes with a bill you haven’t yet acknowledged.
The arrow that connects the user to the server remains a ghost until the obligation of the license is pinned to the wall.
We have spent too long obsessing over the art and ignoring the science. We build cathedrals of data and then realize we forgot to buy the land they sit on. It is time to stop reviewing diagrams that are half-empty. It is time to demand a notation for the things that actually keep the lights on-the rights, the entitlements, and the boring, essential licenses that turn a drawing into a working system.
Until then, your diagram is just a very expensive piece of clip art.