zondag 9 april 2017 | Likes: 0 | Comments: 0

Mark Paauwe

VP Product Development

Dragon1 Inc

Views on Architecture Principles

Architecture Principles are a total disaster.

Let's face it.

They are often produced but even more not used.

The Top Architecture Principles

I have written a blog about the top 10 Architecture Principles every modern enterprise should apply today, but don't do yet.

I am asking everyone to provide me with feedback on this set of architecture principles: which ones would be on your list?

Phd/Research on Architecture Principles

I am doing Phd/Research on this subject (Prof. Erik Proper & Bas van Gils). Architecture Principles are so important for the success of any architecture project, but are currently used very badly in practice. This makes it worthwhile researching extensively how we could improve the practice on architecture principles. If you want to participate with your vision or list of architecture principles in this research, please contact me on mark.paauwe@dragon1.com.

If you have input for me with your vision on or your top 10 list of architecture principles, I am more than happy to make it part of the research. And as scientist I am maybe more interested in opposing views than people sharing my view. Only open discussions will bring us any further.

As an intermediate result of the Phd/research all literature of other fields of science seems to be hinting in the direction that principles are about the enforced way things work, producing results. Principles in their core seems describe or explain mechanisms, phenomena and concepts. Also, if you look at principles in this way (as only laws of nature) it seems to deliver much more effective principles than working with principles as guidelines, rules or legislative laws (i.e. how mainstream EA defines what principles are).

The current practice: Guidelines and Rules as Principles

We have the current practice that guidelines and rules are labeled as principle. And how hard it is or impossible it may be to scientifically prove that guidelines and rules should not be labeled as principle, I am going to see how far I can go. The people that label guidelines and rules (normative statements) as principles never have an argument why that is a principle, other than saying that it does not matter, and I should not make a big deal of it as every knows what is meant. But as researcher I day: it does matter. If a statement is a guideline or a rule, it already has a label. If giving the exact statement a new label, thus without adding anything, than what is the point of giving it another label.

I Saw the Apple Fall

About ten years ago I saw the apple fall.

When reading Dutch, German and Italian books about building architecture, landscape architecture and engineering I noticed that at the moment they talked about principles, sentences start with words like "By", "If" or "Always". And the sentences describe a mechanism: by doing this or that, this or that happens, causing this or that. For instance, with the design principles of Symmetry, Proportion and Unity: If we see symmetrical, proportioned and unified structure it gives us a good feeling. It brings us joy to look at. This is how we as humans are build and react. Taking this knowledge into account will lead or guide us to build symmetrical, proportional and unified structures.

It was then when I started creating the Dragon1 open enterprise architecture method defining enterprise architecture as a total concept for an enterprise structure. Defining architects as designers of total concepts and supervisors of the realization structures with the total concept applied. And defining architecture principles as the enforced way the concepts (part of the total concept / architecture) work and produce results. I felt that the current EA methods did not address the essence of architecture for enterprises enough.

Now it is up to me to provide enough scientific proof that architecture principles ARE mechanisms or patterns and NOT rules or guidelines. And that it is better to always formulate and visualize architecture principles as mechanisms and patterns in order for them to have more impact and be more effective.

Of course it is always a very hard thing to prove that a word like principle really means mechanism or pattern instead of rule of guideline. So one of the approaches I am taking is to compare doing architecture with 1) principles as mechanisms/patterns and 2) principles as rules/guidelines. If there is a significant improvement on effectivity or impact in the first way, then everyone can benefit from it.

Why and how this is so important me? Well looking at structures, machines and landscapes that were designed and build using architecture, I see that they are much more robust, functional and beautiful than what we now design and build as enterprise and solutions using enterprise architecture (EA). And what I see is that we treat principles in a real different way in EA. Also in building architecture they have their practice but the theory on architecture principles is not written down that specific and detailed. So that makes it all more complicated and also more challenging to find out if we are better of defining, formulating and visualizing architecture principles as the enforced way things work, as mechanisms, as patterns.

