Unprincipled Architecture

We’re Human First

In the world of human interaction, no one thing is violated with such stunning frequency as presumably inviolable, ostentatiously declared, ultimately vapid things called Principles. From Religion to Politics to Marriages to the world of Business, Principles often seem merely to inform the outer world of what we’d like to pretend we stand for. Deeds are hard to mask. Inner thought and a recognition of what we’re ultimately capable of? Well that’s easy to paper over and misdirect with a list of Principles. When it comes to the business of Information Technology, human nature makes no exception.

 

In a Name

What do we even mean when we use the word “Principle” anyway? For illumination I turn to that oracle of the ages to which I turn whenever I’m grasping for something that I feel I ought to know: Google.

 

“prin·ci·ple/ˈprinsəpəl/Noun. 1. A fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning. 2. A rule or belief governing one’s personal behavior.”

 

Ah. There it is. First off, it is a noun, not an adjective, not a verb. It is a fundamental truth or a fundamental proposition. It serves as a foundation underpinning a belief system. It is a rule. It is governance. It is logical and enduring. A Principle doesn’t “guide” me. It doesn’t suggest. At the end of the day, it isn’t optional. It is intrinsic.

I’m not sure I know of too many things that really fall into this category that I’m called upon to reference on a daily basis. Certainly not in day-to-day work in IT. A systems of ethics would certainly fall into this category. But what else would? I can’t say ‘simplicity’ is a Principle because, let’s face it, not everything we produce is simple no matter how much we’d like it to be so. Then is this definition too strict? Is it even relevant? Is this all there is to say about Principles? As with anything in business or technology, of course not.

 

But Industry Says…

If we turn to the keeper of TOGAF, The Open Group, we see a definition of architecture principles that goes something like this:

 

“Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.

In their turn, principles may be just one element in a structured set of ideas that collectively define and guide the organization, from values through to actions and results.”

 

So to TOGAF a Principle is merely a general rule, a guideline. It is still enduring and not to be trifled with, but it isn’t a commandment and can apparently be safely ignored (as there are no risks to doing so spelled out). At any rate, it is simply one of several elements that guide an organization, they say. From my viewpoint, this definition begs the question of why Principles exists at all. Any number of things can guide decision making. Who cares if you have Principles or not in that event? It doesn’t even seem that they are particularly useful since they require a “consensus” of the enterprise in order to be defined. If we already had a consensus, why do we need a Principle? My experience shows it is precisely the companies without consensus that are in most dire need of defined Principles. Frankly this all strikes me as run-of-the-mill TOGAF-three-dimensional-layered-cube-doublespeak silliness. But hey, I’m not TOGAF certified.

IBM, the elder statesman of IT, opines at length on the matter of Principles:

 

“A principle signifies a point, or points, that allows for the formation of a norm or rule that guides the development of ethics by which you operate. Reducing a rule to its principle says that, for the purpose at hand, the principle cannot be questioned or further derived unless you create a new rule.

Principles are used by an organization to support its overall mission. They are used for decision making because they are general rules and guidelines. They should be long-lasting, and rarely change. Principles are based on industry best practice, and reflect the enterprise’s purpose, vision, and values that are implemented through policies, procedures, and standards.”

 

Ah, so a Principle is merely an abstract point or points, thought or thoughts, that may or may not lead to the suggestion of a formation of a norm that may be a rule that can do something else that – buy WebSphere – can support a strategy that – buy DB2 – has a mission that is – buy more servers – based on best practice. Whew. For a second I thought I would need a dozen Software Group guys for a year to figure that out.

Okay, aside from the sarcasm, it is important to note the uniqueness and non-derivative nature of a Principle in this definition. They’re used to support a mission and guide decisions. They rarely change and are based on industry consensus. Good grief. If a company rarely reaches consensus, how in the world does an entire industry reach consensus? Has IBM read the twitwebs lately? There’s precious little consensus on Principles aside from the fact that they should be good ones. I can’t quite get over the statement that they’re useful in decision making because they’re general guidelines. That just seems really fluffy to me. What about them being general and abstract makes them particularly useful in making strategic or tactical decisions that inherently involve real-world people, process and technology not to mention dollars? It seems to me that they would be singularly unhelpful in that context. You know, unless we’re saying such a Principle would be “The decision should be made in English.” At least then I could see how it would be helpful, you know, to English speaking people.

So this begs the question, do we ever use Principles in our business, or when we practice IT in general and Architecture specifically? Or rather, does it even matter whether we do or not?

 

Some Have Said

This isn’t the first time this question has been raised, incidentally. While the topic of whether Principles matter has been discussed by several others over the years (notably Richard Veryard in 2 posts in March and July of 2010), I first recall seeing this topic broached in spring 2009 by Jeff Scott at Forrester:

 

“In the first place most principles are not really “principles” at all. Instead they are mostly good intentions. In the world at large, principles are rules we live by. They are the things we believe strongly in and adhere too unless there are extreme extenuating circumstances. For example, engineering principles are generally based on laws of nature so they are very rarely broken. Personal principles are based in moral beliefs and are broken occasionally but only under duress (or too much alcohol). But EA principles are different. A principle of “buy before build” doesn’t really mean we will always choose to buy solutions when they are available. The “buy before build” principle really means that we will consider buying an available solution before we jump to coding. The problem this creates is that our clients see us declare principles that we don’t adhere to. They (correctly) come to the conclusion that we don’t really mean what we say.”

 

This reminds me of a scene from The Pink Panther Strikes Again:

Clouseau: What is your name?

Mr. Shork: I’m Shork, the gardener.

Clouseau: And what is it you do?

