1.6. Design rules in a NATO NEC federated environment
24. This guideline document describes a concept and model for how knowledge of proven solutions in the form of design rules can be documented and packaged in order to form a shared basis for the future development of NNEC based systems for NATO.
25. The processes in which design rules are identified, produced and used are not described within this guideline.
1.6.1. Problems or opportunity description
26. In the development of large systems of systems or federated systems for the future needs of the NATO there are several problems to be solved as well as opportunities to exploit. The problems range from what methods to use for requirements capture and design to how to solve detailed technical matters.
27. In order to be able to establish a set of building blocks that can be used to meet the needs of the future NNEC, design regulations are absolutely essential if the building blocks shall be possible to be used together and combined in different ways, from a technical as well as from a business point of view.
28. Design regulations in this context are the descriptive or normative regulation work necessary for NATO nations to be able to implement, configure and use systems in a federated environment. This includes not only technical and business design, but also the ability to manage and maintain these regulations to be able to provide the NATO nations with flexible component based systems.
29. Moreover, there is a strong incentive to endorse reuse of proven solutions or implementations and thus get a more cost-effective solution. The overall quality is also expected to benefit from this kind of reuse.
30. In this document we will focus on the model for design rules, and the patterns for setting up the SIOP and SIP:s between federations, this in order to be able to exchange information services between parties.
31. Design rules patterns and knowledge for supporting NATO Nations in designing NNEC compliant components and services can also be retrieved from different Nations repositories as reference architectures, Sweden Design rules (releasable to NATO) will be included as one of the Partner nations reference architecture as recommended and proven patterns in order to achieve NNEC interoperability.
1.6.2. Solution
1.6.2.1. Design rules in the NNEC context
32. Design rules are about reusing knowledge of proven solutions. In the context of NNEC we are especially interested in reuse of solutions that provide typical NNEC characteristics. In addition to this, the use of design rules aim at making the development of NNEC more cost-effective and improve the quality in the resulting products.
33. As mentioned before, a design rule is in the most general description a three-part rule, which expresses a relation between a certain context, a problem or an opportunity and a solution.
34. Different design rules may be in conflict with each other, e.g. in that the solution of one design rule can be incompatible with the solution of the other.
35. Moreover, design rules can be singular or aggregates meaning that it either is an atomic rule or an aggregate of rules that together constitute the rule. The aggregate may include rules on how to combine the possibly conflicting aggregated rules in order to generate a rule according to the current priorities.
36. Design rules may be implemented for solutions on different levels. There may be design rules for specific technical design problems or rules, how to handle a major business opportunities. It is however anticipated that the majority of design rules valid for an NNEC-system will be focused on the higher levels.
37. Design rules can be used in order to meet functional as well as non-functional needs of the system of interest. It should be clear from all design rules which problem or opportunity it is supposed to solve.
1.6.2.2. General guidance for using design rules
38. The prime prerequisites for implementing a design rule are:
-
The use of the design rule shall make the resulting design "NNEC-compliant", i.e. the design rules shall provide essential NNEC-characteristics such as flexibility, interoperability, security and usability
-
A design rule shall provide a solution to frequently shown problems, to enable reuse of solutions or implementations and thus get a more cost-effective solution.
-
A design rule shall provide a solution to difficult problems, or explore an opportunity, i.e. be a part of the corporate or federated memory
-
A design rule shall improve the quality of the resulting product relative a product solution not using the design rule.
39. At least one of the mentioned prerequisites should be fulfilled. There may of course be other valid prerequisites, which will be assessed and used to initiate the design of a design rule.
40. Design rules shall consist of either atomic rules or aggregates of rules that together shall constitute the rule. The aggregate may include rules on how to combine the possibly conflicting rules in order to generate a rule according to the priorities.
41. An atomic design rule must not contain solutions for more than one subject area, e.g. mixing of business and technical subjects shall be avoided. Detailed technical rules shall in the same way be separated from rules of information or logical nature.
42. Design rules shall where applicable be based on concepts and rules in an extended NATO Architecture Framework.
43. A design rule shall not be of too low granularity or too trivial in order to avoid an explosion in the number produced of design rules. To achieve the approved mandatory validity, a design rule shall specify the way to solve the problem it is intended for. Rules that can be expressed in single sentences are collected in general sections in the design rule solution part.
44. Great efforts shall be made to ensure that the design rule is maintainable. This is primarily achieved by limiting the problem area that the design rule is intended for. More complex problems or opportunities shall be supported by aggregates of rules.
1.6.2.3. Design rule model
45. The design rule product consists of:
-
The basic design rule which, as already described, is a three part rule consisting of context, problem and solution. This shall also be complemented with one or more rejected solutions, i.e. solutions which shall not be used.
-
An analysis and motivation why the solution fits the problem in the given context. This needs to be linked to direct business benefits such as cost savings or increased efficacy in operations.
-
A description of the consequences from the proposed solution which is used to create an understanding at what cost the solution comes. This could include financial impacts, but also how people, processes or technology needs to be adjusted in order to achieve the solution. When describing the consequences from a design rule solution the impact on (at least) the following areas should always be considered:
-
Security
-
Interoperability
-
Cost
-
Usability
-
Flexibility and
-
Procedures
-
-
Verification information which explains how the application of the rule can be verified.
46. A template for design rules, including guidelines, is defined in a separate document.
47. A design rule product is like Standards in the NISP related to near, mid and far term. A design rule can also exist in different versions with different status. The status of the design rule indicates which state of development the design rule is in.
-
Candidates
-
Approved
-
Disposed
48. The solution described in a design rule may refer to other design rules to form an aggregate design rule. This may be the case for instance in a design rule describing a configuration to use in a specific context or for a specific type of system. If so, the validity of the referenced design rule within the current context shall be stated.
49. Each design rule is configured in one, and only one, Design Rule Package.
50. The status of a design rule indicates in which state of development it is.
51. Validity of a design rule is only used when referring as e.g. to form aggregates. The validity labels that can be used are defined in the table below.
|
Validity |
Description |
|---|---|
|
Mandatory |
The rule shall be treated as a norm and is mandatory to use. |
|
Optional |
The rule gives good design principles and is recommended for use. |
|
Candidate |
The rule is planned for future use in this context. The design rule exist but is not appropriate to use due to reasons like cost, compatibility etc. |
52. The lifecycle for a design rule must be coordinated with profiles and standards in the manner, following the IP CaT NISP model
1.6.2.4. Packaging of Rules (Rule Package)
53. Design rules are configured in packages named DRP, Design Rule Package. A DRP may also configure other DRPs, thus creating a hierarchy of packages. A design rule or DRP belongs to one, and only one, DRP.
54. DRPs are defined so that each DRP-structure covers rules that are specific to one particular domain defined for a specific subject area of norms.
55. Dependencies between DRPs shall be defined, and the dependencies shall be minimized. Circular dependencies must not exist. The visibility of design rules configured by a DRP may in addition be limited to the DRP only; default is however that only the DRP exposes the external visibility for a design rule.
56. No design rule shall be part of more than one DRP, if necessary cross-references between DRPs according to the rules for dependencies between DRPs shall be used. Common design rules must for this reason be allocated to higher levels in a DRP hierarchy.
1.6.3. Consequences
57. If the design rule concept is going to be successfully implemented, it is important to understand how they impact the other frameworks and processes used in design. These frameworks and processes also have to be adjusted so it becomes clear as to what is documented where and when.
1.6.3.1. Standards with the use of design rules
58. Standards is often about WHAT but not always about HOW. A vast number of standards are applicable for NNEC, what are applied where, how and together with what, does not always mean that complex system will work. In order to support profiling development when using NISP, Designrules is adopted by NATO as a complementary set of tools for :
-
Helping to choose the right standard
-
How to apply the standard on a specific problem
-
Understanding the relations between different standards
-
Applicability in different domains
-
Helping with best practice and good patters in order to speed up the development of a profile.
1.6.3.2. Profiling with the use of NAF and Standards and Designrules in the NISP
59. The relations between the NISP and NAF objects in focus. The following picture shows the relations between the NISP objects Profile, Standards and Designrules. For more information about Profile guidance document.
