Appendix
Forms and Templates
The following forms and templates are intended as starting points only, illustrating some common best practices. Your organization will have specific style guides. Your legal department and your security office will have specific verbiage that must be included. Your project management office and technical writers will all have requests and requirements that will impact your final version.
Your method of publication may also impact the content and style of these documents. These are presented in their simplest form, as if they were paper documents. But your company may expose these as HTML, or may even store the individual snippets of content in a homegrown or third-party database with a front end that pulls the pieces together on demand, such as the Rational Suite of products acquired by IBM in 2003. These database-driven architecture and requirements systems retain version history and have a built-in publication interface assuring the most current version of the documentation is always available. But for our purposes, old school paper forms will illustrate the basic points.
Architecture template (strategic vision and tactical roadmap)
<FunctionName> Architectural Plan
This is a formal corporate document. It should follow all corporate standards for logos, typesetting, colors, headers and footers, confidentiality notices and disclaimers.
1. Purpose
1.1. The purpose of this architectural plan is to outline <insert organization name, i.e. MyCompany> architectural strategic plan and tactical roadmap for <insert clear, direct description of the function. Keep sentences clear, simple, and direct.>
2. Scope
2.1. This architectural plan applies to <Insert clear, direct description of who/what/where is covered by this architectural plan (e.g., “all third-party, cloud-based applications which directly interface to MyCompany business processes and data”). >
3. Business Need
3.1. This is where you will document the business justification for this function. If you can’t clearly articulate how this architectural strategy will benefit the business, then there is no need to go any further. The goal is not just to explain how an investment of budget and time on this strategy will pay for itself, but to create a compelling case why an investment here will provide more return for the business than other projects the business is considering funding. This section is typically only one or two paragraphs.
4. Long-Term Strategy
4.1. This is where you cast the vision for what the function will look like in three to five years, or whatever your planning horizon is. This is not necessarily the ultimate end-state, but rather a best possible realistic scenario for that time frame, given the constraints of your environment (i.e. legacy application limitations and competitive pressures). Diagrams are encouraged, but keep them simple. You are creating a napkin-drawing to explain the concept, not giving all the design details for a technician to implement. This section is the bulk of the document, typically two to ten pages.
5. Tactical Roadmap
This is the cycle-by-cycle plan for moving from current state to the architectural vision above. The planning cycles are typically aligned with your budget cycles, with a documented tactical roadmap plan for each year. For each planning cycle iteration, you should limit the goals to four or fewer projects.
Each of those goals should briefly state where the ROI for that cycle will be coming from, and how soon it is to be expected. Keep in mind that by listing the ROI here, you are committing to incorporate the collection of these metrics into the project.
For example:
5.1. 2017-01 - Implement automated System Integration Testing in Environment X. Will reduce time projects spend in test environment and increase speed to development.
It isn’t necessary for the tactical roadmap to spell out the complete path to the final destination, but it should extend at least two years into the future.
In some cases, the maturity of your organization has already achieved the end state. You still need to document the business need (section 3) and strategic vision (section 4) in this document, but the roadmap can simply note that no additional changes are necessary.
The tactical roadmap for the most immediate planning cycle may name specific business-requested projects, but beyond that it will contain primarily IT-requested projects – descriptions of the types of infrastructure change that the architects would like to see. As each planning cycle approaches, though, the architects will use this tactical plan information to help identify the business-requested projects that can be used instead. Ideally, by the time each planning cycle begins, all of the tactical goals will be able to be addressed through business-sponsored projects.
6. Communication Plan
6.1. How is this vision to be communicated? The <insert position title, not name> or their designee shall be responsible for determining what job roles, if any, must take specific training.
6.2. Will there be training available? Is that training mandatory? For what roles? Whose responsibility is it to ensure that all of the correct people are educated? How often should the training be repeated in order to stay current? “The <insert position title, not name> or designee will develop requirements for any specific security training deemed necessary, to be administered and tracked through <corporate education portal>.”
7. Revision Cycle
7.1. Both the long-term strategic goal and the tactical roadmap will be undergoing constant revision as business priorities, regulatory requirements, competitive pressures, and the latest technology change. How often should the document be reviewed and updated? How are changes made and approved?
