• Often requires significant investment in exploration of the architecture (via modeling, mob programming, etc.) due to the potential architectural risks involved.

• Allows maximum tailoring of the solution for the stakeholders.

• Due to the uncertainty of the technology and perceived needs, this may be our most risky option.

• Enables us to take advantage of a sophisticated package while tailoring it to our needs.

• Often requires investment in spikes (see below) or a proof of concept (PoC) to explore how the package works in our environment.

• May be difficult to remain on the package's release path when extensive modifications have been made.

• May require redoing some changes when new versions are released.

• May be more cost effective than building from scratch, particularly when a small number of changes are required.

• Enables us to have several delivery teams work on the problem, often leading to a “bake-off” where the best strategy to move forward with is chosen.

• Provides us with a “plan B,” a “plan C,” and so on, that we can shift to when our architectural strategy is disproved early in Construction.

• Increases the cost and expense of initial architecture modeling, but potentially reduces long-term risk through considering a wide range of options.

• Enables people to work through problem or solution domain issues, thereby reducing risk.

• Face-to-face discussion is a very effective way for people to communicate.

• Discussions can go in circles. When this happens, consider shifting to modeling to help achieve focus.

• To persist the conversation we will need to record it, take notes, or model somehow.

• Works well with a disparate group of people that need to hear each other.

• Often produces important insights that leadership may not have been aware of and innovative ideas.

• Requires some up-front planning, facilitation, and follow-through to share the results.

• Some people will not like what appears to be the “unplanned” nature of open space.

• Reduces risk by exploring how a major technical feature, often an expensive software package or platform, works in practice within our environment.

• PoCs can be large, expensive efforts that are sometimes run as a mini project.

• Success criteria is often politically motivated and sometimes even oriented toward a predetermined answer.

• Scales to dozens of people.

• Many people may get their opinions known during the session, enabling a wide range of people to be heard.

• Works well in regulatory environments.

• Works well in contentious situations where extra effort is required to keep the conversation civil or to avoid someone dominating the conversation.

• “Architecture by consensus” often results in a mediocre technical vision.

• Formal modeling sessions risk devolving into being specification-focused, instead of communication-focused, efforts.

• Enables us to think through potential situations, and thereby steer our architecture in a better direction.

• Supports a lean “think before we act” approach.

• Potentially motivates teams, particularly those new to agile, to overbuild their solution.

• Critical for any team where a portion of the “back end” for their solution is deployed to the cloud.

• Easier to understand than UML deployment diagrams.

• Should be combined with threat boundaries (see threat model below) so as to address security concerns.

• This is an emerging architectural view, so most of the advice around this technique is vendor focused at present.

• Can be overly simplistic, particularly when “the cloud” is treated as a nebulous black box.

• Straightforward way to explore security threats to our solution long before we build/buy it.

• Threat boundaries can be indicated on any type of diagram, although a specific diagram is often useful.

• Can mask a lack of security expertise within the team by making it appear that we've considered the issues.

• Well understood by most IT and systems professionals.

• Diagrams can become quite large in complex environments.

• Captures a stable and long-lasting view of the enterprise that can be used to guide prioritization decisions.

• Easily understood by both business and technical people.

• Can be used to explore both future capabilities as well as existing capabilities.

• At the solution level, connects solution capabilities to implementation.

• At the enterprise level, connects business strategy to execution.

• Promotes a common understanding of domain terminology, which helps us to simplify our other artifacts through consistent terminology.

• Provides a high-level start at our data schema and business class schema.

• Supports a domain-driven design (DDD) approach to development [DDD].

• Can motivate overmodeling by people with a traditional data background.

• Can be used to explore either technical or business architecture issues.

• Can easily become overly complex.

• Concrete way to quickly explore what people want our solution to do and thereby identify a more consumable solution early in the life cycle.

• When used to design a few key pages/screens, this is an effective way to explore UI design details with stakeholders.

• When used to design all or most of the pages/screens, this leads to a lengthy “big design up front” (BDUF) strategy that often produces a detailed design that proves to be brittle in practice.

• UI designers often fall into the trap of showing stakeholders a beautiful prototype that can't actually be built, thereby setting unreasonable expectations.

• Prototyping tools may not exist for our platform, requiring potentially slower coding.

• Some users believe that the system is “almost done” when they see high-fidelity screen prototypes.

• Can be a great way to learn about an asset and the dependencies it is involved with.

• These tools often aren't available for all of the technologies used to build the asset or if they are, they are often expensive.

• The models generated can often be overly detailed (a reflection of the architectural problem we face working with it).

• Overview documentation provides a high-level description, including key diagrams, that can be quickly read by team members.

• Likely to be reasonably accurate because of its high-level nature, so can be trusted.

• Enables team members to make reasonable guesses as to where to dive into the implementation to make changes.

• We still need some way to understand the details.

• Some legacy source code can be difficult to work with, particularly code that has been worked on by many people over the years.

• There may be significant reluctance to change the source code due to high coupling within it and a lack of automated regression tests to identify potential problems when we do.

• We may not have the actual code used to build the currently running version of the asset.

• Enables teams to safely work on architectural components in parallel.

• Executable specifications are more likely to remain in sync with the application; and when run as part of our automated testing strategy, they reduce the feedback cycle when changes to the interface do occur.

• Requires time to develop and test the executable specifications and mocks/stubs for the architectural components.

• Potentially increases the chance that we will overbuild our solution, which increases both cost and delivery time.

• In regulatory situations, it requires auditors who understand this approach.

• Enables teams to work on architectural components in parallel.

• Details can deceive people into believing that the architecture will actually work (when it still hasn't been proven), thereby increasing risk.

• Important decisions are made early in the life cycle based on information that is likely to evolve, thereby increasing risk.

• Decreases morale of developers by taking away the challenges associated around architectural work.

• Increases overhead to evolve the architecture when the requirements change or the chosen technologies evolve.

• Supports a documentation-based governance strategy, increasing organizational risk.

• Requires significant time (and cost) to perform.

• Potentially increases the chance that we will overbuild our solution, which increases cost, delivery time, and overall risk.