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 architectural 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 important for the success of any architecture project but are currently used very badly in practice. This makes it worthwhile to extensively research how we could improve the practice of architecture principles. If you want to participate with your vision or list of architecture principles in this research, please get in touch with me at mark.paauwe@dragon1.com.

If you have input for me with your vision or your top 10 list of architecture principles, I am more than happy to make it part of the research. As a scientist, I may be 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 seem to 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 of labeling guidelines and rules as a principle. And how hard it is or impossible it may be to scientifically prove that guidelines and rules should not be labeled as a principle, I will see how far I can go. The people who label guidelines and rules (normative statements) as principles never argue about why that is a principle, other than saying that it does not matter and that I should not make a big deal of it, as everyone knows what is meant. But as a researcher, I say it does matter. A statement already has a label if it is a guideline or rule. If giving the exact statement a new label, thus without adding anything, then 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 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 a 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 built and react. This knowledge will lead or guide us to build symmetrical, proportional, and unified structures.

I then 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 sufficiently address the essence of architecture for enterprises.

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

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

Why and how this is so important to me? Well, looking at structures, machines, and landscapes that were designed and built 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 differently 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 at defining, formulating, and visualizing architecture principles as the enforced way things work, as mechanisms, as patterns.

Another reason 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. That is the most important part because this is something you often cannot make up or rethink yourself. That is why it is important when talking about principles: YOU MUST communicate the mechanism first and the derived rules from it second!

I have already written a book 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.

OUTSIDE OF EA, many people see principles as fundamental laws and beliefs that 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 impactful.

The Mother Of All Principles - MOAP

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

Here is the first try (beware: I am updating this list continuously 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 actions leads to more permanent knowledge, unlike learning from watching others perform, reading others’ instructions or descriptions, or listening to others’ instructions or lectures.
• By automating human tasks, many more tasks can be carried out with less error and much faster.
• By analyzing data, patterns can be discovered that form opportunities to improve business processes and products once interpreted.

We are almost hitting ROCK BOTTOM

I have read more than 100 scientific articles discussing Architecture Principles or touching on the topic. There is a lot of deductive reasoning going on using one or two authors, and hardly any evidence is brought to the table. Scientifically speaking, that is one of the worst practices imaginable for building a new foundational layer. 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). If they stand still, you can consider placing the axiom in the foundation of your theory. For instance: 'You cannot be in two places simultaneously'. 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 no longer stands. 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 bloodshed. Especially when there is a worldwide 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 that never indicate a truth. 'intended to be enduring and seldom amended' tries to push the rules and guidelines into the shape of truth. But that cannot be done successfully. Rules and guidelines are 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 that you will get a fine for driving too fast.

I ask myself: Who has ever proven this axiom was true? I think that spoken language was accidentally 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 behavior 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 is or works the same daily. 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 through mathematics: Anything having mass has an equivalent amount of energy as a consequence of the symmetries of space and time.

Scientists formulate principles using observation, experiments, and mathematics. 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 design science. Architects are designers of total concepts (architectures) and supervisors of realizing structures and solutions with applied concepts.

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 designers. Most architects consider their profession to be about planning and advice. This, I think, is a misconception. This attitude towards architecture, not seeing it as a design science, also impacts 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 change system structures. They don't make decisions, create designs, etc.. while 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. https://www.infoworld.com/article/2988671/enterprise-architecture/architecture-principles-considered-harmfull

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 unnecessary complexity, which greatly enhances the reliability and flexibility of your environment. By reducing complexity, people understand how things work and why they are designed the way they are. This enhances the adoption and usage and reduces the number of questions and complaints. So, the most important principle 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. However, 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. It works best in immature organizations and is the traditional approach found in TOGAF and most literature. As Mark stated, it works in many cases.
2. “A principle must guide 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. 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 for the specific good of the specific organization. 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 enterprises should have and will be applied to all their systems and operations.

Geoff Young - Architecture principles without governance are 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 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 are not appropriately used?

Jagannath Shanmuga Sundaram - AP is part of the EA process and realized at the design, pattern, and strategy level... It should be applied with care and limited w.r.t business model /requirements; otherwise, it might be in the 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, methodology, and processes. If you can, please read my article on my profile.