Another reasons why it is so important, is that if you communicate a normative/optional statement: do this or that in this or that circumstance, the absolute truth / mechanism / way of working gets lost. It is not communicated. Whilst that is the most important part, because this is something you often cannot make up, or rethink yourself. That is wyh it is important when talking about principles, YOU MUST communicate the mechanism first, and the derived rules from it, second!

I have already written an eBook on how to formulate and visualize Architecture Principles. I am using every result and insight from the ongoing research to improve the theory on architecture principles and update the book.

Medio 2017 the eBook will be available in English on this website.

OUTSIDE OF EA, many people see principles as fundamental laws and beliefs which must be observed when achieving the purpose. Looking at principles in this way, the principles HAVE IMPACT! And that is what we want. By relabeling guidelines and rules, it does not make these statements more effective or impactive.

The Mother Of All Principles - MOAP

Before going into theoretical definition wars, it might be smart to come up with a list of statements that most people consider to be very effective principles.

Here is a first try (beware:I am updating this list contuously based on feedback and insight):

  • Every journey begins by taking a single step. If you do not take the first step, you will never get anywhere.
  • Learning by doing: Learning from experiences resulting directly from one’s own actions leads to more permanent knowledge, as in contrast with learning from watching others perform, reading others’ instructions or descriptions, or listening to others’ instructions or lectures.
  • By automating human tasks, much more tasks can be carried out with less error at a much higher speed.
  • By analyzing data, patterns can be discovered that, once interpreted, form opportunities to improve business processes and products.

We are almost hitting ROCK BOTTOM

I have read more than 100 scientific articles that talk about Architecture Principles or touch the topic. And there is a lot of deductive reasoning going on in there using one or two authors and without hardly any evidence brought to the table. Scientifically speaking: that is one of the worst practices imaginable to build a new foundational layer upon. There are often referenced scientific articles out there with a very thin layer of solid reasoning.

An axiom or postulate is a statement that is (up until now) taken to be true, to serve as a premise or starting point for further reasoning and arguments.

Whenever Axioms are used, scientific researchers should test the axioms (using new insights). And if they stand still stand you can consider to place the axiom in your own foundation for your theory. For instance: 'You cannot be in two places at the same time'. This is an axiom that still stands. And what about: 'Global warming is caused by human industrial / fossil fuel activity' Is this an Axiom or not?. But 'the earth is flat', is an axiom that does not stand anymore. So once in a while axioms (that were absolute truths for a long time) are dismissed as absolute nonsense.

Let me repeat that sentence: Once in a while axioms are dismissed as absolute nonsense. Together with the usual blood shed. Especially when there is a world wide consensus for a dismissed axiom.

I am on the path of dismissing the following axiom: Principles are general rules and guidelines, intended to be enduring and seldom amended. Why? Well general rules are general rules and guidelines are guidelines and rules and guidelines never indicate a truth. 'intended to be enduring and seldom amended' tries to push the rules and guidelines into the shape of a truth. But that cannot be done succesfully. Rules and guidelines are a contextual agreements. Rules and guidelines contain values and norms. Truths don't.

A truth is: the sun comes up every day (the next millions of years). A guideline is: don't stay out in the sun too long because you might get a sunburn. A rule is: you will get a fine for driving too fast.

I am asking myself: Who has ever proven that this axiom was true? I am thinking that spoken language accidently was turned into a definition for the term principle. How unwise.

In dictionaries we encounter definitions like: 'A principle is a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning' or 'A principle is a general scientific theorem or law'. On the one hand this all points to mechanisms, because a law or truth always is or works the same every day. On the other hand this all points to things that should not be questioned. But hey! If a truth or theorem is dodgy, it should be put under pressure and discussed and questioned.

By observing an apple fall, Newton could formulate the gravity principle (how gravity works).

After experimenting with moving objects, Galileo could formulate the new heliocentric cosmology principle (how planets orbit a sun in a solar system).

