Some design decisions have an impact on the trajectory of the whole project. Modeling is most needed in complex circumstances, yet the typical dynamics of large projects too often derail it or disconnect it from the real design. A related issue: modeling is best carried out by small, dynamic teams with a lot of autonomy, yet creating large systems requires coordination and project-spanning decisions. Managers and developers alike need to pay close attention to this intersection of design, project organization, and politics. This talk will introduce them to a suite of techniques for that purpose.

First, distilling a shared vision of the system's core and the roles of its parts can focus development effort on real business assets, and tell when 'good enough good enough' versus when to push for excellence. It can guide decisions about what do develop in-house, what to buy, and even where agile processes will matter most.

Then, "context mapping" addresses a vital fact of life: different groups model differently. Ignoring these realities leads to dumbed-down models and costly, buggy integrations, and disruption of project plans where they depend on other teams. Defining the boundaries within which these various models apply allows a team operating within such a boundary to iterate and refine its model and design without being suffocated by interdependencies with other teams, yet without blindly slamming into insurmountable integration problems. The combination of context mapping and distillation of the core domain provides a powerful view of the big picture.

Finally, who makes such decisions and how? Architecture teams disconnected from daily development make decisions with unintended consequences. Agile processes emphasize staying close to the hands-on development work, but such decisions also need a broad view. Without prescribing a particular organization, we will consider guidelines for strategic decision making.