Recognition Requirements for Methods
Methods are evaluated and accepted as part of the certification process. The Certification Authority will maintain and make available a list of recognized methods that may be cited by certification Candidates.
Candidates for certification may also cite methods that are not listed, in which case the method will be evaluated for recognition and inclusion in the list of recognized methods.
Methods may be submitted for recognition with an application for direct certification, or by an Accredited Certification Program (ACP), either at the time of accreditation or subsequently. ACPs are also able to evaluate methods against the Recognition Requirements and submit them to the Certification Authority for inclusion in the Recognized Methods listing.
For the purposes of these method recognition requirements, the word “architecture” is defined as the fundamental concepts or properties of a system1 in its environment embodied in its elements, relationships, and in the principles of its design and evolution (International Standard ISO/IEC/IEEE 42010-2011). For the method to be meaningful in this context, a key deliverable of the method must be an architecture description (defined in the Standard as a work product used to express an architecture).
To be recognized, methods must enable or support “architecting” in its very essence and therefore distinguish themselves in their activities from engineering practices. To meet the recognition requirements the description of the method must demonstrate how interaction with the stakeholders is established while framing or delineating the problem space and making fundamental choices that impact the solution characteristics and/or its implementation.
Some methods go beyond architecture. For example, they include project management, corporate authorization processes, implementation regulations, code generation techniques, etc. For the purposes of this recognition, the submitted information should primarily focus on demonstrating that the architecture-related parts conform to the method recognition requirements, and not on the rest of the method.
|Relevance||The method must be meaningfully applicable to the architectural domain of the certification; for example, IT, EA, business, etc.||Value proposition of the method and summary of approach.|
|Efficacy||The method must be demonstrably successful in practice. Successful means two things:
1. When used correctly, the method routinely has the effects it claims to provide.
2. The results satisfy the needs of the method’s constituencies.
|End-user/customer testimonials or fully worked (possibly anonymous) examples.|
|Active User Community||The method must have a current active community of users; historically significant but disused methods are not of interest.||User rosters and community statistics, random surveys of users, or proof of community events.|
|Well-Formed||The method must have explicitly defined inputs, participants, roles, process steps, outputs, results, and deliverables.||Documentation example.|
|Documented||The method must be well-documented and subject to consistent interpretation. This documentation comprises at least a specification of the method’s deliverables or results, and the process by which they are created (especially the architecture description). These specifications should be expressed with some rigor and detail.||Copy of documentation.|
|Training Available||The method must be supported by self-paced or instructor-led training to a published, common curriculum.||Examples of training materials or random surveys of instructors and students.|
|Managed||The method must have a defined process for feedback from practitioners and the maintenance and revision of the above materials (community, documentation, training, collateral).||Process definition. Identification of responsible parties.|
|Supporting Collateral||The method must be supported by collateral materials for use by practitioners. These materials might include, for example, templates, tools, examples, and best practice recommendations.||Examples of supporting collateral. At least one of the examples must be an architecture description.|
1 A system is a collection of components organized to accomplish a specific function or set of functions (IEEE 610.12-1990).