Einstein could formulate the relativity (mass-energy equivalence) principle by means of mathematics: Anything having mass has an equivalent amount of energy, as a consequence of the symmetries of space and time.

Scientists use observation, experiments and mathematics to formulate principles. The question is: can you create and formulate a correct principle without using one of these three tools?

Misconceptions of Enterprise Architecture

The word Architecture in Enterprise Architecture was adopted from the term Information Architecture, introduced by Raul Wurman in 1997. This term adopted the word architecture from building architecture.

Building architecture is a design science. Architects are designers of total concepts (architectures) and supervisors of the realization of structures and solution with the concepts applied.

Architects make things. Building architects make and change buildings, Enterprise architects make and change enterprises.

Now strangely enough most enterprise architects do not consider themselves as designers. Most architects consider their profession to be about planning and advise. This I think is a misconception. This attitude towards architecture, not seeing it as a design science, also has it impact on looking at and working with principles. The architects feel it is their job to inspire, motivate and guide people to make decisions, create designs, supervise solution building and changing system structures. Themselves they don't make decisions, create designs, etc.. whilst in fact this is what they should do. But now, in the end, no one is doing it.

Different Views on Architecture Principles

Below are the unedited comments I received upon posting this blog in various discussion forums.

Gerben Wierda - You are right that they are a disaster. You seem to think the idea can be fixed. I disagree. http://www.infoworld.com/article/2988671/enterprise-architecture/architecture-principles-considered-harmful.html

Erwin Derksen - I think one of the core principles should be 'Simplicity' (by means of reducing complexity where possible). People tend to make things (and especially IT) complicated and overstructured. By applying simplicity in the vision / architecture i often managed to avoid unnessacary complexity, which greatly enhances the reliability and flexibility of your environment. By reducing complexity, people have a more clear understanding of how thinks work and why they are designed the way they are. This enhances the adoption and usage en reduces the amount of questions and complaints.. So, the most important prnciple for me: Simplicity! (This also applies to f.e. project management and security in my experience...)

Serge Bouwens - I think architecture principles should not be treated the way they traditionally are. But how to treat them depends on the maturity of the organization. In short there are two sides of the spectrum:
1. “A principle must give clear and unambiguous direction”. This perspective emphasizes the limits set by policies, is directive and prevents discussion. This approach works best in immature organizations and is the traditional way one can find in TOGAF and most literature. It works like Mark stated in many cases.
2. “A principle must give guidance in decision making, without trying to pre-determine the outcome”. This perspective emphasizes the space within the limits set, and prevents escalations. This approach works best when architecture practice is working ok.
The architect must understand this and find the shade of gray that works in his context.

Paul Oude Luttighuis - The bad press that architecture principles get is hardly their fault, but rather of the architects that use (or frame) them in too restricted ways. Somehow, architecture practice doesn't seem to get out of the ever-swinging pendulum between killing top-down control and chaotic laissez-faire. The harder you push or pull to one end, the harder it will swing back to the other, one day. To that end, architecture doesn't differ much from management and policy.
My suggestion: let's start using architecture principles (and models) as communicative and creative expressions, that do their specific and temporary work in specific situations to the specific good of the specific organization. Because in the end, the principle doesn't do the job, just like the method doesn't.
It is the architect who is responsible for this discourse. He/she can never leave that responsibility to any principle, or model.

Raj Bhino Rajamani - I feel Business Continuity is one principle all modern enterprise should have and will be applied in all their systems and operations.

Geoff Young - Architecture principles without governance is not EA.

Peter Murray - Architecture principles are effective when they are applied to the design methodology. They are therefore applicable to key design components of the solution. APs serve as a reference point. They can however be over applied and will in these instances confuse the end result.

Peter Rawsthorne - 1) culturally and contextually aligned 2) lightweight to fit with 1.

Lal Dissa - Is it the architecture principles that are a disaster, or the fact that they not appropriately used?

