//December

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

By |2016-12-16T10:05:24+00:00December 16th, 2016|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.

 

Translating business capability maps into business impact

By |2016-12-15T08:53:36+00:00December 15th, 2016|Newsletter|

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

Does Business Architecture Start With Value Chains?

By |2016-12-14T20:58:26+00:00December 14th, 2016|Newsletter|

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

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.