Last week I finished moving our document management system from on-prem to the cloud. Almost immediately, users wanted connections to more applications. That was a reasonable expectation. We had made the system more capable, and people could see useful things to do with it.
Each connection needs a security review and a decision about how it fits our policies. We have to consider what can enter the system and what can leave it. We also have to think about the agents that may eventually read what’s there.
From the requesting side, that can look like a successful technology change followed by an administrative delay. The connection is possible. Somebody still has to approve it.
I keep coming back to what changed underneath that conversation. On-prem, integration was difficult. That difficulty limited the number of connections we had to consider. The architecture was exercising restraint on our behalf, without anyone having to defend the restraint as a decision.
Once we removed the difficulty, the decision became ours.
The old constraint had no owner
Calling this an unwritten policy needs a little care. Technical inconvenience cannot tell you which use is appropriate. It can prevent useful work as easily as questionable work. I wouldn’t argue for preserving a difficult architecture because it saves somebody an approval conversation.
But the practical effect was there. When connecting another application took enough effort, fewer connections happened. The system constrained behaviour without requiring a person to assess every possibility that the cloud now makes available.
That distinction matters when we explain the queue. The visible workload has increased because more decisions have become worth asking for. The migration succeeded at creating options. Each option now needs a decision about whether, and under what conditions, it belongs in the working environment.
The cost of restraint has moved into people’s calendars.
It also has a name attached. A technical limitation is impersonal. A reviewer asking for more information is somebody whose answer can be challenged. The same user who accepted that an integration was impractical may reasonably ask why an available connection is taking time.
I don’t want to dismiss that impatience. It is evidence that people can see value in what we delivered. It also creates an obligation on our side: the review needs an intelligible purpose, an owner, and a decision people can act on.
Simply pointing at governance leaves the requester with very little. A useful answer explains the unresolved boundary and who can settle it. Approval should carry conditions that another person can understand later, without having attended the original conversation.
This is where the migration plan needs to extend beyond the cutover. If easier integration is part of the benefit, the capacity to assess integrations is part of the operating requirement. Otherwise, we have funded the capability and left the decisions to whoever can find time.
The old architecture made that omission difficult to see. A queue makes it obvious.
Connected still needs boundaries
There is an attractive architecture behind the promise of AI at work: bring the information together, connect the systems, and give the model enough context to help. Fewer disconnected tools can mean less work for the person trying to assemble an answer.
I understand the appeal. Building useful behaviour into a workflow is a better experience than making every employee work out how to ask for it.
In regulated work, though, the design has to preserve the distinctions that govern who may use information and for what purpose. A more complete picture is useful only within those boundaries. Some parts of the picture need to remain unavailable to the actor performing the task.
The number of databases doesn’t settle that problem. A consolidated system can preserve access boundaries, and separate systems can still expose information through their connections. The important decision concerns the reach we give an application and the purpose that justifies it.
That is why a phrase like access limited to the right information carries so much work. Somebody has to define what right means for this connection. Somebody has to establish whether the receiving system can preserve the relevant restrictions. The answer must survive beyond the person who approved it.
The boundary is part of the design.
This also changes how I would approach the accumulated friction in an older system. Some of it deserves to disappear. Some may be the practical expression of a distinction that still matters, even if its rationale is poorly recorded.
Before removing a constraint, establish what it has been preventing and whether any of that prevention is still needed. Then make the surviving rule explicit. Keeping every obstacle would preserve needless work. Clearing them all without understanding their effects would leave the replacement design unfinished.
A migration gives us the opportunity to make those choices deliberately. It also takes away the ability to leave them implicit.
Today’s integration becomes tomorrow’s evidence
The part that extends beyond this migration is what happens to the information after a connection has been approved.
Our document system is also a place future agents may retrieve from. That makes the decision to admit information consequential beyond the immediate convenience of getting it there. Something available for retrieval can become an input to an answer or a proposed action.
Availability, by itself, says very little about how much weight that information deserves. The system needs to preserve enough context for the next user to understand its origin and intended use. An agent workflow needs an explicit way to account for those distinctions too.
This brings two decisions together. We decide whether an application may contribute information, and we decide what downstream work may rely on that contribution. Treating the first as a transport question leaves the second for somebody else to discover later.
I would want the integration record to make that connection visible. It should state the approved purpose, describe the permitted movement of information, and identify the person responsible for the decision. It should also record the assumptions that would require another review if they changed.
That record gives the next reviewer something useful to work from. It creates the possibility of consistent decisions across similar requests, instead of repeatedly reconstructing the reasoning from memory. It also gives the requester a clearer account of what an approval actually permits.
The technical controls can then enforce a decision that somebody has consciously made. There is still judgment involved in setting the boundary and revisiting it. Making the workflow easier to use doesn’t remove the need for that judgment.
The cloud move is a good outcome. People have more options, and their interest in using them is part of the value. Supporting that interest now means giving the decisions the same attention we gave the infrastructure.
The old architecture could make a connection impractical. It could never explain why we should permit it.
That answer needs an author.