Jagannath Shanmuga Sundaram - AP is part of EA process and realized at design , pattern and strategy level... It should be applied with care and limited w.r.t business model /requirements otherwise it might be in governance process but not at implementation ...

Rogerio Carneiro, TOGAF ® 9 Certified - I wrote a small article about EA principles. I agree with the idea that we have to enforce it using mechanisms, metodology and processes. If you can, please read my article at my profile.

Greg Horsman - I governance approach I've used in the past is to complete an Architecture Principle Alignment scoring when solution architectures and solution options are being reviewed... essentially a rating of unfavorable, neutral or favorable against each principle. There is always tension between principles and the objective is to make visible which principles are being supported or traded off for a particular solution ... no solution is a perfect fit against the principles.

Serge Thorn - The problem is much bigger than Architecture Principles. If they are not used, probably EA is not understood or not communicated as it should be. Or probably not sponsored or endorsed by senior people in your organization. You can have the best principles in the world, if nobody understand the value...then for sure nobody will respect them. At the end the issue is top-down, related to a value proposition to key stakeholders. Governance, Principles and more are normally accepted if you do some "homework" before. Another aspect which brings complexity is this digital world where everything should go fast. Companies are now using Agile and DevOps, and may "skip" EA for wrong reasons... I have seen that recently happening. People "writing EA frameworks" may not have seen that...because often too much academic..

Akshyadeep Raghav - They are very valuable, add support to policies, governance and managing technical debt. Calling them disaster seems either improper use of them without understanding or need proper understanding and purpose of them . Also greatly helps in building consensus at large federated organisation.

Willem Oorschot - One of the issues with principles: the donn't last forever and have to evolve over time. A principle for today could be obsolete the next.

Edward Galiaskarov - Hello Mark. Could you inform the URL of your blog or the post where you wrote about principles?

Sreedhar Padakanti - Hi Mark, Architecture principles are needed and it will help a lot in identifying the top 10. As you said they are ignored and not properly implemented. Hence I feel along with top 10 principles it will help a lot if we can have some governance around those for proper and right implementation.

Michel BÉNARD - Well in a way, it is reassuring to know that ignoring architecture principles is commonplace ;-) looking forward to reading your post. by the way, we have defined 10 architecture principles at my workplace.

John Scott - Do other industries with 'architecture' type roles/activities have "architecture principals"? Looking towards 'a timeless way of building' aren't any principals embodied in patterns? If principals are so often written, but seldom read are they of real value?

Lars Feldmann - Hi Mark, apart from the art of defining the right principles I found that the even more important capability an organisation needs to build up is the capability to govern those principles. There's never a shortcoming of finding the right principles but if they're not adhered to during project implementation phases they're worth nothing.

Robert Deckers - I do not think something is wrong with the concept of using principles as mechanism to direct change. But, I observe that today's practice of using guidelines, principles or whatever would like to call them, has (a.o.) the following issues:
1. they lack in engineering quality: they are not precise, often inconsistent, and not checkable.
2. Their application is not reasoned and not clear. The way to apply them in the system
(=enterprise/process/business/infrastructure/applications/...) is not clear for the appliers.
3. They lack in definition w.r.t. the relation to other concepts. E.g., it is not clear where architecture stops and design begins or where business goals stop and architecture begins, or what is essential and what is temporary implementation choice.
The solution is to stop the contextless blabbing about principles and only consider an integral approach (in which principles can be beneficial concept).

Ed Roberts - A couple of thoughts... 1. Yes other industries do have Principles.... I refer you to Permaculture Farming... https://permacultureprinciples.com/principles/
2. I think Principles may have some of its best benefits in spending the time developing them... as people will have to describe what is important and what they are going to be making decisions on

Adrian Grigoriu - As anything, if properly specified and used they are good. If not, they are detrimental. This stands too for EA frameworks. See following posts http://it.toolbox.com/blogs/ea-matters/architecture-principles-are-they-any-good-76184 and http://it.toolbox.com/blogs/ea-matters/architecture-principles-are-they-any-good-i-76185

