While my recommended development process prescribes writing project and iteration plans, few organizations choose to adopt it, and use their own or no process in particular. Not establishing a communicable plan and follow it leaves a gap in my architect work.
Therefore, I feel more comfortable having a development plan outlines in my solution architecture document, which helps me both communicate and ensure solid backing of my intentions with respect to iterations and increments.
Even if the organization chooses to write project and iteration plans, I still find it practical to present the plan from an architectural perspective, highlighting the architectural significance and design impact in each step of the plan. It helps me lay the ground for much of the subsequent content in the architecture document and strengthens the rationale behind the project and iteration plans.
I often present the development plan in a fairly simple table:
| Build | Description | Architectural significance | Status |
|---|---|---|---|
| Render PDF | Web app that loads and renders a PDF from a file. | Proof-of-concept Blazor app that verifies that a PDF can be read as a byte stream from a data source and can be rendered in a Blazor page. This is essential to developing the envisioned solution using the preferred technologies. | Done. |
| Boilerplate web app | Deployed, runnable and properly branded web app. | Establishes the development environment, verifies the deployment pipeline, verifies the production environment, sets up a bare-minimum web app that picks a session id and emits log entries and metrics to mon. | Ongoing. |
As the example above shows, I can add goals that aren’t necessarily mentioned in the project or iteration plans. Those are typically focused on achieving business goals and might not mention architectural goals to overcome technology-related challenges to mitigate identified technical risks.