What does an Agile Solution Architecture need to record?

A good Solutions Architect looks after technical soundness and integrity of the solution the same way as good Project Manager looks after schedule and budget constraints.

With software engineering moving towards agile methodology's, the effort for IT projects is shifting away from discreet design and build phases and towards a blended model whereby the design and build occur simultaneously

Lets discard architectural dogma, frame up how solutions architecture could work within a agile framework.

Agile Solution Architect (ASA) is a team member in a scrum team involved in the delivery of the sprint increment. The ASA has prominent roles in the following scrum activities:

• Grooming – Involved as a team member giving input into stories and the estimation process

• Sprint tasks – The ASA mentors and guides the design effort, note there is no requirement that they do all the actual design, as this is against the ethos of scrum (team member role specialisation), but as an experienced designer they must influence and guide the process Communicating to the architecture to architectural stakeholders (product owner, project stakeholders, and development team) the vision, the trade-offs made and the current status of how far along the implementation of the architecture is. Updating architectural work products; updating models, recording significant decisions.

• Planning meeting – as a team member the ASA assists in the decomposition and estimation process

High-performing scrum teams are highly collaborative; they are also self-organizing. The team members doing the work have total authority over how the work gets done. The team alone decides which tools and techniques to use, and which team members will work on which tasks. The theory is that the people who do the work are the highest authorities on how best to do it. Similarly, if the business needs schedule estimates, it is the team members who should create these estimates.

A scrum team possess all of the skills required to create a potentially shippable product.

Most often, this means we will have a team of specialists, each with their own skills to contribute to the team's success. However, on a scrum team, each team member's role is not to simply contribute in their special area.

The role of each and every team member is to help the team deliver potentially shippable product in each sprint. Often, the best way for a team member to do this is by contributing work in their area of specialty.

Other times, however, the team will need them to work outside their area of specialty in order to best move backlog items (aka user stories) from "in progress" to "done."

What we are describing is a mindset change from "doing my job" to "doing the job." It is also a change in focus from "what we are doing" (work) to what is getting done (results).

Describe the reason for the problem (business problem) and what the current expected outcome is, based on this you can describe a System Metaphor, this is a simple shared story of how the system could work, a metaphor.

This story typically involves a handful of components, interactions and patterns that shape the core flow of the system being built.

Solution Architecture is not Software Architecture so the correct level of abstraction is the system of systems level, or how multiple systems interact.

The picture is not the solution design, the reasons for drawing that particular picture and the picture is the solution design. (Blueprint and Decisions)

Document the reasons why you have included any component into your system metaphor by assigning clear responsibilities to each component. The component, its responsibilities within the design and the interactions it has with other components fill out the system metaphor (CRC – Component (Class) Responsibility Collaborator)

Think of these as Architecturally Significant Decisions. Architecturally Significant Decisions (ASD) are ones that have the highest impact on costs and risks of the system and its delivery. (An agile project is both design and delivery, so they are different sides of the same coin) Enterprise and Non-functional requirements fit in well here.

The solution architect is a stakeholder the product owner collaborates with when building out the user stories during the story workshop meeting. It is the responsibility of the solution architect to advise on costing and risk mitigation. The solution architect is responsible for driving the agenda on critical architectural decisions and for steering the product owner towards the area of optimal cost and risk.

If they relate to an ASD their significance to that decision must be recorded

Solution Architecture should be minimal; you should keep the overview of the whole system coherent.

The solution design should be limited to the areas with critical impact, thus leaving a maximum of design space for other team members.

The as built components and the interfaces between them as well as the rationale leading to this architecture must always be clear

Architecture is the fundamental organization of systems embodied by their components, their relationships to each other and to the environment, and the principles guiding their design and evolution.

Let's take this definition apart and focus on its key elements to make sure we're all on the same page:

1. Organization of systems. In other words, architecture is something you do with systems. You organize them. Architecture is something you do, not something you buy

2. Environment. If you look at the enterprise as a system, what is the environment of its component systems? The people—the business itself. Many architects get this point wrong when they think of the systems as consisting of technology, where the people use the technology, as though they were separate from the architecture. In fact, the people are part of the system

3. Evolution. Change is built into the definition of architecture. If you think of architecture as some diagram you can put on your wall, be it your data architecture, Java architecture, security architecture, or what have you, you're missing the big picture. Such a diagram is at best a static snapshot in time of your architecture. To accurately represent architecture, you must include the principles for the evolution of that diagram.

Yes, you have to design the applications, middleware, networks, and so on—but those are all simply means to an end. It's how people use those components to achieve the goals of the business that is the true focus of the architect.