Aggregated enterprise architecture wisdom
Nick MalikHello Enterprise Architects! If you are seeing this post, you probably have your RSS feed set to my old blog location on the Microsoft site. I have resumed blogging on my own company site: VanguardEA.com The (human readable) location is http://vanguardea.com/inside-architecture Please update your RSS feed to point to: http://vanguardea.com/feed This will give you access…
The title of this post is a bit of advice I first heard many years ago, while working on an Enterprise Architecture review of a troubled software development effort. Never waste a good crisis.
Of course, no crisis is good for the person going through it. Be compassionate. And I’m not talking about a personal crisis like the death of a loved one. I’m talking about a crisis in business, like when a company changes strategy leaving customers out in the cold, or when a new technology simply fails to deliver any value, leaving the champion with less buy-in from his business stakeholders.
These are the little crises of business. It often starts with someone taking a risk that doesn’t produce an hoped-for return. If that someone is a senior leader, and they are smart, they have already collected their bonus or promotion and moved on, so they won’t get the blow-back from their own failure. But just as often, the person who took a risk is still around to get hit with “blame and shame.”
Unhealthy as it is in a corporate environment, blame and shame is common. When something goes wrong, someone takes the fall.
But for an influencer like an Enterprise Architect, a crisis can be a good thing. Why? Because we are change agents. And people won’t change unless they are forced to change. John Kotter, in his book “Leading Change” suggests that one of the greatest obstacles to change is complacency. Change just isn’t urgent enough. He’s completely right, and a crisis is often what is needed to break through complacency.
So a good change agent has a dozen different changes all queued up, ready to go. Well thought out, well planned, well designed changes. Some little, like getting your boss to agree to buy you a new Surface Pro 3, and some big, like a hacker waking up your leadership to the notion data security.
To take advantage of a crisis, you have to be ready. Have your arrows sharpened and sitting in your quiver, ready to go. During a crisis, you may get exactly one shot to propose an idea, and it may not be the moment you expect. There won’t be a “right” time. Just the opportune time. So be prepared.
And when the crisis comes, strike.
On that note, I’m leaving Microsoft.
I’ve had the great pleasure of being part of the Microsoft family for eleven years now. As many of my friends know, I was a dot-com entrepreneur back in the 90’s and had a great run at two start-ups in a row. It was exciting but risky. My children were very small and responsibilities to my family meant that I needed to curtail the risk for a while. So I sought a “safe port in a storm” by joining Microsoft. It served me well. During the doldrum years and all the way into the Great Recession, I rode with Microsoft, pouring my energy into becoming the best Enterprise Architect I could be.
And for the past few years, I’ve been fortunate to be part of Microsoft Consulting, while the company experimented with providing Enterprise Architecture as a consulting program. The ESP program has been through many lives in the past few years, and it is still “figuring itself out”, especially with the new “Devices and Services” world Microsoft has chosen for itself. I’ve met some of the smartest, most amazing architects, project leaders, and yes, even sales professionals while working inside Microsoft Consulting, and I’ve learned a great deal.
But it’s time. The economy is back. Enterprise Architecture is on the rise, and I see opportunities to provide Enterprise Architecture service that are outside of Microsoft’s strategic focus.
So I’m moving on to create my own Enterprise Architecture practice as a compliment to Microsoft Consulting. I am applying to become a Microsoft Partner, and will work happily with Microsoft customers, but I’ll no longer be limited to working solely in the Microsoft model. I’ll be looking for other architects willing to take this journey with me.
Moreover, as many of you know, Enterprise Architecture is of tremendous value in companies that don’t have strong IT strategy and planning DNA. These can be very large companies that are not IT focused, like transportation companies or retailers, or midsized companies that have never really gotten hold of the concept of strategic planning. It can even include start-up firms that need to spend wisely and move quickly. These players are an excellent market for a Vanguard EA, and I’m going for it with an established business and technical architecture process.
So if you wish to continue to follow me, reach out and connect with me on LinkedIn. http://linkedin.com/in/nickmalik
I will continue blogging on a new platform as soon as I get things set up. If I’m able, I’ll bring across the EA-specific articles from this blog to that site as well.
It’s been a good run, but I’m awake from my own complacency, and I’m not going to waste a good crisis.
The title of this post is a bit of advice I first heard many years ago, while working on an Enterprise Architecture review of a troubled software development effort. Never waste a good crisis. Of course, no crisis is good for the person going through it. Be compassionate. And I’m not talking about a personal…
Sometimes, Enterprise Architecture efforts fail. This is no surprise to folks in the EA business. This failure occurred slowly, back in 2007 and 2008. But it did occur. It took me a while to realize it.
I had developed a method useful for Application Portfolio Management as well as for Service Oriented Architecture called “Solution Domains”. The method is good. It’s a framework and taxonomy for high level descriptions of software so that generalized services can be created AND so that the portfolio of applications can be rationalized.
The method is good. But I failed to position it’s use in the appropriate enterprise program in the appropriate way. I failed. Not the method. Where we used the method, it worked brilliantly.
I’ve learned from my mistakes, but being unwilling to let a good thing go to waste, I’m sharing the Solution Domain taxonomy with the world. It’s not patentable (I tried). It is useful, however, because it is a part of a business method that supports Application Portfolio Management in a completely technology agnostic manner as well as Middle-Out SOA.
I’ve put the entire taxonomy on my Enterprise Business Motivation Model site at: http://motivationmodel.com/wp/application-portfolio-management-and-solution-domains/
I may return here, at some point, and provide further details on how it can be effectively used. For now, back to work!
Sometimes, Enterprise Architecture efforts fail. This is no surprise to folks in the EA business. This failure occurred slowly, back in 2007 and 2008. But it did occur. It took me a while to realize it. I had developed a method useful for Application Portfolio Management as well as for Service Oriented Architecture called “Solution…
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.
Your thoughts?
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…
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 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…
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.
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.
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…
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 …