/Nick Malik

About Nick Malik

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

Disruption – why you need business architecture

By |2016-11-30T04:34:11+00:00November 30th, 2016|Enterprise Architecture|

Business Architecture is, on occasion, a difficult sell.  In many companies, it can be tough to get senior leaders to give you to remit to use the tools and techniques of business architecture.  This is especially true in organizations that think of Enterprise Architecture as an IT function.  The following video answers the question “Why do we need Business Architecture?”

Your feedback is encouraged.

 

The European EABOK and Enterprise Architecture Pattern Catalog

By |2016-10-19T20:36:47+00:00September 24th, 2016|Enterprise Architecture|

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.

(more…)

Defining Your Value Proposition

By |2016-10-20T04:08:55+00:00September 13th, 2016|Enterprise Architecture|

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][one_full last=”yes” spacing=”no” center_content=”no” hide_on_mobile=”no” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” hover_type=”none” link=”” border_position=”all” border_size=”0px” border_color=”” border_style=”solid” padding=”” margin_top=”” margin_bottom=”” animation_type=”0″ animation_direction=”down” animation_speed=”0.1″ animation_offset=”” class=”” id=””]

Elbonia Air Stakeholder Required Value / Value Proposition
Government owner
  • Reliable service to remote areas of the country
  • Hire citizens to do the work – limit outsourcing
  • Don’t lose money
  • Keep ticket prices low
  • Keep borrowing and debt in check and in alignment with the private sector
Private Investor
  • Lower risk investment due to government backing
  • Reasonable return on investment / dividends
Customer
  • Reliable, comfortable, safe services
  • Similar customer experience to competitors
  • Low ticket prices
  • Convenient travel times
  • Desirable destinations
Partner
  • Dependable relationships and agreements
  • Reliable payment for services
Employee
  • Empowered opportunities to contribute
  • Reasonable opportunities for advancement
  • Fair market wages
  • Safe and comfortable working conditions

[/one_full]
Typically, the biggest problem for a commercial organization is the difference in requirements between the investors and the customers.  For some companies, there can be a huge difference, with the investors driving for revenues that cause the customer satisfaction to fall dramatically (such as checking account fees at your local bank).  For an airline, “fuel surcharge fees” are similarly problematic as they are usually seen as an attempt by the airline to make the ticket prices look lower than they are.

The biggest challenge to this particular business model, however, is the difference in value proposition between the perspectives of the two chief types of investors: the government investor and the commercial investor.  The value of a national airline to it’s country government is very different from the value of the stock to a commercial investor.

It is the delicate balancing act between these two kinds of investors that got the government airline in trouble in the first place.  The airline had taken on debt because they had expanded service to a number of smaller destinations that are primarily appealing to foreign tourists.  Those services were created to provide subsidies for unprofitable routes that the government demanded, and to keep ticket prices low on the unprofitable routes.  However, the recession had caused the new tourist routes to become unprofitable.

The airline simply owned too many aircraft for the profitable routes they had, had no flexibility to drop unprofitable routes, and competition from other commercial airlines was keeping down ticket prices.

How did they solve the problem?  By changing the relationship with the government.  The government became a partner, not just an investor, in particular routes.  That allowed the government to subsidize those routes and get out of the business of caring about the overall airline.  The main commercial routes were expected to be competitive and profitable while the “required” routes were subsidized so that they wouldn’t lose money.

All this was visible by examining the value proposition as an independent element of the business model.  Simply doing a “SWOT” analysis wouldn’t have focused leadership on this kind of problem, or this kind of solution.

Enterprise Architecture and Threat Modeling

By |2016-11-28T21:14:48+00:00August 29th, 2016|Enterprise Architecture|

What should an Enterprise Architect know about threat modeling?

I recently asked on a LinkedIn group about threat modeling and Enterprise Architecture. My first surprise came when the first set of responses were from folks who didn’t appear to understand what threat modeling was. So I guess the first order of business for anyone wishing to consider themselves an Enterprise Architect is to study up on what Threat modeling is.

(more…)

The human element to strategy

By |2016-07-15T23:03:43+00:00July 15th, 2016|Enterprise Architecture|