Voytek Janisz - I agree with Adrian. They are only disaster if they are not tied to anything else. In my environment, EA Principles have become the foundation for architecture governance and strategy definitions. We were relentless in making sure that the principles were properly socialized and more importantly properly interpreted. Another way of looking at it is that EA Principles are a disaster only if you don't know how and when you are going to apply them.

Adrian Rossi, Ph.D. - As with most things in life they are not intrinsically bad or good. Architecture principles are extremely effective when they are SMART which they should be and enforced. I have used them within our team at ESDC and enforced them every day. Now if you just write them down and then ignore them then they are useless. But this doesnt make them bad...it just means you have not leveraged them well.

Nick Malik - Principles are a response to fear of losing control. If you allow an architect to add requirements to a system, you are giving control to Architects. Who loses? The business stakeholders do because budgets don't increase when requirements are added. Therefore principles were invented as a compromise. Architects can declare principles in advance and planners can plan systems on the basis of the principles before funding. That allows both architects and business stakeholders to both get what they want. Also the planners are accountable to business stakeholders while architects are not, so power is maintained.

Chris Kempster - Yes and no; a question of EA and planning maturity. Principles need to apply to yourself as designers, if you cannot even do this, then get stop everything your doing and sort it.

Paolo Zotti - Principles are useless only when architects are not open to listening to the explanations of why one wants to deviate...

Mohan K. - @Mark Architecture Principles may be a "total disaster" ... when the architecture governance (ARB ?) and the planning processes are a "total disaster"
A right-sized, well functioning Architecture governance will need referable inputs including Principles.

Alex Kuryliak, FCIP, CRM - Properly written, adhered to, measured and acted upon, principles are great tool for guiding an enterprise. If they are put out and given lip service, then they are pretty useless.

Ivo Velitchkov - I think EA principles can be useful ONLY of they are descriptive and not prescriptive. Creating prescriptive principles – the most common case – leads to a worse situation than having no principles at all. Prescriptive principles require to comply or explain non-compliance. If a solution architecture complies with a principle, then it is accepted as good. If it doesn't comply, then a good justification would show that in certain cases a better architecture would be achieved by not complying with one or more principles. It turns out that prescriptive principles, which by nature appears stricter, allow both compliance and non-compliance to be accepted.
When the EA principles are descriptive, they can help in showing when a particular architecture would not support the vision, but they would not stop a solution to demonstrate support to the vision, when it does it in a way not described by the principles.

Truly descriptive principles should actually be means for description.

Pankaj Gupta - It's part of organisation life cycle IMHO. The principles are forced upon during a phase and then it takes shape of auto pilot. However it's gets disrupted again especially if there is a significant change of leadership in the organisation. Overall the adoption of these principles takes the shape of a typical Sine Wave

Samuel Holcman - Mark: We humbly suggest that architecture principles are no more than platitudes. We have abandoned them years ago, because, as you state, they are a total disaster. We use SMART Goals (strategic, measurable, actionable/assignable, results oriented, time-bound), which guide actions that these platitudes were intended to address. And, there is no one "set" of these. Respectfully, Sam Holcman

Cees Booister - Hi Mark, have you looked at http://www.referentiearchitectuur.nl/index.php/ArchiXL_referentie-architectuur ? Like

Hans Bot - Ook voor architectuurprincipes geldt het credo "less is more". Maar is is naar mijn smaak wel een optimum. En, voor de duidelijkheid, dat ligt boven nul. Iedereen die niet "gelooft" in de waarde van principes nodig ik graag uit om eens te kijken naar de verschillen tussen AWS en Azure. Een goed-geoliede machine versus een doos vol gereedschap. Of WSO2 t.o.v. Websphere. Een rijk platform opgebouwd uit complementaire features versus een vergaarbak aan tools en technologieën. Of Tesla versus Honda. Impliciet of expliciet, principes maken het werk van de individuele architect schaalbaar naar een groter geheel.

