System-driven Cloud Architecture Design Support with Structured State Management and Guided Decision Assistance

TL;DR

The paper tackles the challenge of cloud-architecture design under ambiguous requirements by introducing CloudArchitectBuddy (CA-Buddy), a system-driven design support tool that uses structured state management (UserState and ArchitectureState) and guided decision assistance to iteratively refine requirements and designs. It presents the system design, state models, user/system actions, and prompt-based LLM workflows that generate and evaluate architecture proposals. Through a preliminary LLM exam study and a user experiment with 16 practitioners across four scenarios, CA-Buddy achieves design quality comparable to a chat interface while offering higher usability and clearer visibility into architectural decisions; users still desire free-text interaction for richer discussions. The findings support a hybrid direction that combines structured workflow with conversational flexibility to more effectively support cloud-architecture development in practice.

Abstract

Cloud architecture design is a complex process requiring both technical expertise and architectural knowledge to develop solutions from frequently ambiguous requirements. We present CloudArchitectBuddy, a system-driven cloud architecture design support application with two key mechanisms: (1) structured state management that enhances design understanding through explicit representation of requirements and architectural decisions, and (2) guided decision assistance that facilitates design progress through proactive verification and requirement refinement. Our study with 16 industry practitioners showed that while our approach achieved comparable design quality to a chat interface, participants rated our system higher for usability and appreciated its ability to help understand architectural relationships and identify missing requirements. However, participants also expressed a need for user-initiated interactions where they could freely provide design instructions and engage in detailed discussions with LLMs. These results suggest that integrating a chat interface into our structured and guided workflow approach would create a more practical solution, balancing systematic design support with conversational flexibility for comprehensive cloud architecture development.

Figures (8)

• Figure 1: Comparison of chat UI and CloudArchitectBuddy.
• Figure 2: System architecture of CloudArchitectBuddy. The upper part shows structured state models, UserState and ArchitectureState, evolving over iterations. The lower part illustrates the system-driven flow, consisting of user actions (steps I and V, in orange) and system actions (steps II, III, and IV, in blue). Step numbers indicate the interaction sequence and correspond to updates in the state models above. In each step, green-highlighted fields in the state models are updated as a result of the corresponding action. After (V), the user returns to step (II) to revise the architecture. UserState is carried over, and the history of ArchitectureState is preserved, enabling incremental improvement through successive iterations. See Figure \ref{['fig:state-examples']} for concrete examples of the states and updates, and Figure \ref{['fig:system-interfaces']} for the user interface supporting interactions with these states and actions.
• Figure 3: Example transitions and structural representations of UserState and ArchitectureState, illustrating how user actions drive iterative updates. Each numbered panel corresponds to a design state in the workflow, with the associated process step, state type, and action source (see also Figure \ref{['fig:system-overview']}). (1) shows the initial UserState containing only high-level requirements, which the system uses to generate, (2) the initial ArchitectureState with proposed services, issue analysis, and clarification questions. (3) is the updated UserState after user responses such as requiring GPU, saving data, evaluating Session Manager as good, and pinning EC2. (4) is the regenerated ArchitectureState that reflects the updated preferences.
• Figure 4: System interfaces. (a), (b), and (c) show state views of the ArchitectureState for Services, Summary, and Inspection, respectively. Each of (d), (e), and (f) presents user interaction forms for answering system inquiries, evaluating solution alternatives, and marking essential services.
• Figure 5: Our prompt template for Architecture Proposal