The Enterprise Partner Supplier Customer (EPSC) Model sits as a core concept of Enterprise Architecture. It is so much at the core of everything we do that we seldom question it. Is that healthy? This post will discuss the core idea behind the EPSC model (differentiation by control) and alternative ways to think about enterprise boundaries.
First off, we only name things when we want to differentiate them. As the old expression goes, “the fish discovers water last.” In EA, we tend not to discuss the fact that we assume a particular model of enterprise identification and enumeration on a regular basis. That’s because the model is built in to the things we say and do. It’s built in to our business models and our service models. It’s built in to the way enterprises create policies and budgets and govern efforts. It’s so deeply ingrained that we rarely question it. Well, it’s time for this fish to discuss the nature of water. And to do that, we have to name it. I’m naming it the EPSC model, which is an acronym for “"Enterprise Partner Supplier Customer”. It looks like this:
The view that an enterprise is a bounded thing, with suppliers feeding in, customers getting the benefits, and partners in a peer-to-peer relationship… that’s the EPSC model.
The underlying assumption of EPSC is control. In this model, there is typically OWNERSHIP CONTROL over the enterprise. “Ownership control” means the same people OWN an influential number of shares in each of the organizations inside the box. That is not necessarily controlling interest. It is sufficient interest to ensure that the all the businesses inside the box get along well with each other. It works because employees do what their bosses tell them to do. Take that fundamental notion and expand it to the enterprise level and you get the assumption of ownership control.
Another form of control is ECONOMIC CONTROL which is typically the case when there is a huge size disparity between the suppliers and the enterprise itself with respect to the end customers. This happens in retail a great deal. Walmart is a textbook example of “economic control” since their supply chain requirements can drive massive costs into their suppliers without any substantial backlash. The fundamental model above is the same so I’m not going to redraw it. It’s still EPSC. Just with a really big “E”.
The Internet has introduced some things we expected, and some things we didn’t. We expected the introduction of easy communication and easy transmission of data. What we didn’t expect: the creation of the commercial ecosystem as a differentiating factor in strategy. In other words, the creation of a product by one company that is combined with another product to be consumed by a customer dependent upon both to solve the needs of a customer that is totally unaware of either one. This is common now in the mobile applications space. A mobile app may be created from unique capabilities of four or more companies that are not just peers, they are collaborating peers, all focused on producing the mobile application. Yet the customer is unaware of the grouping.
The EPSC model is completely broken for understanding this space. It simply fails. Because there is no boss telling you what to do. There are only customer opportunities. It is organic and bottom up in its very nature.
And the moment we examine the “more than one” condition, we have to open the door to the possibility that there are more than two or three or ten. How many alternative models are there? I do not know. No one has enumerated them and drawn distinctions (hey, doctoral candidates… want a dissertation idea? Enumerate these).
I will brainstorm a couple of alternatives. This is not a thoughtful investigation of models. It’s a brainstorm. Take it with a grain of salt. But I encourage you to use the ideas to expand your own thinking.
The dynamic collaboration model involves a series of companies that have no common ownership but who collaborate on a very frequent basis to create positive value for customers that is achievable through the combinations of their products.
The key to success in this model is to focus on that dynamic collaboration and to build excellent feedback mechanisms with the customer. This kind of model can fall apart of the customer loses confidence in the collection of companies to meet their needs, and it is vulnerable to attack from alternative collaborative groupings that build better feedback mechanisms.
My knowledge is not wide enough to suggest that I understand other possible models. Perhaps recognizing more than collaborative self interest is necessary to even perceive them. I know that there are more than one, and I’m guessing that there’s more than two. These are the two that I can see. Please post your own ideas and we can collaborate.
What does this matter?
Well, I’d suggest that the strategy of Microsoft under Bill Gates reflected the dynamic collaboration model, but that the strategy under Steve Ballmer reflects the EPSC model. We can see the gradual deterioration of value and innovation during this period. Microsoft under Satya Nadella has shown signs of moving back towards the dynamic collaboration model. Time will tell. He inherited a very weird beast.
But just as important as understanding Microsoft, what does this say about Google, Amazon, Force.com, IBM, Oracle, and the hundreds of other competitors (and open source initiatives) that fill the technology space?
This kind of differentiation is useful for making these kinds of observations.
I guess it shouldn’t surprise me that business strategy work is often about constrained thinking. Thinking “inside the box” is nearly always rewarded well. After all, the person giving the rewards lives in the same box. One of the most pernicious kinds of constrained thinking is “brand thinking.” That is the notion that the value of your existing brand is the starting point for all your products. Living within the box of the brand is definitely constrained thinking.
Brand thinking says “everyone knows us for doing this one thing well, so let’s invest in variations on that thing.” That’s great. And it often works. For example, the Dell computer company has a great reputation for building good (but not wildly innovative) personal computers for individuals. So naturally, when they decided to diversify, they decided that they should build on that brand. They decided to build server computers for businesses. It worked fairly well. As they tried to become more innovative, they had problems with the brand. In some areas, Dell simply bought other brands (Alienware for gaming computers, for example).
On the other hand, brand-thinking also leads to a kind of situational blindness. Essentially, we choose not to see the things we think are outside the brand, or even the market, that we are used to. And in doing so, we nearly always miss opportunities. At least, until our competition points them out to us. Dell was good at electronics manufacturing to the home. Had they looked outside their brand, and focused on their abilities, perhaps in the 1990s, they would have been successful competing with Sony or Sharp for personal electronics. Brand thinking says “no.” They stuck to computing, moving into printers, laptops, and tablets. All have suffered from the “commoditization” of their market.
A strategist is a unique role. To be a successful strategist, you have to do everything you can to resist the boundaries of constrained thinking. But then your ideas have to be judged by people who are PAID based on constrained thinking. And that’s a tough sell.
When we do business capability modeling, we are looking not at the products of a company, or it’s brand, but at what that company can do. We look at what a company has the people to do, the processes to do, the information to do, and the tools or technologies to do. We bring together this knowledge into a complex model of elements, and summarize it as a capability map.
The value of doing this is typically revealed when creating initiatives for the execution of strategy. If a company is doing incremental strategy, there may be one or two areas that have slowed or prevented the company from achieving its goals with respect to its competition. But when a company is following an innovative strategy, there may be a dozen different capabilities that need attention. Some may have to be created from scratch. Capability modeling is a clearly valuable tool in this arena.
However, there is another use for capability modeling that is not often discussed, and that is the need for unconstrained thinking on the part of the strategist.
If you are over the age of 30, and live in a western country, you’ve probably heard of Eastman Kodak. Known for their near monopoly on film and film processing, Kodak was the undisputed king of photography for decades. In 1990, they held 90% market share. They were unbeatable. Remember this logo? It was a very successful brand.
Let’s assume Kodak had done a capability model back in 1990 and had actually paid attention to it. They would not look at their brand or their existing products, but at the things that they do very well. What would be on that list of “things they do well?”
Let’s be clear here. These capabilities were not just solid. They were the best in the world.
What’s not on here? Electronics. Electronics manufacturing. Electronics R&D. Electronics Marketing. Not on the list.
So when Kodak started to see the need to expand, they used brand thinking. People see the brand “Kodak” and think photography. So why not go into the manufacturing of digital cameras?
Do you see anything on that list of capabilities that deals with innovation and manufacturing of digital cameras? Heck, they didn’t make that many analog cameras (Nikon, Olympus, and Canon made most of the analog cameras). They had no distribution network, no reputation, no capabilities, no core skills to make cameras of any kind, and certainly not digital cameras.
Even though they were able to leverage their brand for a while, eventually their ability to sell digital cameras fell away and they lost money. Huge sums. At the same time that their analog film business was also losing money.
Now, look at that list again. What do you see? Ignore the fact that this is a film company. Do you see other things there?
The simplest capability to build is the ability to market to a new segment. The hardest is the ability to do R&D and manufacturing well, so let’s drop the marketing for a moment. Not completely, but let’s focus on the hard stuff. Could they have built products based on treated plastics and treated paper? Almost certainly. There’s an entire industry that makes sheets of plastic film for a wide array of different purposes from glass protection to window tinting. What about chemistry based R&D? Could they have created innovative consumer products to compete with companies like Clorox or Proctor and Gamble? Could they have leveraged their chops in chemistry to compete with companies like 3M? Maybe. But only if they had looked first at their core capabilities.
The important thing to note about these industries is that they have not been disrupted by technology the same way that camera film was. While these industries are not easy to compete in, the ability to leverage existing world-class capabilities is more critical to success than the ability to leverage the brand.
Eastman Kodak thought of themselves in the film and photography business. And it was their downfall. Unfortunately, it still is.
What about this brand? What are their core capabilities? And what can they be doing with those capabilities?
Are they on the precipice of disruption? You bet.
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).