A common concern is scope: “This is enterprise architecture, does it apply to solution or cloud architecture?” The honest answer is: the artifacts differ by level, but the mechanisms travel well.
Why transfer is defensible
Demir et al. (2024) provide a careful bridge: software architecture is described as a stakeholder-negotiated process producing architectural decisions, and practitioners face both technical and social problems (p. 1). The study’s conclusion that challenges and considerations transcend specific methodologies or documentation practices (p. 26) supports cautious transfer of the socio-technical lens across architecting contexts.
What changes when you move to cloud/solution architecture
- The “enterprise” layer may be thinner, but governance and risk remain (often) implemented as guardrails, policies-as-code, and platform standards.
- Artifacts change form: roadmaps may become migration waves; conceptual architectures may become landing zone or reference architectures; solution designs may become ADR + IaC patterns.
- Stakeholder sets shift: platform teams, FinOps, security, SRE, vendor constraints often play a larger role.
Practical mapping (EA artifact → cloud/solution equivalent)
- Roadmaps → migration waves / modernization backlog
- Conceptual architectures → reference architectures / landing zone blueprints
- Solution designs → ADRs + design docs + IaC modules
- Maxims/principles → guardrails / policies / standards-as-code
The core function remains: artifacts as boundary objects that stabilize shared meaning and enable routine decision-making across communities.
What to do in practice
If you have access to project histories (ADRs, diagrams, sprint reviews) and outcome signals (time records, incidents, rework), you can move from a conceptual lens to an empirical contribution via a longitudinal case study.
Bibliography
Demir, M. Ö., Chouseinoglou, O., & Tarhan, A. K. (2024). Factors affecting architectural decision-making process and challenges in software projects: An industrial survey. Journal of Software: Evolution and Process, 36(10), e2703.

Leave a comment