Normative Restriction of Design Freedom

I've been working on creating an environment to document an architecture. The customer I'm working on at the moment, has a lot of documentation, but it's all spread over powerpoint presentations, word documents, enterprise architect models, archimate models, visio diagrams, excel spreadsheets and wiki pages. You can imagine it's a tough job to find all the information you need to make choices. So, I have suggested to rationalize all these documents into a Wiki, which will then be the 'Single Point of Truth' concerning the company's architecture.

That's easier said then done. The most important question here is what to document. Document too much and you'll never get anything done, document not enough and people will not know what to do or how to do it. I looked at all (well, not all, but a lot) the architecture metamodels around to see which one of them would give me the structure I needed. Unfortunately, most architectural models ignore concepts like business goals, principles and construction regulations. To me that's quite strange, as I find that these are essential parts of any architecture.

About two weeks ago a NAF workgroup (Dutch Architecture Forum) presented its results. A book on Architecture Principles. In a very lively presentation the authors Danny Greefhorst (ArchiXL) and Erik Proper (Tudor) presented their book, accompanied by two organizations who participated in the research. I'm not going to discuss the book here, as I'm still in the process of reading it, but it did trigger me to re-think the work I had done for documenting architectures.

One of the essential conclusions of the book (and hence the presentation) is, and I quote:

The meaning of enterprise architecture is that it provides a normative restriction of design freedom toward transformation projects and programs

This is a very interesting concept. The more I thought about it, the more I think it is a concept that I could use in my quest for the optimum architecture documentation metamodel.

Luckily I was able to discuss both my quest as well as the book during an IT-eye Open Space. After more than hour of (sometimes) heated discussion we came up with the model you see here on the right hand side. In that model you will find the 3 basic artifacts I think every architecture needs:
1. Business Goals - what needs to be achieved in the next 5 years
2. Principles - what are the (business, information, technical, etc) principles that guide any change within the organization?
3. Construction regulations - what do we have to comply with when constructing artifacts (like processes, datastructures, business units, software,etc).

I have added the 'Generic Components' as well, as every organization has reusable artifacts (reuse is not limited to software!). The fun part of this model is, that you can look upon each and every relationship that's drawn in it as being of the type 'Normative Restriction of Design Freedom'. Business Goals, usually the highest level, is (often severely) restricted by the existing environment. Change comes harder if you have to replace existing constructs. Business Goals themselves restrict Principles. It won't do to have principles that go outside the set goals.

So now I have a potential metamodel which I'm already applying at my customer. It will probably need some more finetuning, especially taking in account specific characteristics of Wiki functionality.