Have a clear exit strategy

When are you done architecting? How long should the architecting phase take? These are very common questions that often don’t have a common answer. Your answer depends on what you’re trying to achieve and your operating environment.

The first step is to understand your environment and your constraints. Both technical and organizational. As Fred Brooks said in his new book The Design Of Design: “constraints are friends.” Constraints bound you and the scope of your work. You must still understand and feel the difference between a real constraint and a perceived constraint (often political) and a requirement.

The second step is to define your exit strategy. This must and can be defined shortly after you understand the general nature of the problem and your role in defining a solution. This requires understanding the role of downstream designers and implementers (even if you may be playing those roles as well). Without clearly defining the success (and failure) criteria before you invest your time your work is never going to be good enough. It’s a given fact that your success criteria and your exit strategy may change through the design process, but having a baseline will make it easier for you to handle changes in the future. But most importantly you’ll know when you’re done.


Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Comments

Anonymous said…
I like the idea of an exit strategy. Can you provide specific examples of what this has looked like for you?
adviluser said…
This comment has been removed by the author.
Having an exit strategy means knowing when architecture is complete and can be transferred to the downstream designers for further refinement or detailed (code level) design.

Knowing when to stop architecting is critical.

For example, for a web based system that supports the documentation process of researchers' activities I knew that the following segments had to be part of the exit strategy:

1. Well defined interfaces for data consumed by the tool (down to business rules and format of the data)
2. Selection of the backbone framework for the whole application (MVC)
3. Identification of all core modules (reporting, researchers' log, data import utility, authorization, authentication, evidence management library)

I was done architecting when all the modules were defined and the relationships between the modules (data flow and control flow) was defined. The relationships were expressed from different perspectives: runtime, static, and deployment.

Popular posts from this blog

Why we do agile

Quality Attribute Refinement