Structured viewpoints can help architects identify requirements, answer design questions and guide AI-assisted development, according to Iasa Global founder Paul Preiss.
Enterprise architects often begin projects by drawing diagrams or choosing familiar modeling methods. But Paul Preiss, founder and CEO of Iasa Global, suggests a different approach: Start by identifying the questions a system must answer, then select the viewpoints and models best suited to addressing them.
In a Nov. 6 LinkedIn article, “From the Field: Designing With Viewpoints,” Preiss describes applying this approach to an ongoing project involving IASA’s Metis learning platform and Ergane architecture tool.
The project will enable students taking IASA courses to work on individual Ergane boards alongside their lessons, receive feedback from instructors and retain their boards after completing their courses.
Although the objective is straightforward, Preiss says implementation raises questions about enrollment, identity management, permissions, system integration and long-term access.
Rather than starting with screens or technical components, he created a fictional student persona.
Tomás is an experienced engineer transitioning into an architecture role. His circumstances introduced several requirements, including the need to avoid uploading confidential employer information and retain his completed architecture work for future professional use.
Those requirements helped establish the issues the architecture needed to address.
Preiss then created a service blueprint illustrating the student experience from enrollment through course completion. The blueprint identified student activities, supporting processes and interactions between the two platforms.
One unresolved issue emerged: What should happen to a student’s access after completing a course?
To answer that question, Preiss used an information viewpoint to model the lifecycle of a student’s access to an Ergane board.
The model distinguished among different access states and showed that completing a course would remove certain permissions without deleting the student’s work. Rejoining could restore access.
This allowed a governance decision to be made before the development of individual screens.
Security requirements presented another challenge.
Preiss used both a sequence diagram and an access control model to describe authentication and permissions. The two representations addressed the same concern but served different audiences.
Developers could examine the technical interactions, while other stakeholders could review permissions presented in more accessible terms.
The process also exposed unresolved assumptions, including what should happen when an authentication token expires while a student is saving work.
Preiss describes identifying such assumptions as an important part of architecture work because they reveal risks that might otherwise remain undocumented.
Another principle involves selecting modeling notations according to the question being addressed. He used UML and C4 representations rather than trying to address every concern through a single diagramming approach.
Preiss also discusses using AI agents within this structured environment. He reports that architectural information from the boards could be exported to development tools, including Devin and Claude Code, to support implementation.
He attributes the usefulness of those interactions to the structure provided by the viewpoints, which gave the agents defined information and constraints.
The article concludes that viewpoints do not eliminate the experience required to make sound architectural decisions. Rather, Preiss argues, they help architects identify the questions that need answers and document those answers consistently.
His overall message is that effective architecture begins not with a preferred diagram or tool, but with a clear understanding of stakeholder concerns, system behavior and the decisions necessary to produce a coherent design.