Yes - but there are some considerations ...

Enough is Enough

An architect needs to know when enough is enough. Architecture needs to be done with the team (not to or by but WITH the team) - then we can collectively feel like we understand the proposed solution, how it’s going to hang together, how it will address the risky bits and, meet its requirements. We can summarize architecture as comprising and limiting the planning and design decisions made up-front and to those that are difficult and (perhaps) costly to change once development has started.

There is a balance to be struck here - too much "architecture up front" and we end up in analysis-paralysis, too little and we end up with 'accidental architecture' - that is architecture on the fly! So we need some guidelines to help - and a sense of fail-fast pragmatism. It 'should' become clear to project teams if too much effort/time is being spent on purely architectural concerns, similarly red flags should be waved in during sprints and development cycles when teams are suddenly needing to answer large/encompassing architectural questions. Think big, act small

"Think big"

• Teams must maintain an overall vision and direction for the architecture of the system.
• An architecture that is incremental yet emergent doesn't mean that no one is anticipating and looking toward the future.
• The strategic architectural direction of the product that anticipates the needs of the business must be plotted out.
• YAGNI?

Note: This is not a big up-front design, however; it can take the form of an architectural vision document, an architecture document that supports the development teams. The items that are prioritized as a result of the architectural vision end up on the architectural runway.

"Act small"

• Teams need to keep the big-picture architectural vision in mind while delivering small pieces of valuable software to the business.
• Small "increments" must be of high quality and include consideration and possible incremental implementation of the architectural vision.
• Pieces of the emerging architecture should be built as part of a user story that is driven by business needs and delivers value to the end user.

Note: Teams should front-load risk in projects and, by doing so, deal with risk early and take the necessary steps to alleviate its impact on the project and business. This is complemented by the idea of "learning rapidly," as it's of no use to fail fast if teams do not learn from their failures. Teams need to identify and overcome challenges as early as possible to ensure the success of their projects.

Deliver quality

There are technical practices that are the key to achieving technical excellence.

• Proper unit and automated testing
• continuous integration (CI)
• pair and peer programming
• refactoring
• collective code ownership

Tags

• architecture