Does Academic Sloppiness Hurt EA?

There are surprisingly few researchers publishing articles about Enterprise Architecture from universities.  Even well considered programs like Penn State and MIT may only publish four or five papers a year.  Therefore, when a single researcher (a doctoral candidate at a well regarded university) publishes no fewer than fourteen separate papers on Enterprise Architecture over the course of three years, a few directly through the British Computer Society website, folks like me notice.

Unfortunately, as this article will show, this researcher appears to be building a body of sloppy work that he promotes widely, potentially harming both the profession of Enterprise Architecture and the reputation of the British Computer Society for promoting him.

(more…)

By | March 28th, 2017|Enterprise Architecture|0 Comments

Self Organizing Enterprise Architecture

Our language can limit us.  Our words can prevent us from thinking about our world in a clear way.  This article is about freedom from our own words.  Read at your own risk.

(more…)

By | February 27th, 2017|Enterprise Architecture|2 Comments

The Capability Instance – can capabilities be realized?

Bizbok 5.5 from the Business Architecture Guild mentions an interesting concept that I’d like to discuss here: the capability instance.  I’d like to caution that this description is a concept rife with conflicts.  I’ll explain in a moment.

For those of you who don’t have a copy of the Bizbok 5.5, first off, get one.  But for the sake of expediency, the description I’m referencing comes from section 2.2.  in a subsection titled “The Capability Instance”

“As a rule, capabilities exist in multiple business units and enable multiple value streams and value stream stages.  As a result, a useful concept called a “capability instance” has emerged that allows practitioners to associate unique attributes, such as effectiveness or automation levels, with specific instances of a given capability in practice.  A capability instance is defined as “a specific realization of a capability, as it exists or is envisioned to exist, in the context of a given business unit, value stream, or other situational context.”  In practice, identifying capability instances provides the business architecture practitioner and consumer with flexibility to assign unique heat map values and other ratings to a capability based on its effectiveness or impact within a given business unit or value stream.”

OK… so why my concern?

Almost a decade ago, I set out inside Microsoft to stop the raging debate about the definition of capabilities.  At the time, our business architecture team was using the concept of capabilities derived from the Microsoft Motion framework (very much like the definition used by the Business Architecture Guild today) as composed of People, Process, and Tools.  (We added “Information”).  However, the Business Process Innovation team was busy creating certifications for Six Sigma that describe processes as having people (in roles) and tools under the activities.  They saw no value in the concept of a capability at all.  I got my Six Sigma Green Belt and saw the problem.  Their use of language was sufficiently different from the words used by Enterprise Architecture that our two teams were creating problems for one another.

During this time, I blogged rather extensively on the difficulty of aligning these concepts.  I went back to source materials from such thought leaders as Michael Hammer and Michael Porter and held lengthy conversations with teams involved in business process management as well as business architecture.

The results, which I presented at the BPM conference at Stevens Institute of Technology, was that we could bring together business process management and business architecture if we recognized one very important principle: a business capability is a concept.  It cannot be realized.  A business process is a conceptual description of a realizable set of activities.  A process description is only interesting once the process is realized.  They are different in the ability to realize them.

A business capability is a concept.  It cannot be realized.

In that frame of mind, when I discuss measurement of a capability, I measure the maturity of the constituent elements.  I measure the people, the processes, the tools, and the information independently.  The capability measurement, if used, is a score of these four individual elements.

(Bizbok uses different framing: they now view a capability as composed of Organization, Value Streams, Resources, and Information, a distinction that I’m stepping over for now… a deeper discussion for a different blog post).

The point is that the notion that you are measuring the effectiveness of a capability is silly.  You are measuring the effectiveness of a business process.  You are using the concept of a capability to allow you to compare completely distinct business processes that have similar impacts on the organization.

The moment you cross the line and allow yourself to view a capability as something that can have an instance, you also cross the line between “what” a business does, and “how” a business does it.  The value proposition of the business capability concept collapses if you cross that line.

I soundly reject the notion of a capability instance as a mechanism to measure and apply attributes that belong in the world of business process measurement and management.  If there are other uses of the capability instance concept, I’m open to them.

Note that it is OK to create a score of a capability in a specific instance.  Is that a measure of a capability instance?  In a way, yes.  For example: the score of an accounts payable capability in customer refund handling is distinct from the score of an accounts payable capability in vendor management.  By comparing these scores, am I measuring the effectiveness of a capability instance?  No.  That’s a measure for the underlying process.  It’s a carful distinction.

Make the distinction.

By | February 24th, 2017|Enterprise Architecture|2 Comments

The concept of the “Nearest Common Manager” in Enterprise Architecture

I’m going to share a secret.  Something that no one talks about, but is critical to understand if you are to be an effective Enterprise Architect.  Are you ready?

People do what you pay them to do.

What a letdown.  Everyone knows that, right?

But we don’t talk about it because it is an assumption of every day work.  Those assumptions drive a great deal of behavior in an enterprise.  In Enterprise Architecture, we must think about the assumptions, because assumptions can stop progress without anyone realizing it.  Assumptions can impede communications.  Assumptions can cause good behaviors to be punished and bad behaviors to be rewarded.

So let’s look at this assumption a little more closely.  Who pays you?  Well, the guy or gal who can fire you if you don’t perform, that’s the person who pays you.  So, if your manager says “run every decision past me,” you are going to run every decision past the boss.  You are doing what you are paid to do.

This creates a hierarchy in an organization that is persistent and rather absolute, especially if you can be blamed.  No one will defy their manager’s manager.  On the flip side, if you are an individual contributor, you have no idea if you are doing what the CEO wants.  Only your manager tells you what to do.

How does this affect Enterprise Architecture?

EA’s are often called to work “across silos” or to collaborate with different groups.  There is no single manager that everyone in your “virtual team” reports to.  You cannot go to a single manager and ask him or her to support your efforts.

One concept that you should be aware of is the “Nearest Common Manager.”  This is the lowest ranked person that everyone on your virtual team ultimately reports to.  In many companies where I have worked, the nearest common manager is the CEO.

The thing that you should be aware of: whoever the nearest common manager (NCM) is, someone who is in communication with the NCM has to have your back… someone who the NCM knows and trusts has to know what you are up to, and has to agree with it.

When you hear the term “executive support,” this is what we mean.  Someone who can provide the air-cover that you will need with the nearest common manager.

 

By | December 16th, 2016|Enterprise Architecture|1 Comment

Translating business capability maps into business impact

Creating a business capability map is just part of the challenge businesses and chief information offices face. Taking the information in the map and making it work and translate into real, tangible business impact can often present far more obstacles than the development of the map itself but without this crucial step the benefits of undertaking the task of creating a business capability map are generally lost. (more…)

By | December 15th, 2016|Newsletter|0 Comments

Does Business Architecture Start With Value Chains?

Creating value chains can be integral part of decision-making thanks to their ability to illustrate how a firm is delivering a valuable product or service to market. A value chain can support other decision tools and benefit competitive strategies with the additional information they supply. (more…)

By | December 14th, 2016|Newsletter|0 Comments

The Repository Won’t Save EA

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.

By | December 8th, 2016|Enterprise Architecture|1 Comment

Disruption – why you need business 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.

 

By | November 30th, 2016|Enterprise Architecture|0 Comments

The European EABOK and Enterprise Architecture Pattern Catalog

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…)

By | September 24th, 2016|Enterprise Architecture|1 Comment

Defining Your Value Proposition

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]

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

By | September 13th, 2016|Enterprise Architecture|0 Comments