There is no shortage of business thinkers and authors who will tell us this statement is true:

Anyone can create a good strategy.  The most frequent failure is in execution.

Unfortunately, this underestimates the difficulty in creating a “good strategy.”  While the statement above is absolutely true, it is not unusual to find companies that don’t have a formal strategy at all, or who fail to share their divisional strategies with all of their employees (a key measurement of strategy adoption in a company is “how many of your employees can recite your company strategy”).

One of the obstacles I’ve come to recognize in Enterprise Architecture is unique to companies that either don’t have a formal strategy or who do not share their strategy with their staff — you cannot align efforts to strategy if there is no consistent understanding of strategy across divisions.

I always knew this was true.  I’ve become more and more convinced that it is a hard-and-fast rule.  In other words, if you want to be successful as an EA in a company that doesn’t share strategy, this becomes your First Order Problem — how to develop a consistent strategy that everyone at the senior level agrees with and that they are willing to share with their staff.

That’s it in a nutshell.  To be successful, your organization must develop a consistent strategy that everyone at the senior level agrees with and that they are willing to share with their staff.

First order problem — In other words, focus on this.  Make progress on this.  Measure yourself by your progress on this.  Associate yourself with the people who “should” own this, and align yourself with the people who actually do own this (rarely the same person). Find ways to be involved.  Find ways to contribute. Volunteer.  Make things happen.  Find ways to support incremental progress, while recognizing that the increment may not be good enough in the long run.  For EA to become known for “doing successful Enterprise Architecture,” a clear and communicated company strategy is ground zero.

 

Welcoming Archimate to Enterprise Architecture

By |2016-10-21T09:38:17+00:00June 28th, 2016|Enterprise Architecture|

I’m going to get some heat for that title… I’m sure of it.  Archimate has been a diagramming standard for some elements of Enterprise Technical Architecture for a couple of years now.  However, with the new release of Archimate 3.0, this interesting visual language is now directly useful to Enterprise Architecture from the perspective of a Vanguard EA.

(more…)

Enterprise Architecture in the world of consulting

By |2016-07-10T01:22:37+00:00June 14th, 2016|Enterprise Architecture|

Many years ago, fellow EA consultant and thought leader, Jeff Scott, published an interesting article in CIO magazine that outlined a useful method for applying Enterprise Architecture to an organization. The article was titled “Don’t Just Build Business IT Alignment, Map It!” (linked here).

Unfortunately, I believe, very few people understood it.

I’ll admit that, when he published his article, I was working in an EA team and I didn’t use his advice either.  You see, Jeff was speaking from the viewpoint of a company that wants to provide EA as a consulting service (he was at Forrester at the time).  The advice he gave was less useful for organizations that wanted to provide EA as an internal service.

With your permission, gentle reader, I’ll spend a few minutes describing the difference.

(more…)

Never Waste A Good Crisis

By |2016-08-09T15:12:51+00:00May 16th, 2015|Enterprise Architecture|

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. (more…)

Sharing the Solution Domain Taxonomy

By |2015-04-23T10:17:18+00:00April 23rd, 2015|Enterprise Architecture|

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!

Alternatives to the EPSC Model

By |2016-07-10T00:45:26+00:00February 16th, 2015|Enterprise Architecture|

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:

image

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”.

Why do we need alternative models?

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

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.

image

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.

What other models exist?

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?

  • Oracle seems to play in the EPSC model.  What does that say about the future of Oracle?
  • Amazon clearly plays in the Dynamic collaboration space?  Does that ensure a bright future?  How important are each initiative in Amazon when vi
    ewed in this context?  While delivery to the neighborhood is necessary, are the drones needed?  Or is that just good buzz?
  • Google… plays in both.  (Kind of like Microsoft).  The EPSC model drives their revenue, but there’s a lot of initiatives in the dynamic collaboration space.  Is this an intentional transition, or just opportunism?
  • Facebook is primarily an EPSC business, with a very large base of users.  (See economic control above).  Will they make moves toward dynamic collaboration?  Can they survive if they don’t?

This kind of differentiation is useful for making these kinds of observations.

 

Your thoughts?