Architecture-First Strategy
Overview
Bio: Tony Marius
Over the years there have been many attempts to develop good software by using software methodologies. Some of these methodologies include Rational Unified Process, Waterfall, Scrum, and Rapid Application Development. These techniques are all after the same goal, which is to build quality software on a budget and timeline.
It is difficult to build good software. Without a good technique the software can be created, but it may have low quality and cause big problems as the project gets closer to production.
For instance, the Scrum technique works, but I have seen its limitations on many projects. On paper, Scrum supports change but in practice it is hard to change things once the coding has started and the database already has data. This problem leads to choices where important items like security are passed over instead of being integrated. This makes it very difficult to build a comprehensive product.
What I am describing here adheres to Agile principles and describes a philosophy and not a framework, such as Scrum. The Architecture-First Strategy is a technique that uses pieces from the existing methodologies and real-world techniques based on experience.
Workflow
Project Workflow
This diagram shows a workflow through a project's lifetime. It represents a 30,000-foot view of the relationships between roles, tasks and timelines. It is not important to understand how each section works in this article. It is more important to visualize the relationships and the flow.
There are two architectural results in this process: Business Architecture and Technical Architecture. The Business Architecture includes the business related artifacts that are used to develop an application that meets the needs of the users. The Technical Architecture pertains to the technical components that will enable the application to work successfully.
Any of these roles can be played by the same person. At a high level, the process go as described below.
Business Architecture
The Business Analyst (BA) gathers functional and non-functional requirements from the stakeholders. The BA works with the User Interface Designer (UI) to create Wireframes and Mockups to discover what the users' desire.
Wireframe
Next, the BA covers the requirements by developing Use Cases while using the Wireframes as input.
Use Case Diagram
On the data side, the BA develops a Domain Model representing the important entities. The Database Engineer (DE) produces a Data Model that is used to create the corresponding tables.
Domain Model
The DE sets up the database structures as implementation of a relational DDL or NoSql schema. The DE uses the Use Cases as input to develop Data Scenarios that include coverage of all execution paths identified in the Use Cases. These Data Scenarios are realized as SQL or NoSql queries. The Data Scenarios will both prove out the Use Case and Data Scenario coverage of the requirements.
Business Architecture Loop
The BA, UI and DE work in a tight loop with the stakeholders to ensure that the solution is properly molded.
Similar to RUP and Scrum, the users can see and interact with the UI for their workflow needs. The UI Designer creates active mockups by using the results of DE queries as input to each screen. In this way, the Use Cases, Wireframes and Database become more and more refined without the heavy cost of backend code change. Based on complexity, the UI Developers can get involved at this time to produce a real UI with a mocked backend.
At this point, the Sprint Plan has not been completed for the full build and only contains the early project work related to Analysis and Design.
Technical Architecture
Technical Architecture Loop
In the Architecture-First approach, the High-Level Architecture is simultaneously defined by the Architecture Team (Arch). Items, such as the database, server and UI technologies are chosen at this time. The IT team uses the definitions to set up the desired environments
The Arch identifies technical risks and unknowns and perform various Proofs of Concept (POCs) to ensure the desired architecture can support the requirements. The results of the POCs will either confirm a design choice or cause it to change. The information is used to develop the Framework that will be used on both the client and server sides.
The Arch works with IT to determine the local development environment as well as configuring DevOps. The goal is to have as much architecture in place as possible before involving the Backend Development (Dev) team. This allows the Arch team to define the Technical Architecture in the most cost-efficient manner before there are too many developers and too much code to support. As we know, once the team is too big it is very difficult to change direction and make sweeping changes that are needed.
BOA Platform
Note: A working example of a platform based on the Architecture-First strategy can be found in the Open-Source BOA Platform. It is a nice starting point for building business-focused applications.
Testing
The QA team uses the Use Cases and the Technical Architecture information to produce a Test Plan. This Test Plan is used to derive various Test Cases well before application development starts. The tests can be reviewed for coverage. Often, the review of the Use Cases leads to refinement or re-prioritization of the requirements.
Application Development
At this point, it is safe to map out the User Stories related to building out business features in Sprint Planning. The project is not sacrificing good architecture and framework practices while only supporting the easier requirements.
The first members of the Dev team should be the UI developers. They build and deploy the UI based on the Business Architecture developed in the early phase. The UI processes data, such as JSON that is a result of a Data Scenario by the Data Engineer. As is the case with the other workflows, it is more efficient to make changes to the application UI based on user feedback and requirements with no backend rather than if the backend has to change as well.
The last group to plug in are the backend developers. By this time, the database is moderately mature after handling many Data Scenarios, the UI has defined the information that is needed in the backend API, and the Architecture Framework has been defined with one or more services to use as templates. There is less that can go wrong at this point and fewer meetings where the backend team is blocked by undecided business or technical issues.
Other articles
This article is high level and will be new to most since it is a homegrown approach. Some other articles discuss