The Architect Still Owns the Decision: Language Models in Enterprise Systems Design

By Federico J. Quijada

In conversations with technology leaders this year, one question keeps returning in different forms: if a language model can sketch a reference architecture in under a minute, what is the architect for? It is a fair question. The honest answer is more useful than either the enthusiastic version or the dismissive one, and it starts with being precise about what an architecture actually is.

Architecture Is a Record of Decisions

Most of us learned to picture architecture as boxes and arrows. The research community moved past that picture some time ago. Jansen and Bosch (2005) argued that a software architecture is best understood as a set of explicit design decisions, and they traced many of architecture's chronic problems to what they called knowledge vaporization: the reasoning behind a decision stays implicit and is never captured as part of the design. Van der Ven and colleagues (2006) put it more plainly: design decisions reside in the minds of the designers, where they are easily lost.

That framing matters for anyone bringing AI into design work. The diagram is the visible output. The decision, and the reasoning that justified it, is the asset an organization actually depends on when something has to change.

What the Models Can Do Today

The early evidence is encouraging within clear limits. In an exploratory study presented at the 2024 International Conference on Software Architecture, Dhar, Vaidhyanathan, and Varma (2024) asked models to produce the decision portion of an architecture decision record from its context. GPT-4 generated relevant decisions without any examples, but it fell short of human-level performance. The authors concluded that models can help architects document decisions without being dependable enough to generate them on their own. A case study by Ahmad and colleagues (2023), in which a novice architect worked alongside ChatGPT on a service-based system, found that the model could support and sometimes lead parts of the architecting work, but still needed human oversight and decision support.

In practice, that makes a language model a capable drafting partner. It can propose alternatives a team had not considered, produce a first version of a decision record, and restate a design in terms a business stakeholder can follow. Those are real gains. A ten-year review of architecture knowledge management found that the cost and effort of capturing decisions and their reasoning is a major barrier to doing it at all (Capilla et al., 2016). A tool that lowers that cost matters.

Where the Risk Sits

The real issue is not that models make mistakes. Every tool does. The issue is the kind of mistake. Ji and colleagues (2023) describe hallucination as generated text that appears fluent and natural but is nonsensical or unfaithful to its source. In architecture work, a hallucinated detail rarely looks wrong. It looks like a reasonable default: a service boundary nobody asked for, a vendor capability that does not exist, a security assumption no one checked.

The second risk is human. Human factors research has documented for decades the risk that people over-rely on automated decision aids. Parasuraman and Manzey (2010) found that automation bias appears in experts as well as novices and is not reliably prevented by training or instructions alone. A systematic review by Goddard and colleagues (2012) identified workload, task complexity, and time pressure as conditions associated with stronger over-reliance. An architect reviewing a confident, well-formatted proposal late in a long week is precisely the person this research describes.

Put the two together and the failure mode comes into focus. A plausible error, reviewed by a capable but busy expert, becomes a decision no one actually made.

What This Means for Technology Leaders

The practical question becomes how to keep the drafting value without giving up ownership of the decision. Three habits make the difference.

Treat model output as a proposal, never as a decision. A named person accepts, modifies, or rejects it, and that name goes on the record.

Record the rationale, including what was rejected. If the model suggested an option the team declined, write down why. That is exactly the knowledge Jansen and Bosch warned would vaporize.

Verify what the design depends on. Vendor capabilities, compliance obligations, and security assumptions get checked against primary sources, not against the model's description of them. Goddard and colleagues (2012) list emphasizing user accountability among the mitigators of automation bias, and a verification step with a name attached to it does exactly that.

How I Teach This

When I work through this topic with executives, I do not start with the tools. I ask someone to defend one decision in their current architecture: why this database, why this boundary, why this vendor. Most can describe what they built. Fewer can reconstruct why they built it that way. That gap existed long before language models. The models simply make it possible to produce architecture faster than an organization can explain it.

Content mastery is the floor of this exercise, never its ceiling. Knowing what a model can generate is useful. Being able to defend what you chose, to a board, an auditor, or the person who inherits your system, is the job.

The Takeaway

Language models will keep getting better at drafting architecture. That makes the architect's other responsibility more important, not less: owning the decision, recording the reasoning, and being ready to explain it when someone asks. An architecture no one can explain is not finished. It is only drawn.

References

Ahmad, A., Waseem, M., Liang, P., Fahmideh, M., Aktar, M. S., & Mikkonen, T. (2023). Towards human-bot collaborative software architecting with ChatGPT. In Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering. ACM. https://doi.org/10.1145/3593434.3593468

Capilla, R., Jansen, A., Tang, A., Avgeriou, P., & Babar, M. A. (2016). 10 years of software architecture knowledge management: Practice and future. Journal of Systems and Software, 116, 191–205. https://doi.org/10.1016/j.jss.2015.08.054

Dhar, R., Vaidhyanathan, K., & Varma, V. (2024). Can LLMs generate architectural design decisions? An exploratory empirical study. In 2024 IEEE 21st International Conference on Software Architecture (ICSA). IEEE. https://doi.org/10.1109/ICSA59870.2024.00016

Goddard, K., Roudsari, A., & Wyatt, J. C. (2012). Automation bias: A systematic review of frequency, effect mediators, and mitigators. Journal of the American Medical Informatics Association, 19(1), 121–127. https://doi.org/10.1136/amiajnl-2011-000089

Jansen, A., & Bosch, J. (2005). Software architecture as a set of architectural design decisions. In 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05) (pp. 109–120). IEEE. https://doi.org/10.1109/WICSA.2005.61

Ji, Z., Lee, N., Frieske, R., Yu, T., Su, D., Xu, Y., Ishii, E., Bang, Y. J., Chen, D., Dai, W., Madotto, A., & Fung, P. (2023). Survey of hallucination in natural language generation. ACM Computing Surveys, 55(12), Article 248. https://doi.org/10.1145/3571730

Parasuraman, R., & Manzey, D. H. (2010). Complacency and bias in human use of automation: An attentional integration. Human Factors, 52(3), 381–410. https://doi.org/10.1177/0018720810376055

van der Ven, J. S., Jansen, A., Nijhuis, J., & Bosch, J. (2006). Design decisions: The bridge between rationale and architecture. In A. H. Dutoit, R. McCall, I. Mistrík, & B. Paech (Eds.), Rationale management in software engineering (pp. 329–348). Springer. https://doi.org/10.1007/978-3-540-30998-7_16