Purpose of Sprint Zero:
Possible solution options
Costing estimates
Modify vs Buy vs Build vs Partner
Identify risks
Sample Document Template
IT Architecture Vision /
Sprint Zero Architecture
Problem Description 3
Problem Statement 3
Business Vision Statement 3
Business Capability Impact 3
Change Drivers & Opportunities 3
Business Objectives 4
Architecture Vision 4
Architecture Assumptions 4
Constraints 4
As-is Conceptual Architecture 4
To-Be Conceptual Architecture 4
High-Level Non-Functional Requirements 5
Availability 5
Performance 5
Volumes 5
User Interactions 5
Business Continuity 5
Security 5
Operations and Monitoring 5
Networking 6
User Interface Requirements 6
Architectural Requirements 6
Proposed Solution Option(s) 6
Costing Estimate 6
<<This section of the vision includes the problem statement, list your stakeholders, write the business vision, including the business objectives and high level requirements>>
<<Describe the concerns from the business. This is usually written by a business user defining the problems or new requirement statement that needs to be solved. This should include a list of the stakeholders, the business capability or value stream is impacted.>>
Stakeholder
Business Capability
Business Problem/Concerns
<<The purpose of the business vision statement is to agree at the outset what the desired outcome should be for the architecture, so that architects can then focus on the critical areas to validate feasibility>>
<<Diagram(s) explaining what business capabilities are impacted. This can be a capability model or value chain diagram, depicting what capabilities are impacted by the Vision>>
<<The purpose of section is to identify the change drivers and opportunities behind this vision for the target architecture. Drivers that impact the decision made to the target architecture. List potential opportunities to implement the target architectures>>
Business Objectives
<<List the business objectives that will resolve the business problem.
List the technology objectives, such as migrate, replace, decommission against the systems. This usually are part of an application roadmap>>
Architecture Vision
<<List the architecture principles that will be applied and leverage. Refer to the architecture principles standards>>
<<List the Architectural assumptions that have been made in the selection the proposed options.>>
<<List all the constraints that might impact the target architecture. Lso list possible risks and mitigation strategy for each ris.k>>
<<The as-is conceptual architecture is a visual view depicting the context of the current architecture>>
To-Be Conceptual Architecture
<<The to be conceptual architecture depicts the target state of the architecture, this includes solution options, applications impacted, the data requirements, security requirements, infrastructure and what technology will be leveraged or needed>>
High-Level Non-Functional Requirements
<<This is a high level non-functional requirement. The intention of this section is only to try and highlight some known non-functional requirements. This does not have to be detailed, as the detailed non-functional requirements will be completed in the Solution Architecture Document>>
<<List the hours of operation, availability requirement, will there be batch windows, planned downtimes, etc. >>
<<List the user requirements for response times and acceptable data latency>>
<<List the average volumes expected. E.g. How many transaction do you expect daily or monthly. If you are using files, what will the file sizes be?>>
<<List the number of users, how many users will use the system at the same time, and the user’s locations>>
<<List your high level disaster recovery plan and acceptable number of transaction and users on the DR site>>
<<List your authentication and authorization requirements, do you require audit controls, and confidentiality of the data.>>
<<List any operational and monitoring requirements>>
<<List the networking requirements, such as LAN, WAN and Cloud networking requirements. Will the solution require a VPN or Load Balancer, etc.>>
<<How will the user use the application. Web browser, desktop, mobile, etc.>>
<<List here any architecture requirements such as integration platforms needed, what environments need to be set up (Dev, QA, UAT, Prod), and what development technology stack if nay, will be required.>>
Proposed Solution Option(s)
<<Create proposed solution option. This might be high level, and can be buying a Vendor solution versus build your own solution. Include technologies needed and how the system will be hosted. You can have multiple options if no upfront proposal has been made by business stakeholders or no architecture guidance and standards has to be followed.>>
<<This is a very high level cost estimate indicating to business what this solution will cost and how long to implement. We call this a ROM (Rough Order of Magnitude) >>