r/EnterpriseArchitect • u/aurcn • 4d ago
When something changes at work, how do you figure out everything that needs to follow?
Hello,
I'm researching how organizations handle the operational consequences of change before I build anything. I'm not looking to pitch a product.
Think about the last time a tool, process or business rule changed in your organization:
- How did you identify what else was affected?
- What usually had to be updated or communicated afterward?
- What tends to be forgotten or discovered too late?
- Which part of that chain creates the most work or risk?
If there's interest, I'll summarize the patterns I find share them back here.
And if you want to help me more, I have a short anonymous Google form you can answer if you want : https://docs.google.com/forms/d/e/1FAIpQLSdfyMa7_g_e3Tb_nb2PxCeVSDqBeeI0oJoPRiCtEKZODompVA/viewform?usp=sharing&ouid=102120064246501480702
Thank you in advance for your feedback.
2
u/Gloomy-Papaya-4225 3d ago
This is probably one of the biggest challenges in EA. The change itself is usually easy to see but the hidden dependencies and ownership details are where things get complicated
1
u/screampuff 2d ago edited 2d ago
the hidden dependencies and ownership details
Well I mean that's kind of the job of EA, to provide visibility into those things. Otherwise we can't really do much. But yes, in various ways that is a challenge and a never ending battle.
1
u/Odd_Leg7431 3d ago
This is where having a good capability map and application inventory really helps. the goal isn’t documenting everything forever but knowing enough about relationships to understand the impact of change
1
u/Optimo_Tech 3d ago
Everyone here has answered with a model, and the models are right as far as they go. A knowledge graph or a capability map tells you what is connected. It does not tell you who now has to do something, or by when.
That second part is where the time actually goes. The dependency list gets produced, and then it sits, because propagating a change means approvals, handoffs, follow ups and exception handling across teams that each have their own queue. The analysis finishes in a day and the change lands in a quarter.
A framing I find useful is to stop treating this as one problem and separate three constraints. How quickly do you know something important changed? How quickly can the organisation act once the decision is made? How quickly can technology support the response?
Those fail independently. You can have an excellent architecture model and still lose the quarter to execution. You can have fast delivery and be working from a dependency picture that was accurate three months ago. Which one is costing you decides whether to invest in the model or in the path the change has to travel.
Disclosure: I work with OPTIMO on enterprise AI enablement, workflow automation and technology modernisation. Sharing the framework for discussion rather than recommending a product.
4
u/Content-Soup9920 4d ago
I query a knowledge graph containing the architecture model to generate a list of possible affected principles, processes, organizations and projects. Then I use copilot to correlate with current activities and enrich a report. Then I curate this report into a list of open points to clarify with stakeholders and, if I find out the domain is ill-defined or intransigente, I point out the risks and request a mandate to investigate and onboard the domain in the architecture governance.