Vishi Singh - The effective way we implemented is via implementing on the lowest entity like the people who are at the bottom of the tree... they actually make use of it .:. They are eager to learn and very quick to change

Riaan Roos - Hello, I would recommend the following books on the subject. Enterprise Architecture (2009) by Op't land and Proper, and Architecture principles: the cornerstones of enterprise architecture by Greefhorst and Proper. But I guess you already knew that. ;)

Matt Comb - I think the mistake often made with principles is the attempt to change a large number of principles overnight which is difficult to enforce or establish a culture around. I believe principles should be added or changed one at a time and monitored closely for a short period before moving onto the next change, that way they have a chance to bed in.

Joshua Tedam MBA - I find a lot of resistance to the application of architectural principles. I think socialisation is the appropriate term but like regulation and compliance, they has to be sponsorship from the top. They deliver no functional requirements and as such can be perceived as trying to take control or control the way and manner things are done. In some cases, architectural principles can mean significant change. This can get in the way of old habits, good or bad.

Also, where spend and projects are justified via business cases, having principles that merely enforce best practice without helping to tick off a benefit in the business case can be a hard sell. Lastly, architectural principles must deliver dependable benefits to be taking seriously. If architectural principles do not affect business as usual in any significant way, you will merely be trying to fix a thing that is not broken. What does the organisation stand to lose, rather gain, without the architectural principles? If you, as the author, can't find an answer how do you expect others to? Your architectural principle will gather dust if they deliver no significant contribution to the business Case; and the strategy and vision for that matter.

Murilo Gimenes Rodrigues - Disaster happens when Architecture Principles are built by Architects for the Architects. If you have Architecture Principles that are truly there to guide your teams, then it won't be a disaster and they will become organic in the decision making processes.

Torsten Mahr - Architecture Principles should be agreed by the team (including business and IT) they should give them guidance where it is hard to make the right decision. If principle made to set a framework of rules they will fail. architecture principles are not equal to architecture rules. No one could be compliant to principles, no one can measure principles ... that is why they are often misunderstood in enterprises.

Soumen Paul - EA is a top-down approach. If principles are not being used, then there could be fundamental problems e.g such organisations may not have understood EA value-add or appropriate usage/benefits of EA. Another comment would be - today's world of cloud based architecture brings additional challenges to traditional ADM, as most organisations now rely on agile sprints. Therefore to apply EA practically, we need to consider how we define our iterations and transitional states (building blocks) so that it can fit inside agile sprints. Theoretical principles need to be changed appropriately, and applied practically to cater today's fast moving businesses, and it's enabler as IT.

Richard Haklander - I experienced that there is more commitment on principles with DON'Ts then with DO’s. Why? I don’t know, but I guess it’s just a culture or mind thing. It looks like that forbidden things are better adopted that the recommended ones you should do. Another suggestion is ‘Security’. It’s is a broad topic, a lot of things is going on now and it has the attention from the board and management.

Somnath Ghosh - let me email you . appreciate for such initiative

Graham Berrisford - Architecture principles are useful as a tool for experienced professional architects to use when and where they see fit. The trouble is the more common practices of
-a- generating principles by copy and paste, and then either
-b- ignoring them or
-c- applying them mindlessly, without attention to the trade offs.

Ibrahim Soliman If you didn't,review EA sample principles mentioned in TOGAF 9.1 specifications. I guess few of them can fit within your top 10 as foundation principles. However, knowing "how to apply the principles within the organization" is important as defining principles.

Kumar Mayank Jaiswal looking forward for your blog..

Rohan Philip Buultjens - @Mark, in total agreement with you. Most organisation ignore the need for principles and end up with considerable technology debt, project failure etc, and very soon digital waste. My take on principles is that it should be a short set of guidelines designed to ensure decisions and behaviours that are aligned with the chosen (eg. strategic) direction.

