Collaboration without common values is fruitless

By |2009-10-19T18:28:46+00:00October 19th, 2009|Enterprise Architecture|

One thing that any new Enterprise Architect realizes, on or around their first day of work, is that there are not very many other Enterprise Architects in their organization.  It is easy to look around and discover that you are the one and only Enterprise Architect, or part of a very small team.  That doesn’t do much to relieve the pressure, though.  An Enterprise Architect is expected to provide a lot of value, without a lot of direct resources. 

For this reason, a key concern of Enterprise Architecture is “how can I be accountable, and deliver value, without a lot of direct reports?”

This question is easy to answer: Collaborate.  It’s a lot easier to say than do. 

It is not enough for an EA to “want” to collaborate, or even to be “open” to collaboration.  Other roles can make that claim.  The EA has no choice but to “drive” collaboration: to make collaboration happen in situations where your stakeholders may actually be incented to ignore you, disregard you, or outright oppose your very existence.

And there’s the rub.  How does an EA create an environment of collaboration, and mutual interdependency, without wielding a large club?  There are many answers to this question, but the one I want to touch on, right now, is “the appeal to common values.”

Using the Appeal to Common Values

At the end of the day, it is impossible to force another person to do the right thing, especially if you don’t have the right to cause bodily harm :-).  You can appeal to their manager, but that only works when their manager agrees with you.  You can try to use logic, to convince them that your ideas are sound, but that doesn’t mean that they will be motivated to use your ideas. 

One thing that I think is key to success, necessary (but not always sufficient), is an appeal to common values. 

An appeal to common values goes like this:

  1. We both care about doing the right thing for our company.
  2. One aspect of doing the right thing is X (where X is a company value, corporate goal that you both share, or a common recognition of a problem that both of you want to solve).  Let’s both achieve X.
  3. We can achieve X better if we work together than if we are working separately.  We each bring our own requirements to the table.  However, since the end goal is the same, collaboration is better that competition.  (be ready to use measurement, logic, emotion, and/or incentive to back this point up).
  4. You can trust me to defend all of our requirements, and I’d like to trust you in the same way.  I’m trustworthy. 

Appeals to common values are effective because none of these statements is particularly difficult to agree with. 

For example, in Microsoft, we have company values that say that we will take on Bold Challenges.  We also have policies that say things like “use our own technologies where possible to solve our corporate needs.”  I can use both of these together to convince someone to adopt a new technology in an upcoming project, even if it adds some small project risks, because I can tie that activity (“use a new technology”) back to shared values (“use our own stuff” and “bold challenges”).

The fourth item above is probably the biggest part of the “appeal to common values.”  If we are working together to collaborate, at some level, we must trust one another.  My requirements and your requirements must blend.  We must both be accountable to all of the requirements, and we must both defend the other person’s requirements when our shared solution is challenged.  Otherwise, collaboration is a farce. 

This is sometimes overlooked, but without trust, an appeal to common values may produce no fruit.  On the other hand, without common values, collaboration can be difficult, or impossible, to achieve. 

The most difficult things

By |2009-10-13T21:42:05+00:00October 13th, 2009|Enterprise Architecture|

The single hardest thing to get a
person to do, is think.

If you can get a person to think, the next most difficult thing to get them to do is change.

Therefore, if you want people to change,
don’t ask them to think.

My father used to tell me, “You have two choices: getting someone to think, or getting someone to change.  Asking for both is asking for the moon.”  My father had a good bit of experience with both… he was a college professor.  A good one at that.

Of course, a college professor can consider himself successful if he gets someone to think.  Not so much for an Enterprise Architect.  We have to be able to go either way.  Sometimes, it is the job of an EA to get someone to think.  Other times, it is our job to get someone to change.

Thinking is tough.  If you show a business leader that a particular counter-intuitive action is a direct result of their own strategies, they will have to think about it… or just trust you.  That is the advantage of being a trusted advisor.  If the business leader trusts you, he can take the easy way out.  He won’t have to think, because you’ve shown him that you can be trusted. 

Change is tough.  In many organizations, Enterprise Architecture is not well integrated into normal planning and alignment processes.  You may have to ask people to perform tasks in a different order or to use a different set of inputs than they are used to.  You are asking them to change. 

The key here is not to also ask them to think.  Plan out the steps and walk them through those steps.  Show them how to do the “new” work.  Help them to understand why the “new” work is more valuable than the old work through any of a dozen different techniques (reference wins, emotional appeal, hope, common values, support for shared goals).  You aren’t asking them to develop the new process. That would require thinking.  You are asking them to do, not think, and giving them the steps.

Thinking or changing… pick one.  As an EA, know what you are asking for.

The Value of Enterprise Architecture

By |2009-10-03T13:10:09+00:00October 3rd, 2009|Enterprise Architecture|

“Waiter, Waiter!”

The customer sat in the corner of the busy cafe, with a seaming bowl of soup, frantically waving to the retreating waiter who had just set the bowl down and hurried away.  Frustrated, he turned, but did not advance.

“What is it, sir?”

“Waiter, try this soup,” the customer replied.

Curious, he walked back to the table.  “What is wrong with it.”

“Just try the soup.”

“Sir, is there a problem?” the waiter impatiently insisted, looking over his shoulder at the other tables.

“Just try the soup,” the customer repeated.  A few seconds of silence passed.  The waiter considered his options. 

“OK, sir.  I’ll try it.”  The waiter looked around the table.  “Where’s the spoon?”

“A-haaaaaa” noted the customer. 

I spent about two hours yesterday in a conference call with the Enterprise Architecture team of a large financial institution, one of the many fringe benefits of this job.  I shared some details about our EA practices and they shared theirs.  It was an opportunity for me to speak with peers, share ideas, compare practices, and such.  (Special thanks to their Microsoft Account Manager for setting up the conference call). 

One question that came up, that in fact often comes up, is “how do you convince senior business leaders of the value of Enterprise Architecture?

My answer: I don’t.  Enterprise Architecture, the function, is not valuable by itself. 

Enterprise Architecture is valuable because of the data that EA collects, and the reports that EA makes available to senior leaders. Allow me to repeat, it’s all about the data.

Business leaders don’t need Enterprise Architects to stand around acting smart.  They need data, reports, and analysis.  The Enterprise Architect is essential to interpret that data, and help them to understand the value of the using the information to make decisions. 

So, if I have a business leader who does want data, I start there.  I collect a little data and show it to her, and whet her appetite.  I ask what questions she wants answered (“Which processes drive the most cost to my department?” or “How much of my budget, last year, was actually spent on going after my priority strategies?”).  Then, get the subset of EA data needed to answer that question.  Projects grow from projects, functions from functions.  Data maintenance is expensive, so the reports have to be valuable year after year.

When we see a business leader that doesn’t understand EA, we show the reports we created for other leaders.  It’s all about the data.

To be honest, I don’t want to ever sell the value of EA to a business leader.  I want one business leader to ask another, “where did you get that data,” and have the other reply, “From Enterprise Architecture, of course.”

The system should flow from it’s own success.

If the data is the food, EA is the spoon.