I’ve been asked a number of times over the years if I can explain the theory of Enterprise Architecture. I decided recently to reopen that idea. It’s not a new discussion. I refer to Tom Graves post on the Theory of EA from 2012 where he posits that the theory of EA, if one were to be described, cannot be used to prove the value of an EA design. The not-so-subtle hint is that there is, therefore, no value in creating a theory at all. I disagree. I believe that there is value in developing a theory of enterprise architecture.
Let me first recap my gentle readers on what I mean by a “theory of EA.”
Typically, in science, we start with observations. Observations are objectively real. They should be mathematical and measurable. They exist within a natural setting and may vary from one setting to another. We may observe a relationship between those observations. The goal is to explain those observations in a manner that is good enough to predict outcomes. To do this, we suggest a hypothesis, which is simply a guess. We then see if we can prove or disprove the hypothesis using data. If we cannot disprove the hypothesis, we have passed our first test. We use the hypothesis to predict new observations. We then check to see if the predictions are correct. If so, we have a useful theory.
Theories are created to explain observations and help predict new ones. So what kinds of observations would I include in the Theory of Enterprise Architecture?
These observations need to be measured, collected, and validated. And we need more observations to be researched, shared, and enumerated. We don’t know quite what EA explains just yet, and building out the list of observations gives us a place to start.
At the highest level, the basic premise of Enterprise Architecture is simple:
The EA Hypothesis: The structure of and both intentional and unintentional relationships among enterprise systems has a direct and measurable influence on the rate of potential change and organizational cost of operating and maintaining those systems.
The EA Hypothesis: The structure of and both intentional and unintentional relationships among enterprise systems has a direct and measurable influence on the rate of potential change and organizational cost of operating and maintaining those systems.
That simple statement is quite powerful.
The EA hypothesis demands that we create a definition for “enterprise system” and a method for describing the “structure” of an enterprise with respect to those systems and to describe the “relationships” between them. Clearly an enterprise system has to include socio cultural systems, information technology systems, workflow systems, and governance systems.
The EA hypothesis suggests that the relationships between these systems are important. That the relationships themselves influence the rate of potential change. as well as the cost to own a system.
The EA hypothesis demands that we measure the rate of potential change, and that we describe “organizational cost.” To do the latter, we must develop a clear idea of what is involved in operating and maintaining each of the included systems.
The hypothesis is also fairly unbounded. It leaves us with important questions to answer.
I’m intentionally not answering these questions here because it is rational to leave all of these questions open for scientific research. It is entirely possible that the answers may help us separate useful EA models from useless ones. It is simply too soon to tell.
The rationale for creating an EA hypothesis is the requirement, often expressed through strategy, placed on an enterprise by its senior leaders, to do one of two things:
This matters because nearly all strategy hits one of these two buckets. This goes from corporate strategy all the way down to personal improvement: either you are improving your production, or your production capacity. Either you doing what you know how to do, or you are learning new things. Either you are getting better at the normal stuff, or innovating to add new stuff.
Enterprise architects are called upon to help in both ways. We have to answer questions like: “what does “innovation X” do for us, and what does it do to us?” We also have to contribute to ongoing concerns like “how do I grow my business in “Market Segment Y” in an innovative and compelling way?” and “How do I cut the cost of our IT expenditures?” and “How do I improve the quality of my customer data?” These questions fall under the category of “organizational cost”.
* Cost and quality come together to include a balance of monetary cost, effectiveness, customer satisfaction, efficiency, speed, security, reliability, and many other system quality attributes.
We need a clear theory of Enterprise Architecture because answering these questions is difficult to do well. We have operated without a theory because we were able to “guess and check.” We would guess an the scope and value of an initiative, undertake it, and check on its value later. But we are not able to say, in advance, that “proposed initiative A” is foolish compared to “proposed initiative B” because we have no science here. It’s all just “guess and check.”
The term “guess and check” is not new. My kids learned to use the “guess and check” method in elementary school math class as a way of exploring a problem. But that’s where the “guess and check” method belongs. Elementary school. Grown ups use proven science.
All except EA. We still use “guess and check.” It’s time to grow up.
Moving forward from here requires research. More on that connection in another blog entry.
So, full disclosure, I care about Wikipedia. Call me dumb, I know. Wikipedia has been described, alternatively, as the best platform ever invented for fostering useless arguments among ignorant people /and/ the most successful encyclopedia effort of all time. The truth, as always, lies between these extremes.
Well, I’m part of a small team that is working to clean up the Wikipedia pages dealing with Enterprise Architecture. One thing that we noted recently is the fact that there are two pages, similar, both rather poor, that cover essentially the same topic.
One page is called “Information Architecture” and the other is called “Data Architecture.”
We don’t believe that there should be two distinct pages. Wikipedia has a feature called “redirect” that allows the name of one page to point to another. So it’s possible to bring these together. However, the debate is now open… which one? Should the field be called “Information architecture” or “Data architecture”?
(Note, for a while, User Experience Designers used the term Information Architect. That seems to have faded and been replaced with User Experience Designer. I’d love to hear from folks in the UxD business about whether they feel ownership or kinship to the term “information architect”)
Or, third option, we are wrong… and there should be two distinct pages because these are two distinct concepts.
I asked for responses to a quick survey on the questions above. I’d like to share the responses.
There were 55 responses between Nov 21st and Dec 2nd, 2014. The responses broken down to be approximately equal: 1/3rd from North America, 1/3rd from Europe, and 1/3rd from Australia and New Zealand.
In the first question, I asked if there should be one article or two. The answer from the community is: a dead even split.
In the second question, I asked if we were to go with one article, what term should win out. Information Architecture, Data Architecture or It doesn’t matter. As an out, I gave folks the ability to answer this one with: leave two terms.
For the folks who want to combine to one term, Information Architecture beats Data Architecture hands down (34.5% vs 10%).
But half of you (49%) said: No. Leave two terms. They are different!
With these results, I’m inclined to leave two pages and just work out the distinctions so that there is clarity. That would be in keeping with the career path already laid out by DAMA and would prevent a conflict. The comments provide additional support for this notion and even provide insight into how to divide these two areas up.
Note that I won’t be able to say that the terms are effectively interchangeable. Rather that each one addresses a specific set of concerns for a particular stakeholder community.
The one thing that I cannot answer: can a single individual rotate between two roles: an information architect and a data architect, wearing the appropriate “hat” for their stakeholders, with minimal additional training required? I’m inclined to say “yes”.
I’ve met many Architecture Managers over the years. Sometimes they go by the title of “Chief Enterprise Architect” or “Chief IT Architect” and other times, the title is “Vice President of Architecture and Strategy” or some variant. The men and women called to serve in this unique role have a distinct, and uniquely important role to play in the success of the Enterprise Architecture function in their enterprise. Yet precious little is said about them.
In this article, I’ll touch one some of the key qualities I would expect to find in a successful Architecture Manager.
As the role of Enterprise Architect matures in organizations around the world, we’ve begun to see the tremendous impact that an effective architecture manager provides. In many ways, the Architecture Manager is the single most important role in the department, but also the most difficult role to fill. That is because, typically, the role is filled by a person who “moves up” from being an Enterprise Architect. Unfortunately, being an excellent EA is poor preparation for this particular role.
An Architecture manager is:
In my travels, I’ve met both good Architecture Managers and not-so-good Architecture Managers. The ones in need of improvement nearly always struggled at one of the above.
Enterprise Architects are rare birds… especially good ones. There are many folks who have worked to become Enterprise Architects, and a few who succeeded in recognizing the uniquely holistic role of an EA. Typically an EA has to manage through influence alone, because it’s rare that an EA has a team of resources assigned to him or her. But an Architecture Manager is in a different position. They do have a team, and unlike other efforts where they could be objective about a business leader’s business processes and functional alignment, they now have to perform architecture on themselves. Sometimes, they succeed.
If you find you need to hire an architecture manager, you’ll need a list of responsibilities for your hiring team. Just copy the following list.
The responsibilities of an Architecture Manager include:
Some of this is pretty obvious, but it’s worth stating anyway. The architecture manager has to be familiar with enterprise architecture. But they also have to be familiar with how things can work in an organization, especially if the focus of the EA program is related to IT (as it nearly always is).
In many cases, people who move into the role of Architecture Manager worked their way to that role as an architect. They may have been a technical architect, solution architect, business architect, or enterprise architect. In many organizations, these roles are deeply technical. Of all the architecture managers I’ve met, the overwhelming majority are technologists.
Unfortunately, most technologists don’t have the skills to focus on the responsibilities listed above. It is tempting to continue to be a technologist once moving to this role. It is also suicide. Your term as the “Vice President of Strategy and Architecture” will be short if you cannot step back and let your team perform the technologies or modeling activities typical of an architect. This means, for the architecture manager himself or herself: No modeling, No coding, No time spent geeking out. (Ok, exception, fiddling on the side is fine, especially if you want to “stay warm” with your technical skills... but nothing deliverable.)
First place is the same as you’d expect for any role: find a person who was successful as an Architecture Manager in another enterprise. Be careful of people who performed but did not succeed as an Architecture Manager. Most folks fail. Find out if the function continued after they left, and if their team enjoyed working for them, and if their stakeholders saw fit to provide an increased level of interaction with their staff members. Look at examples of their teams’ deliverables and ask about their ability to build and maintain new business processes.
Second option is to bring in an experienced architect and let them take on the role. Assuming the team already exists and is well accepted within the organization, this is a reasonable approach. Finding a seasoned architecture manager is extraordinarily difficult, so this may be the only rational option. The person you select should have worked for at least six years as an Enterprise level architect, with increasing levels of responsibility, and should preferably have been a resource manager at some other point in their career. If the program does not already exist, see the next section.
Third option is a seasoned manager who has no experience as an Enterprise Architect. This may be a distinguished technical architect, or the leader of a highly visible program in the past. These folks are expected to bring expert team leadership skills and deep technical skills. The biggest challenge that they will face is being able to adequately learn the role. Unlike most other management roles, the Architecture Manager must be able to SELL the value of the role of Enterprise Architect, and that is extraordinarily difficult to do if the manager wasn’t an architect first. The learning curve is very steep. To pull this off, the Architecture Manager will need a good mentor or an experienced consultant to help guide them through the first year in role.
If you don’t already have a functioning Enterprise Architecture program, your very first hire will be the Architecture manager. This role will be doing a great deal of heavy lifting in that first year. Setting up processes and deliverables. Making sure that the stakeholders buy in to collaborating with those processes. Hiring and situating staff. Creating priorities and managing resources. Setting up measurement and demonstrating value. It’s a tough road to build from scratch while providing value.
The only advice I can give: do NOT build a new EA program around an Enterprise Architect who has never been an Architecture Manager before. That is simply too much for a single person to handle. Going from EA to Architecture Manager of a new program is a huge leap, and I have never seen it be a successful approach in the long term. The person you hire may be a “survivor” who knows how to avoid being fired, but that won’t make them effective. Once they move to another role in the enterprise, the function will likely vanish.
You need the Architecture Manager to be effective. To build a program with lasting value. To build a program that matures over time.
So if you are building a new EA program, build it around an experienced Architecture Manager. Then support them with resources that they did not ask for: (a) an outside expert who can provide a neutral point of view and sounding board as they build and struggle that first year, and (b) Serious “air cover” so that they have the time needed to build the team, create the processes, build support, and demonstrate early value.
The single most important person in the Enterprise Architecture function is the Architecture Manager. This critical role is part visionary, part marketer, part people manager, and part evangelist. They have to change the organization and keep the change from undoing itself. The role of Enterprise Architecture is highly dependent upon the skills and the focus of this key role. Choose wisely.
Organizations do not work, in real life, like they work on paper. On paper, there are departments (all shaped like a neat rectangle) and business processes with neat inflows and outflows of responsibility and information. On paper, you improve things by modeling things on paper, and then moving things around, on paper, then teaching people to follow the process that your neat paper diagrams represent.
In real life, there are human beings and the tools that they use. Sometimes the tools move information from one person to another. Sometimes, they just aid in communication. People meet and get to know other people, and they learn to trust some, and distrust others. Some folks have different measures and motivations and just “pass by” one another. Some subset of these people will have shared cultural values and expectations. There may be many cultures in an organization: both because the organization is in multiple places, and because people from multiple places join an organization. Also, “business culture” arises as leaders achieve successes and people learn to use certain “cultural expectations” to get things done efficiently.
Reality is a lot messier than pretty rectangles.
Enterprise Architects apply science and engineering and aesthetics to the challenge of organizational change. We are unique in that most other “change artists” are not focused on engineering and some even ignore science. (see Daniel Pink’s TED Talk on the Surprising Science of Motivation). Few even know how to spell aesthetics. Yet, when you are dealing with systems that contain and include people, you have to use aesthetics, and you are ill prepared for success if you ignore science. Engineering is a mindset as much as a class of methods. It involves applying the things that science has discovered and using that understanding to build great (and sometimes terrible) things. Engineers build on ideas and use them, often experimenting on systems that are too complex and intertwined for “pure science” to get arms around.
As Enterprise Architecture is such a young science, we have relied to heavily on the “boxes and lines” model of enterprises, and not enough on the messy but important sociocultural view of an enterprise. We find it easier to document, and model, and even simulate, processes as though people were interchangeable and their relationships didn’t matter.
That is just lazy.
It is time to get up off our collective butts and start working out ways to understand sociocultural influences, relationships, and architectures. We have to build ways to detect, measure, and consider these structures when we measure capabilities, or improve processes, or suggest automations, or evaluate business models, or any of the two dozen things that EA’s do.
The value of EA often comes to an executive in the form of a reasoned opinion that is based on data that no one else is looking at. Let’s consider the possibility that examining sociocultural influences can provide interesting opinions that an executive will find valuable.
We should consider sociocultural information if:
Think about it. Do you believe that any of those statements are false? I can find ample examples for each one. So if sociocultural interactions matter, why are we not tracking them, learning from them, using them to make decisions?
It’s only hard because we haven’t tried.
(This post inspired by the many similar pleas shared by J.D. Beckingham in social media).
This is the first time I’ve done this, so I’m hoping that my friends will contribute your opinions: I’ve created a survey asking a few basic questions about how your Enterprise Architecture program is valued, or not valued, by your organization.
KwikSurvey Poll – Does your Enterprise Architecture program deliver value?
Note that this is a free survey tool that doesn’t allow me to collect text responses unless I pay, which I didn’t, so there are no text response fields. If you want to comment on the survey questions or assumptions, please jump over to LinkedIn and comment in this thread:
LinkedIn Discussion – Do you have an effective or ineffective EA Program
All comments are anonymous. I will publish the results on this blog. This is just an informal data collection exercise but one that I think may provide a little insight into how you and your peers measure the value of your Enterprise Architecture program.
We all know that Google lost a landmark legal case recently. As of now, a citizen of Europe has the “right to be forgotten” on the Internet. As of now, a citizen of Europe can ask Google to “forget” them, so that a search of their identity will not return embarrassing information from the past. This allows a person to live past a mistake. Your college indiscretion, and that time you were fired for photocopying your butt, or the time you got drunk and drove your car into a swamp and had to be rescued… all of that can “go away.”
However, this becomes much more difficult when we consider the emerging Internet of Things (IoT). In the Internet of Things, the “stuff” that you own can generate streams of data that do not remain within your control. That data is called “Information Property.” It is the information that YOU generate, in the things that you do. I believe that if YOU create a bit of information property, you should own it.
That information property, thousands of tiny bits of data about you or your activities, will wander out of your house, or your car, or your phone, to companies and governments running cloud-based data centers. That swarm of data surrounds you, and be used to profile you, track you, predict your actions, influence your choices, and limit your abilities to get “outside” the system. Most folks will not have any problem with this cloud of data. At least not at first.
Where we will first feel the pain of this cloud of data: when you want to be forgotten.
We have been dealing with “data about you” for a while. When you apply for a loan or a credit card, the information you submit becomes the property of your creditor, and they share that data with credit reporting agencies, along with your payment history, employment history, residential history, status of property ownership, and basically any other factor that finance companies feel would influence your likelihood to pay your debts. The US Federal Government has placed some controls on this data, but not many. Europe has placed entirely different controls. You have no right to be forgotten, but you do have the right to limit their memory to a decade. That allows you to “get past” a mistake or series of mistakes. But you are always “known.” However, a mistake can be forgotten.
This is a model we can use. Here is data, about you, outside your control, that get’s “forgotten” on a regular basis as it gets old. There is a possibility in the credit reporting world for being “forgotten” because the data is tied to you, personally. It is ALL personal data.
This is not (yet) true in the Internet of Things. If your car sends data to a smart roadway system, there is a great deal of information about where you go, and when, but under most circumstances, your identity is not tied to that data. It’s the identity of the CAR that is sent, but not the identity of the driver or passenger. That can be seen as an advantage, because it is tough to link that data to you, but it is possible, and therefore it will occur. You will be found. And when it does occur, you no longer have any easy mechanism to PROVE that the data from your car relates to you. This means that if any government creates a policy to allow you to be forgotten, the car data will not go away. You can’t CLAIM that data because it is not directly linked to you. You don’t own it.
Think this is a minor problem? After all, your city doesn’t have a smart roadway yet, and your car doesn’t send data, so this problem is a long way off, right? Wrong. If we don’t think of this now, privacy will be sacrificed, possibly for decades.
The environment of regulations sets the platform by which companies create their business models. If we create a world where you cannot claim your data, and you cannot manage your data, other people will start claiming your data, and making money. Once that happens, new regulations amount to government “taking money” from a company. The typical government response is to “grandfather” existing practices (or to protect them outright). No chance to change beyond a snail’s pace at that time.
I propose a simple mechanism. Every time you purchase a device on the IoT, you insert an ID into the device. This ID is a globally unique ID (my tech friends call this a GUID) which is essentially a very large random number. You can pick up as many as you want over your lifetime, but I’d suggest getting a new one every month. A simple app can create the GUID and manage them. Every item you purchase during that month gets the ID for that month.
Every bit of data (or Information property) sent by the device to the swarm of companies that will collect and work with this data will get your GUID.
Note that your GUID allows those companies to link your data across devices (your phone, your car, your refrigerator, your ATM card, your medical record, etc). Is this allowed? Perhaps one government or another will say “no” but that control will be easily worked around, so let’s assume that you cannot control this. The thing I want to point out is that this kind of linkage is POSSIBLE now, it’s just more difficult. But difficulty is being overcome at a huge rate with the number of computing devices growing geometrically. Let’s assume that folks can do this NOW and that you will NEVER be able to control it.
Therefore inserting an ID is not giving up control. You don’t have it now.
But it is possible, with the ID, to TAKE control. You will be able to submit a request to a regulated data management company (a category that doesn’t yet exist, but it is possible), then those systems can identify all the data records with your ID, and delete them. Only if you can claim your data can you delete it. By inserting a GUID into your Internet-of-things, you have gained a right… the right to claim your data, and therefore delete it.
It will no longer be a choice of sending a single message to a single search firm like Google. The request to delete will have to go to a broker that will distribute the request, over time, to a swarm of data management companies, to remove data tagged with these IDs.
Now, before anyone complains that a company, once they have data, will never let it go, I would submit that is nonsense. 90% of the value of information comes from samples of that data of less than 2% of the population. In fact, the vast majority of data will be useless, and plenty of companies will be looking for excuses to toss data into the virtual trash bin. If a customer asks to delete data, it costs a micro-cent to do it, but that data is probably clogging things up anyway.
Getting a company to spend the money will probably require regulations from large players like the EU, the USA, China, Japan, Brazil, and India.
Now is the time to ask for these regulations, as the Internet of Things is just getting started. Companies that understand the ability to create and manage these IDs, and respond to the request to delete information, will have a leg up on their competition. Customers will trust these companies more, and the data will be more accurate for consumers of these data services.
You cannot delete “information property” until you can claim it. The ID is the claim.