The Architecture Principles Task Force has been charged with defining the set of HSPC Architecture Principles and validating them with the larger group.
...
In order to reduce the number of asynchronous channels members have to status in order to participate, asynchronous communication will be conducted on the existing HSPC Slack, #Platform channel.
Plan
Goal:
Establish a base set of Architectural Principles.
...
- Each member of the task force submits will submit (3 candidate ) principles
- Consolidate the list The set will be consolidated into a candidate set of principlesCandidate Principles
- Each member of the task force ranks will rank the candidate set of principles
- Group reviews The task force will review the rankings
- Top 7 are selected as the initial setThe top (7) will be selected as the Initial Set
Tactics:
- Meet 2x per month
- Draft milestones
- Create a page on the HSPC wiki
- Produce a deliverable
- Present to the Steering Committee for review
Milestones:
Date | Milestone |
---|---|
12/1 | Plan/roadmap fully described and communicated |
12/2 | Platform Engineering call: feedback on plan; request for submissions submitted |
12/9 | Platform Engineering call: status on submissions; issues/risks? |
122/122 | Submissions deadline |
122/146 | Submissions compiled; request for rankings submitted |
122/1913 | Rankings due |
122/2317 | Platform Engineering call: rankings review; clarification of extremes of rankings? |
122/2724 | Candidate set distributed for final objections |
123/293 | Final objections resolved |
123/306 | First draft |
Format:
Principles will be described using the following:
Name | Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: "support", "open", "consider", and for lack of good measure the word "avoid", itself, be careful with "manage(ment)", and look for unnecessary adjectives and adverbs (fluff). |
Statement | Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement be unambiguous. |
Rationale | Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision. |
Implications | Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: "How does this affect me?" It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed. |
The Open Group. Architecture Principles. 11/10/2016 from TOGAF 8.1.1.1 Online: http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html#tagtcjh_2