Timeline
Once we have established the plan for the project, we can make a strong proposal for the recommended phases and the timeline of the project. The phases are listed with the milestones and tasks within each one. The requirements to continue to the next phase would also be included. The requirements can be client-set, budget or investment based for example, or set by the developer - specific features that need to be completed for example.
It is essential that the Solution Architect works closely with the development team or vendor for this section to ensure that they have the capacity to meet the suggested deadlines. The team leader will also have a much better idea of how fast their developers are. It is the Solution Architect’s responsibility to margin this timeline to allow some flexibility - an essential part of managing expectations.
Estimate
The cost estimate includes vendor cost for development & design, project management and ongoing support from Solution Architect to manage the vendors and project. While most Solution Architects will be able to ballpark an estimate based on their own experience, this section is always done together with the vendors. Like the Timeline, the team leader will know their developers best and will be able to provide a far more accurate estimate for their team than the SA. It is the SA’s responsibility to evaluate the vendor and sufficiently margin the estimates given to allow some flexibility in the budget.
The following are some of the scenarios that will increase this margin:
- Clients that don’t have a clear vision or are likely to change requirements during development
- Vendors who do not have experience with this project type, size or target audience
- If it is the first time for the SA or client to be working with this vendor
- Tight schedule and hard deadlines
- Fixed budget
- More than 3 decision makers on the project
Always keep in mind that custom application development is never without risks, no matter how detailed the Solution Architecture is.
Final Review
The final part of the Solution Architecture will be a summary. The Architect’s final considerations and thoughts on the project based on everything learned so far. At this point they should be familiar with every aspect of the project, from the client to the development team/vendor, from the business angle to the technical angle and based on their big picture view they may have new insights into risks or opportunities that they will add to this section.
Write, Research, Rewrite
Writing Solution Architecture documentation is rarely a linear process. It is writing a draft and initial solutions, researching, then going back and rewriting things. During the Solution Architecture phase the entire document is basically in Flux with changes happening daily across all sections until it stabilizes and becomes a consistent clear guide to building the project. A document of problems with the best possible solutions.
The documentation is scientific in that it should be fact-based. Decisions and proposals are backed up by years of experience or research and prototypes. Solutions to problems should be the most efficient option, not just for the feature itself but for the application as a whole, not just technically the best solution but also from the business and user perspectives. A puzzle made up of thousands of pieces, each part fitting together to create a clear and recognizable result.