Sean Chamberlin - Mark, totally agree that architectural principles are rarely done well and often not followed. They should be a key tool for guiding organisations to their target future states or Vision. looking forward to your article.

Chris Wilson - Mark - I think there are actually 2 types of principles - there are the principles which are applied to shape and formulate the architecture; and there are the principles which drive the standards to implement the architecture. Interesting to see what your blog will say....

Chris Wilson - Making a BIG assumption on the use of the word EXPERT for me! I'll look forward, as always, to your post!

Rich Anderson - IMHO, principles are useful, but very often architects obsess over them too much. My cynical side tells me that this is because setting principles is usually easier than solving hard problems.

Gjermund Lunder - interesting! what is the most relevant to guide us when evolving our business?

Anna Aaltonen - Good question! I think one root cause is in TOGAF, the examples there are not that useful and everyone copies from there. I think principles should be more concrete and easy to verify that they are now (like "simplicity", who will ever admit they aim for "complexity". Not practical at all in every day use). Also the amount should be flexible, so that you take only most necessary ones you check, because after 10, people just get tired.

Anna Aaltonen - And I think target architecture (very seldom used) is a lot more effective than principles. That clearly sets direction and we can verify whether certain project goes to that direction or not. Many organizations think that principles would solve pretty much everything.

Luc Dobler - Architecture principles might be useful to get a sense of how new projects can integrate into a vision. Our principles are largely inspired by TOGAF's and by the document "Cadre commun d'urbanisation du SI de l'Etat" published by the DISIC (république française). Any new project request is assessed against our Governance principles in order to get a first kind of "compliance" score which indicates if the request goes in the same direction than the principles. The goal is then to follow-up the go no-go decision that are made on the project to see how principles and projects are aligned. The score is however only informative though : bad score is not blocking.

Michael Herman (Toronto) - A key step in enabling Iteration 3 is having the latest version of the relationship matrix fully implemented in an EA tool. #WaitingPatiently :-)

Jon McLeod - Principles are too often nothing more than mere statements of hoped-for aspirational behaviour. Principles must be derived from the enterprise business strategy. "If we want to achieve specific future outcome, we must force ourselves to behave differently. This principle will force us to behave differently." How a principle directly enables a strategic goal, outcome or metric is almost never explained in practice. If organisations create custom-defined principles while looking at all aspects of the enterprise business strategy, their principles would be effective.
Also - principles must be used in governance decisions. If principles are not regularly used to arbitrate difficult governance decisions, and are not being used to drive and mandate appropriate governance decisions, they are irrelevant.

Jon McLeod - I have seen principles created and communicated only within the internal community. They are not even publicly endorsed by the Head of Architecture and Strategy or CIO. Of course, they *should* be publicly endorsed by the CEO and Board of Directors. When no one outside of IT has ever seen the principles, you know it's been a waste of time.

Jon McLeod - Another MAJOR stumbling block for principles and governance is the prevalent model for "IT Service Management". IT service providers will say to customers "All you - as our customer - care about is the service. Everything behind the service is up to us to manage as we see fit. So any principles you may promulgate clearly do not apply to us." When this happens, you know you've lost control of your enterprise architecture. When you've lost governance control of your architecture, you've lost control of your strategy.

Nahum Rosinsky - I believe the main issue you are confronting on writing your blog is the fact there is no clear agreement on what a principle should look like. In some organizations principles are the least moving parts of the architecture very tied with the business strategy while in some other cases principles are understood like high level ADRs. On my opinion in the 'modern enterprise' in which the business strategy is an much more dynamic function the architecture hence the principles should be evolutionary by default, meaning the first principle should be every question every principle in favor of the business.

Wim Van Hooste - Hi. Some companies do an internal project IT "certification" where the technical "lead" has to provide "evidence/artifacts" showing the application of those principles in thier solution design. I am sure there are better ways to streamline and measure this then what i have experienced, but it is something to think about if you have not considered anything along these lines