Inside Architecture blog
The profession of Enterprise Architecture struggles, in part, because we have done a poor job of outlining our value proposition to senior leaders of our respective companies. I have posted occasionally about the value proposition of EA. I was a lead author on the FEAPO perspectives paper that discusses the value of EA. However, I want to highlight one value proposition that is often missed: the human side of envisioning.
While we know that software can expose data, we sometimes forget that writing software can expose data.
When a system gets deployed, we typically build a development environment, one or more test environments, and a production environment. No surprises there. However, developing software with sample data, instead of “real” data, can allow defects that are difficult to catch. On the other hand, using “real” data (typically a subset of production data) runs considerable data security risks. In this post, I’ll discuss the notion of building a general purpose deidentification tool specifically for software development and DevOps purposes. (more…)
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.
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.
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.
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.
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.
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|
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.