Why do Architects need Rules?
An architect uses rules such as business rules and IT rules. A rule is an agreement between two or more parties regarding a relationship between entities, whereby failure to comply with the agreement will invoke certain sanctions. This way, a direction is a rule without sanction, a regulation is a rule with an average sanction, and a law is a rule with a heavy sanction.
Design principles consist of rules. These rules, for instance, consist of business and design rules to make a principle implementable. For instance, take the following principle: ‘a high level of agility due to modularity’. The architect will translate this into a business rule: ‘An enterprise process may never directly utilize information resources from other business processes but must address its own resources or generic information services. ’ When making an architecture design, the architect may use the design rule: ‘Every business process maintains information resources and uses common information resources. If an architect works in this way, they will enable the enterprise to transition to another business process, which entails supporting different information systems, without adversely affecting other business processes.
Another principle is, for instance, ‘controlled facilities assure quality of operations’. In many enterprises, some departments report experiencing difficulties with standard information services or with specific information services tailored to their business functions. We often see this after a merger has taken place. A department may then decide, wittingly or unwittingly, to take a stance against information policy, work in support of an application architecture that is not permitted, and create and operate a new information system to manage the new information provision, even linking to existing enterprise-wide information services. We then see everyone using their own rules, thwarting the official principle.
An architect can now provide decision-makers in an enterprise with evidence proving that an unmanaged specific information provision negatively affects the quality of the information meant for customers and top executives. Each information system should be allowed to develop or be adapted at some point. Non-managed or illegal information systems may have inferior quality and non-standard technology, which can incur high costs when adapted. It then becomes crucial for the decision-maker to promptly place the information system in a controlled environment, based on the architect’s visualization. Thus, it will comply with the approved application architecture, clarifying which rules must be adapted.
A decomposition and a hierarchy of rules can be made in an enterprise. In reality, numerous written and unwritten rules inevitably lead to conflicts within the enterprise. The architect appreciates the challenge of creating a structure that conforms to the rules and ensures the structure incorporates rules that comply with the enterprise's regulations.
As with principles and concepts, rules can be global, detailed, specific, and generic. Rules can be integral, yet also bound to specific systems and domains.
Dragon1 recognizes, from a generic point of view, different types of rules for common architecture domains, systems, and elements. Hereby, we think of:
- Business rules which are included in product rules, process rules, organizational rules, and service rules.
- Information rules within which are included data rules, application rules, and interface rules.
- IT infrastructure rules, which include network rules, security rules, platform rules, and environmental rules.
To make rules pliable, enterprises choose open and international standards. They contain large groups of rules that clearly outline what everyone is expected to abide by. Suppose the architect is aware that the enterprise has implemented the process of “configuration management” for the technical control of its IT infrastructure. In that case, he can assume that an up-to-date configuration database is operational within the enterprise. This is a database that interrelates all the elements, components, objects, and technical products of the enterprise.
The architect will make clear from his architecture design which design rules count, which design decisions have been made, and which design criteria have been used. The architect will also clarify which business, information, and IT infrastructure rules will count in the structure.