Greg Horsman - the 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 a 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, EA is probably 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, but if nobody understands the values, then nobody will respect them. In the end, the issue is top-down and related to a value proposition to key stakeholders. Governance, Principles, and more are normally accepted if you do some "homework" before. Another aspect that brings complexity is this digital world, where everything should go fast. Companies are now using Agile and DevOps and may "skip" EA for the 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 and add support to policies, governance, and managing technical debt. Calling them disasters seems either improper to use them without understanding or needs proper understanding and purpose of them. Also greatly helps in building consensus at a large federated organization.

Willem Oorschot - One of the issues with principles is that they don't last forever and have to evolve. 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 the top 10 principles it will help a lot if we can have some governance around those for proper 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 principles 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 organization needs to build up is the capability to govern those principles. There's never a shortcoming in 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 a mechanism to direct change. But, I observe that today's practice of using guidelines, principles, or whatever we would like to call them, has (a.o.) the following issues:
1. they lack 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. For, it is not clear where architecture stops, and design begins, where business goals stop, and architecture begins, or what is essential and what is a temporary implementation choice.
The solution is to stop the contextless blabbing about principles and only consider an integral approach (in which principles can be a 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 the 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 the following posts https://it.toolbox.com/blogs/ea-matters/architecture-principles-are-they-any-good-76184 and https://it.toolbox.com/blogs/ea-matters/architecture-principles-are-they-any-good-i-76185

Voytek Janisz - I agree with Adrian. They are the only a 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 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 doesn't make them bad...it just means you have not leveraged them well.

Nick Malik - Principles are a response to a 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 based on the principles before funding. That allows both architects and business stakeholders to 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 be applied to yourself as a designer. If you cannot even do this, then you have to stop everything you're 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."
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 a 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 if 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 appear 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 from demonstrating support for the vision when it does it in a way not described by the principles.

Truly descriptive principles should be means for description.

Pankaj Gupta - It's part of the organization's life cycle, IMHO. The principles are forced upon during a phase, and then it takes the shape of autopilot. However, it gets disrupted again, especially if there is a significant change of leadership in the organization. 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 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 https://www.referentiearchitectuur.nl/index/ArchiXL_referentie-architectuur?

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. Implicit of explicit, 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 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 on to the next change. That way, they have a chance to bed in.

Joshua Team MBA - I find a lot of resistance to the application of architectural principles. I think socialization is the appropriate term but like regulation and compliance, they have 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 spending and projects are justified via business cases, having principles that merely enforce best practices without helping to tick off a benefit in the business case can be a hard sell. Lastly, architectural principles must deliver dependable benefits that must be taken 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 organization stand to lose, rather than 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 upon by the team (including business and IT). They should give them guidance when it is hard to make the right decision. If a principle is made to set a framework of rules, it will fail. architecture principles are not equal to architecture rules. No one can be compliant with principles, and 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 organizations may not understand EA value-add or appropriate usage/benefits of EA. Another comment would be - that today's world of cloud-based architecture brings additional challenges to traditional ADM, as most organizations 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 they can fit inside agile sprints. Theoretical principles need to be changed appropriately and applied practically to cater to today's fast-moving businesses and their enablers as IT.

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

Somnath Ghosh - let me email you. appreciate 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 the EA sample principles mentioned in TOGAF 9.1 specifications. I guess a 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 to your blog.

Rohan Philip Buultjens - @Mark, in total agreement with you. Most organizations 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 behaviors that are aligned with the chosen (e.g., strategic) direction.

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

Chris Wilson - Mark - I think there are 2 types of principles - there are the principles that are applied to shape and formulate the architecture, and there are the principles that 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 everyday use). Also, the amount should be flexible so that you take only the 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 sets the direction, and we can verify whether a certain project goes in 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 to get a first kind of "compliance" score which indicates if the request goes in the same direction as the principles. The goal is then to follow up on the go-no-go decision that is made on the project to see how principles and projects are aligned. The score is, however, only informative though: a 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 behavior. Principles must be derived from the enterprise business strategy. "If we want to achieve a 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 rarely explained in practice. If organizations create custom-defined principles while looking at all aspects of the enterprise business strategy, their principles would be effective.
Principles must also 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 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 in 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 to the business strategy, while in some other cases, principles are understood like high-level ADRs. In my opinion, in the 'modern enterprise' in which the business strategy is a much more dynamic function, the architecture, hence the principles, should be evolutionary by default, meaning the first principle should be every question and 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 their solution design. I am sure there are better ways to streamline and measure this than what I have experienced, but it is something to think about if you have not considered anything along these lines