The Architecture Principles Task Force has been charged with defining the set of HSPC Architecture Principles and validating them with the larger group.

Members:

GuyR - Lead

Amir Abrams (Unlicensed)

Bill Tomer

Bryn Rhodes (Unlicensed)

Jeff Danford

John Svirbely

Josh Dees (Unlicensed)

Ken Rubin

Preston Lee

Rick Freeman

Meetings:

In order to consolidate effort and reduce the number of meetings, the task force discussions will be conducted asynchronously as much as possible. Reoccurring meetings will be included as a topic of discussion in the Platform Engineering meeting held every other Friday.

Contact Vadim Polyakov (Unlicensed) and Preston Lee to request an invite.

Communication:

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.

Objective:

Identify 7 high level Architectural Principles that are of the highest value to the HSPC to serve as a base set.

Strategy:

Each member of the task force will submit (3) principles
The set will be consolidated into a set of Candidate Principles
Each member of the task force will rank the candidate set of principles
The task force will review the rankings
The 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?
2/2	Submissions deadline
2/6	Submissions compiled; request for rankings submitted
2/13	Rankings due
2/17	Platform Engineering call: rankings review; clarification of extremes of rankings?
2/24	Candidate set distributed for final objections
3/3	Final objections resolved
3/6	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