/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".

The Repository Won’t Save EA

By |2016-12-08T19:39:36+00:00December 8th, 2016|Enterprise Architecture|

business-woman-tiredOne thing most Enterprise Architects have in common: frustration with resistance to change.  Channeling the words of some of my friends, frustration sounds like this: “We know many of the answers to common problems in IT, especially in how systems are developed and used, how data is organized and mastered, and how capabilities should produce shared components or systems.  We know many of the answers… but no one listens!”

Yep.  We do work and sometimes, no one uses it.  Or we develop advice, and no one follows it.  Common problem.

For some reason, the “answer” that I’ve heard bandied about is to buy software.  “If we only had a repository for architecture, then people would use our models.”

um – no – not really.

If your models are not used, putting them into a collaborative storage and retrieval system will not get them used.  It will make them more available, but in 85% of the cases, availability is not your problem.  Either no one sees the value in using your models, or they don’t know how to read them, or using your models works against some political aspect of their lives.

It’s not that your stakeholders didn’t know the model was there.  It’s that they don’t care.

Adding a repository won’t make them care.

Your first order of business is to build demand for the architecture models.  Once demand is there, worry about the repository.  Until then, a simple modeling tool will work.

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!