Architecture-First Roadmap

Overview

The Architecture-First approach is similar but somewhat different from the pure Agile and Waterfall approaches. It is primarily focused on producing a quality application by addressing the core requirements and risks first. The philosophy assumes that the technical requirements of the application are large and will reduce the quality of the application if not addressed.

The normal communication with Business stakeholders is though a classic business-based roadmap. These roadmaps look good on paper, but may not deliver the expected results. Project development is more dynamic than what is displayed in a classic roadmap.

The stakeholders want to see progress so that they can determine if the project is going as expected. The key is to find the best way to show progress while maintaining the quality goals.

Classic Roadmap

Classic Roadmap

The idea behind this business-based roadmap is to deliver business value for each release. The assumption is the entire feature has been delivered in this release. This includes related UI, backend and database components.

The standard roadmaps work, but there are problems that occur in the goal to build a quality product. Normally, the requirements have been estimated, categorized and mapped out in a plan to develop the application. For a simple application this may work out fine, but for an application with a decent level of complexity the quality or features may be sacrificed due to the timelines.

The software engineer may be forced to sacrifice quality in the coding solution when the date pressures are present. In this case, even reducing features will not ensure quality. If QA or UAT finds defects it may be too late to fix them properly. This may lead to the dreaded work-arounds and shortcuts. The best place to ensure quality is during the initial development itself.

The truth is, complex projects don't run in an orderly fashion. There are plenty of surprises and decisions that are made on the field. The age old metaphor of project building is based on real world construction, but it is closer to the dynamic behavior of sports such as Football. The coach and players initially have a plan, but must adjust to the realities once the game has started.

Architecture-First Roadmap

Project Puzzle

Bringing together a project is like putting together a puzzle. Depending on the size of the project, it becomes challenging to make all the best choices. Certain pieces are completed and then integrated. As more and more pieces are added the picture starts to become clear.

In the case of the puzzle, key pieces must be put together in order to successfully get to the next step. A project works in a similar manner where important items, such as when security is skipped early can be difficult to add later in the desired manner.

Architecture-First Roadmap

The Architecture-First roadmap looks quite a bit different from the classic business-based roadmap. The Business Architecture and Technical Architecture development is the main event for the first few releases. The goal is to build the ideal system by identifying and working through as many gotchas as possible and have elegant solutions since the there are few dependencies at this stage.

As shown earlier in the Architecture-First Strategy article, the artifacts feed each other. Therefore, the artifacts are part of the product development and not simply documentation. The Wireframes and Use Cases are derived from the Requirements and serve as requirements themselves.

The main thing to note is the foundation is built first with as few workarounds as possible. This approach is done in many projects, but often the feature development is started before the architecture is complete. At first, the stakeholders will need to gauge progress by artifacts and other deliverables instead of end-to-end features. When the developers start to build end-to-end features the architecture should be nearly fully formed.

Early on the users will validate the Wireframes and Use Cases at the detail level. This is a deliverable that should be taken seriously to uncover issues and make decisions before the coding has started. This is the first line of defense.

In the example roadmap of the retail application above the releases go as follows.

Release 0.1

Business Architecture

The Wireframes, Data Model and Use Cases are developed first and delivered in frequent meetings with the stakeholders. These items start at high level and then become more detailed during the process. The more detailed the artifacts are the higher chance that nothing is missed that will be costly if discovered while the application is being coded.

Technical Architecture

The Technical Architecture is defined and built starting in this release. This release also includes the Environment Setup and items such as DevOps Setup.

Based on the High Level Architecture and technical risks identified, there are POCs identified. These POCs will address unknowns and also verify technical assumptions. The result of the POCs will affect the Technical Architectural solution.

Release 0.2

Business Architecture

The Data Model is transformed into actual database tables or collections. The goal is to set up a mature database structure as early as possible. In order to facilitate this, the data engineer should exercise as many Use Cases as feasible as Data Scenarios. The Data Scenarios should be implemented as actual queries that are expected to be executed by the application.

At this point, the UI screens should be built as actual deliverables. Since there is no backend development yet, the data shown should come from results of the Data Scenarios. The results are mocked as if they came from the backend. The UI should be deployed and where the stakeholders can interact with the system and give feedback.

The Test Cases should be developed at this time. Since the input to the UI comes from the Wireframes and Use Cases, the Test Cases can be developed before the UI page has been developed. The advantage of this is the developer knows what to test against before turning it over to QA. This should save time by shortening the test and fix cycle.

Technical Architecture

The Technical Architecture is a major part of the development, especially with microservice and cloud applications. This work continues through Release 0.2. The Framework for the UI and Backend are being developed at this time. If the Framework is not developed fully the developer code will have framework fragments scattered all over the place.

Release 1.0

Business Architecture

The rest of the UI work is completed against the mocked backend. The users should be comfortable using the application at this time.

Since the Technical Architecture, Framework and Database should be mature at this point the backend coding should start. Ideally, the query from a given Data Scenario can be plugged into the backend code. The API can be negotiated with the UI team since they already know what data they need. The hope is that there are few issues discovered at this point that affect the backend coding.

As the backend code integrates with the UI and Database, the mocked data is replaced with real data. The QA team can now perform integration testing and feature testing.

Technical Architecture

The Architecture team can focus on items at this time, such as verifying performance of the application and reacting to developer requests. In the best case, any change is only in the Framework or infrastructure code. This allows for changes without adversely affecting the developers and project timeline.

Finishing Up

The Architecture-First Roadmap is focused on delivering quality by focusing on the prioritization of tasks. The full features are completed more towards the middle of the project instead of evenly along the project as the classic approach appears to do. The key word is 'appears', because important items are often avoided in the classic approach in order to meet the dates.

Further Reading

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