This workshop focuses on:
- architecture, answering the question: “what is software architecture?”, addressing the concepts and concerns of architecture design work, and introducing architectural patterns, principles and mechanisms.
- architecting, that is the process of creating and evolving an architecture. The major emphasis of the workshop is on system design. We move between probing what the system needs to become, to better fit its context and purpose, and determining how best to design the system to do that. We create drafts of the various architecture views and related decision sets, to convene discussions, share techniques, heuristics and insights, and practice architecture work. It creates a forum for instructor and peer mentoring, and allows questions to be raised in situ, providing contextual grounding for advice.
- architects, addressing the role and responsibilities of architects (titles may vary) in complex system design and evolution, and expanding the focus of personal development from code to systems design and technical leadership, including strategic acuity. We also discuss architecture responsibilities and the architect role (whatever it happens to be called) within the organization.
Small teams work on creating a draft architecture, drawing on the models and guidance in Visual Architecting. We follow the iterative architecting process, and weave concepts and architecting techniques into lectures/discussion that bookend work sessions. The lecture topics are driven by the concerns that are being addressed at that stage of the architecting process. This makes it a “non-traditional” format, but it is one that works well as it allows us to work end-to-end through the creation of a draft architecture.
For more information about the program please go to http://www.bredemeyer.com/Workshops/architecture_workshop_overview.htm or contact us.
This workshop is designed for architects (those doing architecture work, whatever their title) and senior system design engineers. Managers of architecture teams will also benefit. Product owners may be interested too.
It may also be of interest to developers who are interested in a system design approach that works across both capabilities design (“requirements,” including properties or “non-functionals”) and the design of the system internals (architecturally significant parts and interactions, and mechanisms).