Good architecture – ochtendsessie

To establish, manage, and convey an architecture, the architect chooses how much attention to pay to certain stakeholders, concerns, models and other architectural aspects. But, to make the right choices, the architect must first know what a good architecture is in a specific situation. When the architect has a clear picture of when the architecture is good for a specific system and its environment, it becomes easier to choose amongst the abundance of architecture approaches and techniques, and focus on the most architecturally relevant aspects. This presentation offers a tool to work explicitly on what a good architecture is in a specific situation. The used framework has the following characteristics:

• Correct: “Does the system fit in its environment?”.
• Consistent: “Is the system well-engineered?”.
• Communicated: “Does everyone know what they need to know?”.

To check if an architecture is good and to give direction to the architectural activities, the architect can use a set of questions related to correctness, consistency, and communication. The architect must be able to answer each question, or should be able to explain why an answer cannot be given. Furthermore,  the manager can use the checklist to judge the status of the architecture, in order to decide about development activities. This presentation explains the concept of good architecture, illustrated by real world examples.

Robert Deckers has been working on formal specifications, code generation, model interpreters and methods for domain modelling, architecture, and requirements since 1991. He has been active as architect and consultant on all organizational levels. Robert is author of the book “DYA|Software, architecture approach for mission critical applications”. Since 2010, he teaches courses on architecture, and domain modelling at companies and universities, and coaches architects. In 2013 he started his own company to devote himself to Model Driven Development with a focus on quality aspects and multiple domains because, “system design software development is about integrating knowledge, and not about realizing technology”. Robert currently fulfils a PhD position at the VU in Amsterdam on that topic.