How to Start New Agile Software Projects: Selecting An Architecture

In my last post, I described the initial phase of determining the trajectory for a greenfield softtware project. Once you have established your vision and created a roadmap, the next step is to decide how the software system is to be built. This involves finding a suitable architecture for the system and devising a macroscopic design of the different components and interactions involved.

This post is part of a series. Check out the other posts in How to Start New Agile Software Projects.

Identify Qualities, Constraints & Risks

I usually rely on the following documents to accomplish this step:

Architecture diagram

In order to produce a useful architectural diagram of your solution, you need to spend some time thinking about how much architecture is actually required of the project. After all, every system has an architecture, whether it was planned or not.

You could rely on a canned architecture that is tied to the infrastructure or framework you’ve decided to use, or you can design an elaborate and detailed architecture.

I generally prefer to start out by spending some time thinking about the qualities of the system, and its constraints:

• Qualities are architectural characteristics that we want the system to exhibit. They often end with the letter “y” (such as: availability, reliability, scalability, etc). A good description and list of common qualities can be found in Fundamentals of Software Architecture: An Engineering Approach by Marck Richards & Neal Ford.
• Constraints are the restrictions that must be observed by the system. They may be driven by technical obstacles, regulatory compliance, user requirements, or simply by time and budget.

While this is enough information to derive a list of suitable system architectures, I prefer to follow the approach outlined in Just Enough Software Architecture: A Risk-Driven Approach by George Fairbanks, and practice this risk-driven method to determining software architecture. The process involves identifying potential risks to the project, prioritizing them by likelihood and impact, and using that information to inform the initial design of the system.

The resulting architecture diagram is a high-level representation of the important components and interactions required to mitigate the risks faced by the system, and to satisfy its required characteristics and constraints.

Sequence Diagrams

Sequence diagrams are one of my favorite ways to document my vision of how components and systems should be interacting with each other, and what happens behind the scenes of user interactions.

They provide immediate value because they are both very easy for the architect to produce, and very easy for the team and stakeholders to read and understand. They represent lower-level concerns than a user story map but provide an additional dimension by documenting interactions.

Step 3. Communication

The primary audience of your technical modeling artifacts is the development team. I prefer to compose self-organizing teams that can provide all the different skill sets needed to help the project thrive. That means my modeling artifacts are designed to provide guidance in several areas depending on the nature and scale of the project.

Whenever possible, I recommend working directly with the team to create all the modeling artifacts mentioned above. Doing so provides the team with opportunities to ask questions, gain a deep understanding of the project requirements, and align early on the “what” and the “how” of the project.

Next steps

Armed with a vision, a thorough understanding of the system requirements, an initial design that mitigates risk, and a whole lot of domain knowledge, it’s time for the team to roll up their sleeves and get to work. But who exactly is the team?

In the next article, I’ll talk about various approaches to team composition and organization. We’ll also review some of the common roles and responsibilities found in modern software teams.