Mr. Shork: I’m the gardener.

Clouseau: Why didn’t you say that in the first place? Now listen… What was

your name?

Mr. Shork: Shork.

Clouseau: The cook?

Mr Shork: Gardener.

Clouseau: Aha! Now we are getting somewhere!

 

It would seem absolutely critical to me that anything IT does be seen as consistent to the Business. Using words like “Principle” with the definition most people have for it is a sure-fire way to disappoint folks. It turns out that what we in IT have been saying is an iron-clad, rock-solid thing that we will always do no matter what, a thing that we found our operations on, is in fact merely a suggestion, a preference. As a result, we only sometimes follow our “Principles”. In effect, we having Guiding Preferences instead of Principles.

Mike “The Architect” Walker speaks to this in his post on the subject, also from 2009:

 

“I have seen very large EA organizations create the master set of principles that took them a better part of 3 months worth of very senior talents time to then proceed to frame them on a wall and never to be followed again. This is obviously an extreme but I have seen this behavior at more than a handful of organizations.

 

My opinion on issues with principles are:

• They are subject to interpretation by the architect. Meaning that since principles are very high level there is a lot of room to make an interpretation.
• Effectiveness hinges on the competencies of the architect.
• Is an all or nothing implementation. Meaning, if only a select few architect follow them and the rest don’t this breaks down.
• What is a principle any ways? Jeff Scott alludes to this when he makes reference to: “buy before build” principle? Isn’t it really a strategy?”.
• The problem is that the term principle is too generic and means different things to different people.
• There are issues of abstraction and scope.”

 

Good Lord. If they are abstract in nature and scope, open to interpretation and so generic that they can mean just about anything, then how can we possibly consider them to be Principles? Talk about built-in inconsistency and increased variation. More importantly, what message does this send to our customers? (You remember them, the business, the ones funding all this?) It communicates an unserious, waffling, dithering, pie in the sky, ivory tower approach and confirms for them what they already suspected: that IT and enterprise architecture is a huge waste of time and money.

 

Let’s Be Serious

The Business doesn’t care about our Principles or Guiding Preferences or strategic documents or statements of fact or awesome Visio skills. They couldn’t care less if we built things that were simple, reusable, flexible, horizontal, vertical, cross-cutting or elegant. They care about one thing and one thing only: do IT services add value to the enterprise? When they come to us (usually because they have to or someone forced them), do we provide something that is of demonstrable value to them? Is it useful? Does it make something faster and/or cheaper to get to market? Does it enhance some business activity or add a new revenue stream? Is it worth their time, effort and money?

To answer those questions, we need only two Architecture Principles:

 

#1 Do No Harm

#2 Always Provide Value

 

These must be as a Religion. Our Theocracy must revolve around them as Commandments. They can’t be waived. They aren’t suggestions. They are intrinsic to us as technology practitioners. This is the reason technology exists within the enterprise. This is what we do and who we are. If we don’t do both of these, then we have no business doing anything at all.

Everything else, all the other “Thou Shall” statements we bandy about, are mere dressing to these two Principles. These other things are not Principles at all. They are… other things.

 

The Other Things

A CTO can’t run his organization based solely on the two Architecture Principles above. Principles are nouns, remember? They are not actions. They are not a means. For that we need to turn to another construct that puts Principles where they belong.

Before IT can do anything, the CIO/CTO must lay out a Vision of what that IT organization is supposed to do. What is the reason it exists? Why does the company have an IT organization to begin with? Without a simple statement or statements about the existential rationalization for the organization, nothing else really matters (or at least, won’t be effective). We’re human beings. We need a reason To Be.

Efforts to realize that Vision must be represented by a set of… somethings. I tend toward Objectives, others I know prefer Goals. To be sure they are different, and there is a more complex relationship here than I’m letting on (for instance, where is “Mission”?). For simplicity just go with me on it.

Achieving a set of Objectives will help us realize the Vision laid out by our leadership. Furthermore, we must have not just the Capabilities (both business and technical) to achieve those Objectives, but also sets of Strategies that will get us there. There are a couple of things that inform us on the execution of those Strategies. One of those things is a good set of Best Practices or Standards. They can be ones we invented ourselves or that we borrowed from others. It doesn’t really matter. The other one of these informative things that guides our execution is our foundational set of Architecture Principles. I have two. You may have four. Or six. If you have more than that, I’d start to question things. Moses only delivered Ten to govern all of existence. Surely your little IT group can get by with less.

If you look at this set of relationships, which I drew on my whiteboard in about 90 seconds and is therefore possibly incomplete, it reveals the fact that what we end up doing most when discussing Principles is not discussing Principles at all. Most of the time we’re discussing Strategies for achieving Objectives that help us realize the Vision.

 

Let’s Be Unprincipled

The Principles are the conscience, the right or wrong impulse. It is highly unlikely that they would ever change. So ask yourself, why do we spend more than a few hours on them at all? They should be obvious, feel ‘right’ and be easy to write down in a few words. In effect, we need to not bother with them beyond the carving into stone and abiding for eternity.

To be sure there are myriad Strategies that are unique to our enterprise, our industry. There are always Standards and Best Practices we need to define for ourselves and try to follow. We need to certainly get all of these right. But agonizing and hand-wringing over “Principles” only to go about routinely breaking them serves no purpose aside from flushing our credibility straight down the toilet in the eyes of our customers.

We need to be, in effect, un-principled with architecture.

I invite your feedback. You may say I’m wrong, late to the party, irrelevant. However, I would fight you to the death, 300 style, if you suggested IT’s overriding Principles are not #1 Do No Harm and #2 Always Provide Value.

•