Enterprise Architecture principles are arguably the most commonly created EA artifacts across EA teams. Unfortunately, principles also seem to be one of the least helpful artifacts EAs produce. What! Principles don't add value? Unfortunately not in most cases.
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.
The second issue with principles is that they are passive. A principle sits there until something comes along to test it. Strategies are more active. They drive action all on their own. They tell people what to do. Strategies also provide some wiggle room so veering off the strategic track a little isn't as egregious as breaking a principle. Strategies are also easier to connect to goals and objectives and are much better understood by the business than are principles. And that "buy before build" principle? Isn't it really a strategy? Many EA teams I work with have a hard time defining their strategies because they have couched them as principles so they have a difficult time articulating meaningful strategies.
As all the hype around business architecture increases, a lot of clients are asking about EA’s relevance to the business. One newly minted EA put it this way: “I get the distinct impression that the business side of EA gets at best lip service. It’s no wonder business leaders criticize architects for being IT centric rather than business driven. But doesn’t the “E” mean enterprise?”
Architects ARE guilty of being IT centric, but that is changing. In our defense we have come by this bias legitimately:
• From the very beginning (see Zachman’s first article: http://www.zachmaninternational.com/images/stories/ibmsj2603e.pdf) EA clearly included a business component. But until recently the concept of business architecture was: “what IT needs to know about the business.” So in theory EA is about the enterprise but in practice has been very technology centric.
• Because EA was originally designed by technologists for technologists EA has grown up in IT further contributing to the idea that it is about technology.
• Because it has grown up in IT, EA practitioners are almost all technologists who are very comfortable in the technology space but not so comfortable in the business space. In fact, architects are often their own worst enemy when it comes to the business. They spend very little time with business leaders (outside of a specific project context) and spend even less time educating themselves about business (see my April 21st, 2009 blog post).
One of the biggest problems for EAs is their lack of connection to real business decision makers. Sure, architects frequently interact with business project managers in the context of an ongoing project, but they rarely work at the business strategy level discussing business models, capabilities, or market strategy. Ask yourself this question: “How much time do I spend directly interacting with someone in the business on a topic not related to an ongoing project?” DOUBLE IT!
Read business books to increase your business IQ.
Architects have deep technical skills and expend most of their discretionary time and money enhancing their already significant technical knowledge rather than branching out into developing their leadership and business acumen. Successful architects in the future must be business savvy. Don’t have the time? Think again. The average business book is less than 300 pages. Ten pages a day (about 20 minutes for most) will net 12 books a year. A quick search on Amazon.com returns just short of two million business books, see our reading list for business architects to get you started.
What will you learn? Here are just a few of things I got from reading business books:
Good to Great by Jim Collins – I learned about the hedgehog concept. Finding that one thing the organization is passionate about, can be the best in their industry at, and drives their value creation engine. This led me to change my strategy from selling EA to offering innovative EA services that my consumers really wanted.