206-245-4311
Inside Architecture blog
Does Academic Sloppiness Hurt EA?
There are surprisingly few researchers publishing articles about Enterprise Architecture from universities. Even well considered programs like Penn State and MIT may only publish four or five papers a year. Therefore, when a single researcher (a doctoral candidate at a well regarded university) publishes no fewer than fourteen separate papers on Enterprise Architecture over the course of three years, a few directly through the British Computer Society website, folks like me notice.
Unfortunately, as this article will show, this researcher appears to be building a body of sloppy work that he promotes widely, potentially harming both the profession of Enterprise Architecture and the reputation of the British Computer Society for promoting him.
Self Organizing Enterprise Architecture
Our language can limit us. Our words can prevent us from thinking about our world in a clear way. This article is about freedom from our own words. Read at your own risk.
The Capability Instance – can capabilities be realized?
Bizbok 5.5 from the Business Architecture Guild mentions an interesting concept that I’d like to discuss here: the capability instance. I’d like to caution that this description is a concept rife with conflicts. I’ll explain in a moment.
For those of you who don’t have a copy of the Bizbok 5.5, first off, get one. But for the sake of expediency, the description I’m referencing comes from section 2.2. in a subsection titled “The Capability Instance”
“As a rule, capabilities exist in multiple business units and enable multiple value streams and value stream stages. As a result, a useful concept called a “capability instance” has emerged that allows practitioners to associate unique attributes, such as effectiveness or automation levels, with specific instances of a given capability in practice. A capability instance is defined as “a specific realization of a capability, as it exists or is envisioned to exist, in the context of a given business unit, value stream, or other situational context.” In practice, identifying capability instances provides the business architecture practitioner and consumer with flexibility to assign unique heat map values and other ratings to a capability based on its effectiveness or impact within a given business unit or value stream.”
OK… so why my concern?
Almost a decade ago, I set out inside Microsoft to stop the raging debate about the definition of capabilities. At the time, our business architecture team was using the concept of capabilities derived from the Microsoft Motion framework (very much like the definition used by the Business Architecture Guild today) as composed of People, Process, and Tools. (We added “Information”). However, the Business Process Innovation team was busy creating certifications for Six Sigma that describe processes as having people (in roles) and tools under the activities. They saw no value in the concept of a capability at all. I got my Six Sigma Green Belt and saw the problem. Their use of language was sufficiently different from the words used by Enterprise Architecture that our two teams were creating problems for one another.
During this time, I blogged rather extensively on the difficulty of aligning these concepts. I went back to source materials from such thought leaders as Michael Hammer and Michael Porter and held lengthy conversations with teams involved in business process management as well as business architecture.
The results, which I presented at the BPM conference at Stevens Institute of Technology, was that we could bring together business process management and business architecture if we recognized one very important principle: a business capability is a concept. It cannot be realized. A business process is a conceptual description of a realizable set of activities. A process description is only interesting once the process is realized. They are different in the ability to realize them.
A business capability is a concept. It cannot be realized.
In that frame of mind, when I discuss measurement of a capability, I measure the maturity of the constituent elements. I measure the people, the processes, the tools, and the information independently. The capability measurement, if used, is a score of these four individual elements.
(Bizbok uses different framing: they now view a capability as composed of Organization, Value Streams, Resources, and Information, a distinction that I’m stepping over for now… a deeper discussion for a different blog post).
The point is that the notion that you are measuring the effectiveness of a capability is silly. You are measuring the effectiveness of a business process. You are using the concept of a capability to allow you to compare completely distinct business processes that have similar impacts on the organization.
The moment you cross the line and allow yourself to view a capability as something that can have an instance, you also cross the line between “what” a business does, and “how” a business does it. The value proposition of the business capability concept collapses if you cross that line.
I soundly reject the notion of a capability instance as a mechanism to measure and apply attributes that belong in the world of business process measurement and management. If there are other uses of the capability instance concept, I’m open to them.
Note that it is OK to create a score of a capability in a specific instance. Is that a measure of a capability instance? In a way, yes. For example: the score of an accounts payable capability in customer refund handling is distinct from the score of an accounts payable capability in vendor management. By comparing these scores, am I measuring the effectiveness of a capability instance? No. That’s a measure for the underlying process. It’s a carful distinction.
Make the distinction.
The concept of the “Nearest Common Manager” in Enterprise Architecture
I’m going to share a secret. Something that no one talks about, but is critical to understand if you are to be an effective Enterprise Architect. Are you ready?
People do what you pay them to do.
What a letdown. Everyone knows that, right?
But we don’t talk about it because it is an assumption of every day work. Those assumptions drive a great deal of behavior in an enterprise. In Enterprise Architecture, we must think about the assumptions, because assumptions can stop progress without anyone realizing it. Assumptions can impede communications. Assumptions can cause good behaviors to be punished and bad behaviors to be rewarded.
So let’s look at this assumption a little more closely. Who pays you? Well, the guy or gal who can fire you if you don’t perform, that’s the person who pays you. So, if your manager says “run every decision past me,” you are going to run every decision past the boss. You are doing what you are paid to do.
This creates a hierarchy in an organization that is persistent and rather absolute, especially if you can be blamed. No one will defy their manager’s manager. On the flip side, if you are an individual contributor, you have no idea if you are doing what the CEO wants. Only your manager tells you what to do.
How does this affect Enterprise Architecture?
EA’s are often called to work “across silos” or to collaborate with different groups. There is no single manager that everyone in your “virtual team” reports to. You cannot go to a single manager and ask him or her to support your efforts.
One concept that you should be aware of is the “Nearest Common Manager.” This is the lowest ranked person that everyone on your virtual team ultimately reports to. In many companies where I have worked, the nearest common manager is the CEO.
The thing that you should be aware of: whoever the nearest common manager (NCM) is, someone who is in communication with the NCM has to have your back… someone who the NCM knows and trusts has to know what you are up to, and has to agree with it.
When you hear the term “executive support,” this is what we mean. Someone who can provide the air-cover that you will need with the nearest common manager.
The Repository Won’t Save EA
One thing most Enterprise Architects have in common: frustration with resistance to change. Channeling the words of some of my friends, frustration sounds like this: “We know many of the answers to common problems in IT, especially in how systems are developed and used, how data is organized and mastered, and how capabilities should produce shared components or systems. We know many of the answers… but no one listens!”
Yep. We do work and sometimes, no one uses it. Or we develop advice, and no one follows it. Common problem.
For some reason, the “answer” that I’ve heard bandied about is to buy software. “If we only had a repository for architecture, then people would use our models.”
um – no – not really.
If your models are not used, putting them into a collaborative storage and retrieval system will not get them used. It will make them more available, but in 85% of the cases, availability is not your problem. Either no one sees the value in using your models, or they don’t know how to read them, or using your models works against some political aspect of their lives.
It’s not that your stakeholders didn’t know the model was there. It’s that they don’t care.
Adding a repository won’t make them care.
Your first order of business is to build demand for the architecture models. Once demand is there, worry about the repository. Until then, a simple modeling tool will work.
Disruption – why you need business architecture
Business Architecture is, on occasion, a difficult sell. In many companies, it can be tough to get senior leaders to give you to remit to use the tools and techniques of business architecture. This is especially true in organizations that think of Enterprise Architecture as an IT function. The following video answers the question “Why do we need Business Architecture?”
Your feedback is encouraged.
The European EABOK and Enterprise Architecture Pattern Catalog
A number of years ago, I joined up with a small group of architects determined to create an EABOK (Enterprise Architecture Body of Knowledge). We got off to a good start and I even bought the domain (eabok.org). However, the Mitre Corporation (a federally funded research and development corporation) trademarked the name before we did, based on a white paper they had released in 2004. I was out-lawyered. So the name was theirs. They wanted to do an EABOK as well.
Defining Your Value Proposition
In the Enterprise Business Motivation Model, I require a business to define their value proposition independent of other facets of their business model.
Some folks resist. After all, they insist that they know what their value proposition is. Why write it down? They sell valuable stuff! It’s valuable, damnit! That’s why they exist. 10,000 customers can’t be wrong. For customers. For the owners. To make money… yada, yada, yada. It’s all a confusing jumble of words.
Describing your value proposition is necessary. It is critical. If you don’t understand, and agree upon, your clear value proposition, you cannot get agreement on strategy. Lack of common agreement becomes an insurmountable obstacle. Often the best way to demonstrate the need for this consistency is to ask each of the top managers of the company what the value proposition in, then present the differences to the CEO. Go ahead. Shock him (or her). It’s a good exercise.
What’s in a value proposition?
I often find, when working with clients, that discussing the value proposition is tough. There are nearly always different value propositions, depending on the viewpoint of the stakeholder. A value proposition answers the question: “What value do you provide to me?” Clearly, the answer can depend on “who is asking the question?” In addition, each stakeholder may need to hear more than one answer.
Stakeholders come in all forms. There are owners / investors, customers, partners, employees, and public / government. Each wants something different from you. There can be a pretty wide gap in these different perspectives. The gap between the value proposition from one viewpoint to another creates an issue in how a company aligns.
For my example, I use an analysis I did on a National Airline from a few years back. Let’s call it “Elbonia Airlines” for the sake of this discussion. The company was set up as a publicly traded commercial business and had taken on a good bit of debt. The national government rescued it after the economy collapsed, refinanced its debt, and put in a new CEO. All very public and quite messy.
Let’s look at some realities.[/fusion_text]
| Elbonia Air Stakeholder | Required Value / Value Proposition |
|---|---|
| Government owner |
|
| Private Investor |
|
| Customer |
|
| Partner |
|
| Employee |
|
The biggest challenge to this particular business model, however, is the difference in value proposition between the perspectives of the two chief types of investors: the government investor and the commercial investor. The value of a national airline to it’s country government is very different from the value of the stock to a commercial investor.
It is the delicate balancing act between these two kinds of investors that got the government airline in trouble in the first place. The airline had taken on debt because they had expanded service to a number of smaller destinations that are primarily appealing to foreign tourists. Those services were created to provide subsidies for unprofitable routes that the government demanded, and to keep ticket prices low on the unprofitable routes. However, the recession had caused the new tourist routes to become unprofitable.
The airline simply owned too many aircraft for the profitable routes they had, had no flexibility to drop unprofitable routes, and competition from other commercial airlines was keeping down ticket prices.
How did they solve the problem? By changing the relationship with the government. The government became a partner, not just an investor, in particular routes. That allowed the government to subsidize those routes and get out of the business of caring about the overall airline. The main commercial routes were expected to be competitive and profitable while the “required” routes were subsidized so that they wouldn’t lose money.
All this was visible by examining the value proposition as an independent element of the business model. Simply doing a “SWOT” analysis wouldn’t have focused leadership on this kind of problem, or this kind of solution.
Enterprise Architecture and Threat Modeling
What should an Enterprise Architect know about threat modeling?
I recently asked on a LinkedIn group about threat modeling and Enterprise Architecture. My first surprise came when the first set of responses were from folks who didn’t appear to understand what threat modeling was. So I guess the first order of business for anyone wishing to consider themselves an Enterprise Architect is to study up on what Threat modeling is.
The human element to strategy
There is no shortage of business thinkers and authors who will tell us this statement is true:
Anyone can create a good strategy. The most frequent failure is in execution.
Unfortunately, this underestimates the difficulty in creating a “good strategy.” While the statement above is absolutely true, it is not unusual to find companies that don’t have a formal strategy at all, or who fail to share their divisional strategies with all of their employees (a key measurement of strategy adoption in a company is “how many of your employees can recite your company strategy”).
One of the obstacles I’ve come to recognize in Enterprise Architecture is unique to companies that either don’t have a formal strategy or who do not share their strategy with their staff — you cannot align efforts to strategy if there is no consistent understanding of strategy across divisions.
I always knew this was true. I’ve become more and more convinced that it is a hard-and-fast rule. In other words, if you want to be successful as an EA in a company that doesn’t share strategy, this becomes your First Order Problem — how to develop a consistent strategy that everyone at the senior level agrees with and that they are willing to share with their staff.
That’s it in a nutshell. To be successful, your organization must develop a consistent strategy that everyone at the senior level agrees with and that they are willing to share with their staff.
First order problem — In other words, focus on this. Make progress on this. Measure yourself by your progress on this. Associate yourself with the people who “should” own this, and align yourself with the people who actually do own this (rarely the same person). Find ways to be involved. Find ways to contribute. Volunteer. Make things happen. Find ways to support incremental progress, while recognizing that the increment may not be good enough in the long run. For EA to become known for “doing successful Enterprise Architecture,” a clear and communicated company strategy is ground zero.