1. ATS Architecture Design Solution Intent
Project Name
Technical Lead:

2. Guidance to Authors to include-Delete this slide in your presentation
Organization of this Deck
This presentation is intended to provide the essential information to communicate an architecture at the portfolio, program/solution or application level. This presentation is organized into a Decisions section and Rationale section to help influence your thinking about the content of your deck.
•The Instructions and Guidance section – is intended to assist you with guidance and recommendations on best to utilize this template. Remove this section before sharing your Solution Intent with your stakeholders.
•The Decisions section is intended to be for communicating “What” is going to be done – bottom line answers. This section has the widest audience and should be kept to the absolute minimum necessary. This section of the template contains the highly recommended set of slides that would typically constitute the minimum necessary set to effectively communicate the architecture. The vast majority of audiences are interested in this section.
•The Rationale section is for describing “Why or How” the decisions were made. This section has a narrow audience that is likely to include other architects and architecture review boards. This section of the template contains ideas for you to consider to include as you work with your team or explain the architecture to other architects. This section contains a collection of slides that have been found to be useful in certain circumstances and should be treated as ideas for your use – not a collection of required slides to be mechanically filled out. Use these slides judiciously based on your particular need.
Applicability
The Solution Intent can be used across the spectrum of architecture activities from portfolio, solution and systems/applications. The same template is used with different levels of detail spanning conceptual, logical and physical realizations of an architecture. A single Solution Intent for a portfolio can lead to one or more (1:n) Solution Intents for Solutions. The decisions reached at the portfolio level may significantly contribute to the business context of the solutions. Similarly, a Solution Intent can lead to one or more (1:n) System or Application Solution Intent. Decisions reached at the Solution level can significantly contribute to the business context of the system or application. The Business Context may have other sources as well not shown in this diagram.
Maintenance
The Solution Intent must be considered a living document.
Other General Guidance
•It is imperative that your diagrams show current state, future state what is changing, what is being added and what is being removed.
•Feel free to reorder the slides to meet your needs. The current order is based on the typical PI Planning architecture context.
•Lead Developer should continue to create additional artifacts beyond those listed in the Solution Intent if it helps them do their job. This deliverable does not constitute everything an architect solutions intent may include, but is intended to convey the minimum information necessary to communicate an architecture design.

3. Guidance to Authors to include-Delete this slide in your presentation
Topic Portfolio/Enterprise Solution Application/System
Topic
Portfolio/Enterprise
Solution
Application/System
Structure and Technology
•Conceptual Architecture with Solution Capabilities and Systems (if applicable)
•Include strategic technology choices
•Repeat for Current, Future and Increment states as appropriate
•Association of Solution Capabilities to Feature and to Systems
•Repeat for Current and Increment states or changes highlight on a single picture
•Repeat for Future state if appropriate
•Logical component level structure with Technology choices
•Repeat for Current and Increment states or highlight changes on a single picture
Interactions
Conceptual interactions between Solution Capabilities
Logical interactions between applications or systems
Physical interactions between components and other systems
Infrastructure
Strategically important infrastructure decisions
System level logical infrastructure decisions
Component level logical infrastructure decisions
Security and Privacy
Broad, cross-cutting decisions
Solution-specific security principles and direction
System-level security and privacy implementation
Business Context
•Business Capability Map
•Business Process Flows
Appropriate reuse of material from the Portfolio/Enterprise level Solution Intent
Appropriate reuse of material from the Solution level Solution Intent
Content Details
•This table describes the general guidance for the level of detail intended for major topics in the Solution Intent and the general timing of the delivery of the Solution Intent.
•Each row represents a significant topic/slide in the template
•Each column represents the type of architecture activities
•Generally speaking, the level of detail can be categorized as:
•Portfolio/Enterprise: conceptual level down to Solution Capabilities. There can be definition overlap across level 2 Business Capabilities and Solution Capabilities. Interactions can be between Solution Capabilities (if a solution does not yet exist) or existing applications/systems
•Solution: Logical level down to feature assignment to applications/systems. The applications/systems are treated as black boxes with a focus on feature assignment to applications/systems and interactions between the systems.
•Application/System: Logical structure and physical deployment
•Updates are continuous based on the cadence appropriate for the type
•Ongoing Planning and Program Increment Planning – As the portfolio/product roadmap emerges, the Solution Intent for the Solutions and Applications should be updated to support the desired Features well before the next actual sprint cycle.

4. Current State & Future State: Example Only Below
•Use a picture/diagram to describe the architecture components/layers and technology choices in as few diagrams as possible
•If a technology choice is still pending, be sure to note that on your diagram. If it’s a significant technology choice, not having a choice then risk that should be raised. A typical mitigation for this risk is to have a review early to make that decision.
•Ensure the picture can be read during a presentation
•Visually represent both current state and future state for review. Recommended used of color: Red for deletes, Green for adds, Blue for updates. Use different line patterns (dashed, dotted, thickness, etc.) in addition to the colors to assist the color blind audience.
•Use more slides if needed, but keep it to one slide if possible

5. New & Existing Architecture Feature Summary
•Use this slide to clearly communicate new and existing architecture decisions or implementation approaches that are hard and or expensive to change.
•Briefly describe the nature of the issue. For example, “A policy exception (DIO1234) is in place because the PHI database is not encrypted”
•Briefly describe what should be done for the solution. For example, “Implement Transparent Data Encryption (TDE)”.
•Use more slides if needed, but keep it to one slide if possible.

6. Interactions Diagram Here
•Portfolio: Use a picture to describe the interactions between Solution Capabilities including the types of information flowing between them. Visually depict the solutions or applications that fulfill the Solution Capabilities (if known)
•Solution: Use a picture to describe the interactions of the software as a black box with other systems including integration methods and security
•Application: Use a picture to describe the interactions of the individual application/system components with other systems including integration methods and security
•Ensure the picture can be read during a presentation
•Visually represent both current state and future state for this program increment. Recommended used of color: Red for deletes, Green for adds, Blue for updates. Use different line patterns (dashed, dotted, thickness, etc.) in addition to the colors to assist the color blind audience.
Use more slides if needed.

7. Logical Infrastructure
Diagram Here
•Use a picture to describe the logical infrastructure decisions including disaster recovery and security approach
•Visually represent both current state and future state for this program increment. Recommended used of color: Red for deletes, Green for adds, Blue for updates. . Use different line patterns (dashed, dotted, thickness, etc.) in addition to the colors to assist the color blind audience.

8. Non-functional Requirements
Description
Approach
Multi-tenancy
Describe the requirement
Describe how multiple tenants or clients will be segregated.
Upgrade or Update
Describe how the architecture supports your upgrade or update requirements.
Availability
How will the architecture support the availability requirements?
Capacity
How will the architecture support the Capacity requirements?
Continuity
How will the architecture support the Continuity requirements?
Provisioning
How will the users and/or the application be provisioned?
Automation
Describe how the architecture maximizes automation and CI/CD
•This slide lists the rationale for architecture decisions based on an example set of non-functional requirements.
•Briefly describe the requirement for your solution for each of the major Requirement topics.

9. Solution Options
•Use this slide to describe options that were considered that led to your decisions for a particular architecture style or technology choice. Include the evaluation results such as pros/cons or weighted scores that support your decision.

10. Architecture Considerations
•Use this slide to capture assumptions, constraints, risks and dependencies as appropriate