CT30A8912 Software and Systems Architectures Spring 2024 LUT University Architectural roadmap This activity helps you communicate the technical strategy for the implementation of your proposed software architecture, by clarifying the interdependencies and value of your ASRs over time, as well as the significant risks that may hinder the implementation. Part 1: Reviewing and organizing the backlog Go through your list of ASRs and determine to which one(s) of the following categories they belong: - - New features: Added functionality that delivers “visible” and positive business value to stakeholders Architectural or structural improvements: The “architecture runway” that should be maintained behind the scenes to keep the system functional, scalable, or sustainable in the long term Bugs or defects: Problems that have a “visible” negative impact for the stakeholders or might hinder the business Technical debt: Sub-optimal or quick solutions that may bring as a trade-off some cost or negative repercussions in the future Keep in mind that these categories are not mutually exclusive but rather often overlap. After you have identified each type of ASR, find out whether they have any dependencies to one another (e.g., ASR2 depends on the completion of ASR-1, or ASR-X must be delivered before our competitors implement a similar feature, etc.). Provide a justification for the priorities that depend on the business context and document the reasoning behind such decisions. Use this newly gained and deeper understanding about the dependencies and impact of each ASR to sort them out chronologically in a release timeline, proposing an “architectural roadmap” like the one shown in the figure below. The timeline does not necessarily have to be bound to specific dates, but can be organized on sprints, iterations, or product releases. 1(3) CT30A8912 Software and Systems Architectures Spring 2024 LUT University Part 2: Risk assessment The roadmap you have prepared is not set in stone but will be rather iteratively updated as the software implementation progresses. However, under some circumstances this timeline might change significantly. Such probability of things not going as planned is often called a risk. In most cases, a risk can be mitigated but still not fully avoided (i.e., reducing its probability to 0%). Thus, it is a good practice to create a contingency plan and establish actions that allow to reduce the impact in case the risk occurs. Discuss with your team, identify, and describe the top 3 risks that could significantly prevent you from delivering your software solution as planned in your roadmap. You can use a probability vs. impact matrix to quantify the level of risk. Include in the description any mitigation and contingency actions you would take for each risk. Deliverables Your written deliverable should describe at least the following aspects (but not necessarily in the same order): - - Material from the previous tasks, possibly updated Architectural roadmap Top 3 risks for the roadmap implementation, explaining how the risk level was quantified, the mitigation and contingency actions for each risk Work hour estimations for each group member, including this task and any previous tasks. Please also indicate how many hours were used for group meetings, how many hours for individual work Change log, indicating any significant updates made to the document since the last revision The written deliverable is returned as a single PDF document. If necessary, your models can be uploaded as separate image files. 2(3) CT30A8912 Software and Systems Architectures Spring 2024 LUT University Tips - - The architectural roadmap is an important element in the release plan of your software project. If the ASRs were prioritized using the “MoSCoW” method, then the “Must do” ASRs will be listed at the beginning of the timeline, likely followed by the “Should do”, and by the “Could do” ASRs in the same order of priorities, respectively Risks make you re-evaluate the importance of your ASRs and their implementation timing. An ASR with high risk and high priority should be addressed sooner in the roadmap, because it will add business value to the software product. On the other hand, an ASR with high risk and low priority should be postponed or avoided until it becomes essential, since it does not deliver enough value to justify running risks too early in the project. References Kruchten, P., Nord, R.L. and Ozkaya, I., 2012. Technical debt: From metaphor to theory and practice. IEEE Software, 29(6), pp.18-21. Poort, E., 2016. Just enough anticipation: Architect your time dimension. IEEE Software, 33(6), pp.1115. 3(3)
