Architecture-First Project Management

Overview

This article is high level and touches on the key project-related gains of the Architecture-First approach. There is opportunity to discuss any of the items more deeply in the future.

Both Waterfall and Agile project management techniques work with the Architecture-First Strategy. The only thing affected is the priority and order of work items. The key strategy is to front load the important items, so they are addressed early and efficiently.

Project Plan

Project Plan

The tasks in a Project Plan are organized based on the strategy to handle the core requirements early and efficiently. Otherwise, it is just a normal project. The normal project planning tools and approaches will continue to work.

As discussed in the Architecture-First Roadmap article, the UI development happens early but the backend development waits until the architecture is mature. This approach is efficient and prevents continuous refactoring due to adding architectural components later in the project.

Agile

Taskboard

For an Agile project, creating Features and User Stories is the same as any Agile project. Again, the most important aspect is the prioritization of User Stories and Features. The goal is the same regardless of how the project is managed.

Estimating

As any developer knows, the estimation process is difficult to get right. The Agile approach definitely addresses that issue with the concept of Story Points. This gives the estimator as much information as possible to guage the difficulty of a User Story.

The estimate in a Waterfall project should include all of the complexity, but may have been done before the project even started. These estimates are needed to get a general idea of the cost of the project, but can easily be highly inaccurate.

In the Architecture-First approach, it also accepts the idea that estimating is difficult. The goal is to address as much uncertainty as early as possible in the project. As more and more unknowns are addressed, the ability to accurately estimate the rest of the project increases.

If the Use Cases are of high quality and the Non-Functional Requirements fully provided the project is off to a great start. This helps to prevent the dreaded unaddressed requirements that are realized near the end of the project.

The estimating technique used should consider the Use Cases and Non-Functional Requirements while working down to the task level to find all tasks that holistically handle the requirements. If a team skips this step and goes straight to User Stories and Tasks then there is a chance that requirements will be missed.

The Non-Functional Requirements are critical because they determine if the product is a boat or a ship. For instance, the estimate to handle 10 records a day versus 10 million records per day should be vastly different. The 10 million records per day design will be overkill for the 10 records per day requirement. And everyone knows what happens if the scenarios are reversed. Sometimes the question is not even asked until late in the project. The Architecture-First approach considers non-functional information, such as security, performance and availability to be critical and addresses them early in the project.

At-Risk Agile Project

At-Risk Agile Project Chart

Based on experience, projects tend to treat architecture as an annoyance because it is often difficult to estimate how much non-functional work is needed. In these cases, the architecture work is minimal leading to inconsistency and duplication. This eventually starts to add drag to the functional project work represented by the Feature Burndown line.

As the project moves further and further along, each unexpected complexity leads to work-around decisions. At best, the maintainability of the application is reduced. At worst, the quality and user experience is reduced while never addressing all the desired features.

As shown in this example, the easier features are delivered in the beginning of the project. Unfortunately as the project goes on, the technical debt starts to add up, and it makes supporting many of the features more and more difficult. This leads to decisions to remove or reduce features, which leads to a decreased user experience and quality of application. In this case, the features never burn down completely.

Architecture-First Project

Architecture-First Project Chart

With this approach, the architecture is considered a major component of the application. For example, working with databases are orders of magnitude easier because the database, such as Oracle or Sql Server was taken seriously by the vendors and provided a platform for developers to easily work with data. In a similar way, the goal of the project architecture is also to produce components that make it easier for developers to get their work done without needing a work-around.

The architectural work includes items, such as frameworks and strategies that make development more successful. The work is actually performed for most of the project duration, but the amount of work needed decreases over time. In classic Agile projects, much of the work is done under the name of refactoring. Unfortunately, this refactoring is limited because of how much existing code is present and how difficult it is to make the change without breaking other features. The Architecture-First approach attempts to push upfront the refactoring where it is cheaper and affects less components.

It is a real world so Technical Debt will still exist. The goal is to reduce it as much as possible by addressing that debt upfront architecturally.

As shown in the diagram, the Feature Burndown is purposely slow at first because it is most efficient to address the end-to-end architecture first. There are definitely going to be situations where there is a surprise that must be handled, but the chances should be reduced based on the efforts early in the project. Unlike a project that has plenty of technical debt, features should burndown quicker since the difficult parts have been addressed by the Techical and Business Architecture work.

QA

The QA team plays a critical role. They should verify that the Use Cases and Wireframes provide significant coverage of the requirements. This is the cheapest time to make changes. Requirements by themselves are just a list of bullet points that the analysis team determined. In raw requirements, there is a good chance that many important user items were not listed or thought through.

It is important to consider Use Cases and Wireframes as requirements. They are in a processed form where the BAs have reviewed the requirements and provided the artifacts as their understanding.

From a responsibility perspective, the QA team should own their environment. This means that they know what configuration and changes exist in the QA environment. They should be the ones who initiate the QA deployment as well as UAT deployments. And of course, everything should be based on a source control repository.

Finishing Up

The Architecture-First approach is not vastly different than current approaches using Waterfall or Agile techniques. It is more about prioritization and can fit into either methodologies.

The Business and Technical Architectures are major parts of an application. For example, cloud-based applications can give tremendous return on investment but are also technically complex. Ignoring the opportunities to handle this complexity through architectural efforts will lead to poor quality and reduced user experience.

Further Reading

The overview and context of this philosophy can be found in the Architecture-First Strategy article.