Architecture principles formalized
In a previous post (Architecture, a definition) the key terms in the system realization process were clearly defined. We've seen that an Architecture is a set P of design principles, conforming to some Architecture Framework. Every p Î P
– concerns one system type s Î S.
– is a restriction of design freedom in one domain d Î D.
– accommodates one or more areas a Î A.
An Architecture Framework is defined as a tuple where:
– S is a set of system types.
– D is a set of design domains.
– A is a set of areas of concern.
So, an architecture framework defines categories in which principles should be defined. Each category is a tuple with s Î S, d Î D and a Î A. For each category a set of principles can be devised. The resulting set of principles is called an architecture. Now a couple of important issues arise including the following questions:
– What exactly are principles?
– How to define principles in a formal, unambiguous way?
In this article both questions will be answered.
Architecture principle, a definition
From the definition of architecture and the position of architecture in the system realization process (see Architecture, a definition) it follows that a principle is a general rule or guideline for designing a system. More formal a principle is a restriction of design freedom in a certain design domain and can be categorized in a category . According to [2] both IEEE [3] and TOGAF [1] position principles as a means to guide the design and evolution of systems.
Principles can be distinguished in three main classes [2]:
Principles as inherent laws, these are essentially properties of (classes of) a system that are inherent to a system and can as such be observed and validated.
Examples are the laws of nature, laws of social behavior, etc.
Principles as imposed laws, like inherent laws, they are properties that can be validated. However, imposed laws also require mechanisms to enforce them. Imposed laws typically address concerns of stakeholders. Some of these concerns may be raised by inherent laws which may have a negative/undesirable effect with regard to the system being designed.
Examples are: societal laws, policies and regulations within organizations, etc.
Principles as guidelines, desired properties that are so concrete that they offer guidelines to make operational behavior fit imposed laws.
For example: use your car's cruise control is an advisable property to abide by that provides guidance in obeying the law concerning maximum speeds on roads.
The first class of principles can only be observed and validated. When architecting an architecture, principles in the last two classes will be formulated. Laws, policies and regulations applying to the subject system have to be indicated and principles enforcing them must be formulated. These principles are of the class ‘Principles as imposed laws'. In the class ‘Principles as guidelines' all relevant issues concerning the object system have to be formulated by involving the stakeholders. Principles can be found either by interviewing the stakeholders or by let them formulate the principles themselves in a group discussion. The last method is preferred but has to be guided, for example by using a Group Decision Support Systems (GDSS).
A format for defining architecture principles
Its useful to have a standard way of defining principles. In that way the defined principles are more understandable, can be checked for completeness and are easy to compare. Comparability of principles is important for creating a consistent set of principles (a consistent architecture). The Open Group [1] defines a very useful format for defining principles. This format is shown in Table 1. Besides the name and the fundamental rule of a principle, it describes the business benefits and the consequences of adopting a certain principle.
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. |
Table 1 – Recommended Format for Defining principles [1]
The two example principles shown in Table 2 and Table 3 give a good idea how this format can be used for a clear definition of principles.
Name | Business Continuity |
Statement | Enterprise operations are maintained in spite of system interruptions |
Rationale | As system operations become more pervasive, we become more dependent on them; therefore, we must consider the reliability of such systems throughout their design and use. Business premises throughout the enterprise must be provided with the capability to continue their business functions regardless of external events. Hardware failure, natural disasters, and data corruption should not be allowed to disrupt or stop enterprise activities. The enterprise business functions must be capable of operating on alternative information delivery mechanisms. |
Implications | Dependency on shared system applications mandates that the risks of business interruption must be established in advance and managed. Management includes but is not limited to periodic reviews, testing for vulnerability and exposure, or designing mission-critical services to assure business function continuity through redundant or alternative capabilities. Recoverability, redundancy, and maintainability should be addressed at the time of design. Applications must be assessed for criticality and impact on the enterprise mission, in order to determine what level of continuity is required and what corresponding recovery plan is necessary. |
Table 2 – Example (enterprise) architecture principle 1 [1]
Name | Requirements-Based Change |
Statement | Only in response to business needs are changes to applications and technology made. |
Rationale | This principle will foster an atmosphere where the information environment changes in response to the needs of the business, rather than having the business change in response to IT changes. This is to ensure that the purpose of the information support – the transaction of business – is the basis for any proposed change. Unintended effects on business due to IT changes will be minimized. A change in technology may provide an opportunity to improve the business process and, hence, change business needs. |
Implications | Changes in implementation will follow full examination of the proposed changes using the enterprise architecture. We don't fund a technical improvement or system development unless a documented business need exists. Change management processes conforming to this principle will be developed and implemented. This principle may bump up against the responsive change principle. We must ensure the requirements documentation process does not hinder responsive change to meet legitimate business needs. The purpose of this principle is to keep us focused on business, not technology needs – responsive change is also a business need. |
Table 3 – Example (enterprise) architecture principle 2 [1]
Formalizing architecture principles
The definition of a principle states that a principle should be a restriction of design freedom in a certain design domain. The given format in Table 1, however, does not provide enough precision to concretely limit design space. Therefore, principles defined in that format have limited power as a steering instrument [4]. Principles stated in human language could be ambiguous and therefore always a subject of discussion. So it is very useful to search for a more formal way of defining architecture principles. If principles can be formalized it is easier to check whether a certain design complies with the architecture or not. Formalized principles could even trigger research in trying to automate some parts of the design process (compliancy checks, etc.).
Principles can be formalized using a combination of Object Role Modeling (ORM) [6] and Object Role Calculus (ORC). ORM is a very powerful approach because it is both formal and easy to understand. It uses intuitive diagrams and natural language. Van Bommel, Hoppenbrouwers, Proper, and Van der Weide [4] conclude: "We found not only that such analysis is quite possible, but more importantly that it can lead to better understanding of and even improvement of the principles as such, so apart from their formalization. Using ORM and ORC for principle analysis helps give clear and unambiguous meaning to those principles.".
With the idea of using ORM for formulating principles, the items, derived from [5], shown in Table 4 can be added to the format for defining principles.
Assumptions | The assumptions made while interpreting the statement and rationale will be included in an ordered numerical list for easy (cross) reference. This is the rationale of those who give meaning to the architecture by interpreting it and extracting the meaning from the information. |
ORM Schema | The graphical ORM schema. |
Verbalization | The relevant verbalization of the fact types and entity types. This shows in a semi-formalized natural language what the structure of the schema is meant to represent by means of NORMA generated sentences. |
Issues | Issues that need to be solved in making the formalization of the principle specific enough to make it imposable. |
Table 4 – Template for formalizing (enterprise) architecture principles [5]
The example principle ‘Business Continuity' given in Table 2 is formalized in Table 5.
Assumptions | A1: Business Functions need Information, and implicitly their delivery. A2: System interoperations are mechanisms for Information Delivery. A3: The Business functions should be dependent on other delivery mechanisms then system operations. A4: An event is something that causes an interruption like a natural disaster or bug. |
ORM Schema | |
Verbalization | Enterprise has Business Function. Each Enterprise has some Business Function. For each Business Function, exactly one Enterprise has that Business Function. It is possible that the same Enterprise has more than one Business Function. Enterprise has IT Operation. Each Enterprise has some IT Operation. For each IT Operation, exactly one Enterprise has that IT Operation. It is possible that the same Enterprise has more than one IT Operation. Business Function is dependent on Information Delivery. It is possible that more than one Business Function is dependent on the same Information Delivery and that the same Business Function is dependent on more than one Information Delivery. Each Business Function, Information Delivery combination occurs at most once in the population of Business Function is dependent on Information Delivery. Each Business Function is dependent on some Information Delivery. For each Information Delivery, some Business Function is dependent on that Information Delivery. Information Delivery facilitated by IT Operation. It is possible that the same Information Delivery facilitated by more than one IT Operation and that more than one Information Delivery facilitated by the same IT Operation. Each Information Delivery, IT Operation combination occurs at most once in the population of Information Delivery facilitated by IT Operation. Information Delivery is independent of Interruption. It is possible that the same Information Delivery is independent of more than one Interruption and that more than one Information Delivery is independent of the same Interruption. Each Interruption, Information Delivery combination occurs at most once in the population of Information Delivery is independent of Interruption. Each Information Delivery is independent of some Interruption. IT Operation is interrupted by Event. It is possible that more than one IT Operation is interrupted by the same Event and that more than one Event interrupts the same IT Operation. Each Event, IT Operation combination occurs at most once in the population of IT Operationis interrupted by Event. Each IT Operation is interrupted by some Event.Each Event interrupts some IT Operation. |
Issues | How to determine if an event is an interruption? |
Table 4 – Template for formalizing (enterprise) architecture principles [5]
The example principle ‘Requirements-Based Change' given in Table 3 is formalized in Table 6.
Assumptions | A1: A change is an actual existence and therefore always affects technology and IT application. A2: IT Application & Technology should not be interpreted as singleton. A3: A change is about an IT change. |
ORM Schema | |
Verbalization | Enterprise uses Technology. It is possible that more than one Enterprise uses the same Technology and that more than one Technology is used by the same Enterprise. Each Enterprise, Technology combination occurs at most once in the population of Enterprise uses Technology. Each Enterprise uses some Technology. Enterprise has Business Need. Each Enterprise has some Business Need. For each Business Need, exactly one Enterprise has that Business Need. It is possible that the same Enterprise has more than one Business Need. Enterprise uses IT Application. It is possible that more than one Enterprise uses the same IT Application and that more than one IT Application is used by the same Enterprise. Each Enterprise, IT Application combination occurs at most once in the population of Enterprise uses IT Application. Each Enterprise uses some IT Application. Business Need determines ChangeTechnology. For each ChangeTechnology, exactly one Business Need determines that ChangeTechnology. It is possible that the same Business Need determines more than one ChangeTechnology. Business Need determines ChangeITApplication. For each ChangeITApplication, exactly one Business Need determines that ChangeITApplication. It is possible that the same Business Need determines more than one ChangeITApplication. Business Need causes Change. For each Change, exactly one Business Need causes that Change. It is possible that the same Business Need causes more than one Change. Change affects Technology.For each Technology, at most one Change affects that Technology. Each Change affects some Technology. It is possible that the same Change affects more than one Technology. Change affects IT Application. For each IT Application, at most one Change affects that IT Application. Each Change affects some IT Application.It is possible that the same Change affects more than one IT Application. |
Issues | How to determine/predict the impact of changes? |
Table 6 – Example (enterprise) architecture principle 2 formalized [5]
Conclusion
A principle is a general rule or guideline for designing a system. The format for describing a principle given by The Open Group describes, besides the name and the fundamental rule of a principle, the business benefits and the consequences of adopting a certain principle. But for using a principle as a restriction of design freedom a more formal notation is needed. This formalization can be done with use of ORM.
By looking at the example principles it can be concluded that by using the extended format the principles are made more explicit. Both the assumptions and the statement of the principles are explicitly stated, making the principle unambiguous. However, unless it is easy to read, ORM is not the most easy notation to formulate a principle in.
References
[1] The Open Group Architecture Framework (TOGAF), version 8.1.1. Enterprise Edition, 2007. http://www.opengroup.org/
[2] Architecture Principles, werkgroep Nederlands Architectuur Forum voor de digitale wereld, 2007. https://lab.cs.ru.nl/ArchitectureInstitute/Principles_Arena
[3] Recommended Practice for Architectural Description of Software Intensive Systems. Technical report: IEEE P1471-2000, September, The Architecture Working Group of the Software Engineering Committee, Standards Department, IEEE, Piscataway, New Jersey, USA, 2000, ISBN 0738125180
[4] P. van Bommel, S.J.B.A. Hoppenbrouwers, H.A. (Erik) Proper, and Th.P. van der Weide. Giving meaning to enterprise architectures – architecture principles with ORM and ORC. In R. Meersman, Z. Tari, and P. Herrero, editors, On the Move to Meaningful Internet Systems 2006: OTM Workshops – OTM Confederated International Workshops and Posters, AWeSOMe, CAMS, GADA, MIOS+INTEROP, ORM, PhDS, SeBGIS, SWWS, and WOSE 2006, Lecture Notes in Computer Science, Montpellier, France, EU, October/November 2006. Springer, Berlin, Germany, EU.
[5] G.J.N.M. Chorus , Y.H.C. Janse, C.J.P. Nellen, S.J.B.A Hoppenbrouwers and H.A. Proper, Formalizing Architecture Principles using Object-Role Modelling,
[6] Object Role Modeling, the official site for conceptual data modelling. http://www.orm.net/
2 Comments Added
Join DiscussionI’ve read some of your other blogs regarding MDA and your work at Mendix. This post on formalizing Architectures through ORM leaves me a bit confused on just exactly where you stand.
From my not so expert perspective the semantics of ORM or another formal logic based language could be sufficient to create a declarative model which could be executed in a logic based environment (provided the model is computable, satisfiable and decidable).
Do you agree, disagree or lie somewhere in between with this statement?
Hi Manny,
I’m sorry for my late reaction. See my latest post for my view on the place of architecture in model driven engineering: http://www.theenterprisearchitect.eu/archive/2008/11/27/the-place-of-architecture-in-model-driven-engineering
As you see architecture is on another level as MDE. Using ORM to formalize principles helps to use these principles as a steering instrument. Combined with MDE it is even possible to automatically check the models against some of the principles (this is not possible for every principle, because a lot of them are quite high level).
However, the intention of this article is not to focus on automation, but more on stating principles in a formal, unambigious way.
I don’t think direct execution of principles is useful, because they are modelled from a user / problem perspective, not a system / solution perspective. Besides that, they are formulated for using them as guidelines for the design of a system, not to actually design the system itself.