Project plan, timelines, milestones and task breakdown on the “epic” level
The detailed deployment plan is a crucial step in the solution architecture process. It involves creating a comprehensive plan that outlines the timeline for implementing the solution, assigning responsibilities to team members, and defining the necessary testing and validation steps.
The solution architect may be responsible for creating this deployment plan (it’s not always the case, but we want you to be prepared that it will be a part of your responsibilities). You work closely with the project management team to identify key milestones and deadlines, as well as the roles and responsibilities of each team member.
Note:
Milestones:
Definition: Milestones are significant points or achievements within a project that mark the completion of specific deliverables, stages, or important events.
Purpose: Milestones help break down the project into manageable chunks and provide a sense of progress. They enable stakeholders to monitor the project’s advancement and ensure alignment with project objectives.
Examples: Milestones can include completing the analysis and requirements gathering phase, finishing the system design, completing development iterations, conducting user acceptance testing, and achieving key project approvals.
Note:
Deadlines:
Definition: Deadlines refer to specific dates or times by which certain tasks, activities, or deliverables must be completed.
Purpose: Deadlines create a sense of urgency, drive productivity, and establish accountability. They ensure that project activities are executed in a timely manner, contributing to the overall project timeline.
Examples: Deadlines can include submitting project proposals, delivering design documents, completing development sprints, conducting testing phases, and launching the final system
To create the deployment plan, the architect defines the tasks required to deploy the solution. He then organizes these tasks into a timeline, with specific deadlines for each task. This helped ensure that the deployment process would be efficient and effective.
In addition to defining the timeline, the architect may also assign specific responsibilities to team members. This helps to ensure that each team member understands their role in the deployment process and could work efficiently to complete their assigned tasks.
Finally, the architect may define the necessary testing and validation steps to ensure that the solution would function correctly after deployment. This included unit testing (usually covered by developers, but the approach itself can be provided by the architect), integration testing, load testing, and user acceptance testing — depending on the project goals and requirements.
In big projects, where all the steps above may be covered by different team members (project manager, technical leads, QA leads etc.) the role of architecture will be to conduct architecture meetings and be sure, that development is aligned with the initial architecture and stakeholders needs.
The whole project may be represented as one or many epics (depending on the project scope and size).
Note:
Epic:
Definition:
An epic is a high-level user requirement or theme that captures a significant and valuable functionality or feature set of a system or application. Epics are often too large and complex to be implemented within a single iteration or sprint and may require further breakdown into smaller, more manageable user stories or tasks.
Characteristics:
Scope: Epics typically span multiple user stories or features, covering a wide range of functionality related to a specific business need or user goal.
User Value: Epics provide value to end-users or stakeholders by delivering a cohesive and meaningful feature set that addresses their needs, improves efficiency, or enhances user experience.
Long Duration: Due to their size and complexity, epics generally require longer development and implementation timelines, often spanning multiple iterations or development cycles.
Cross-Functional: Epics may involve multiple teams or disciplines, such as design, development, testing, and operations, working collaboratively to deliver the required functionality.
Epics may be created based on use case diagrams or high-level flow diagrams. When we have a big system and a huge amount of epics — it also would be helpful to create some diagrams to bind epic links to use cases or global flows.
This is the last article of this series. I hope the process of solution architecture became a bit more clear after reading it. See you in the next series.
