Home > EA > EA value… where are thou?! [ Part 1 – Mission ]

EA value… where are thou?! [ Part 1 – Mission ]

I really, really wonder if there’s any other job that has such difficulties justifying its existence. Recently, I tried to explain to my parents that I do something where I earn about 8 times more than they do and where I spend up to say 40% of the effort on just explaining others what the hell I am actually doing, what it is good for and why should anybody need it.

Well, sometimes I am wondering too. Although I’ve been doing EA for quite some time now and in various companies, I am still not 100% sure that what I do make sense and really adds some value.

But recently, we had an interesting discussion in the office with my fellows. Since then I am getting more and more robust picture about the ultimate vision, mission and goals of EA. So I want to publish it here to let you question that picture and let me feel desperate again:)

The discussion we had (and which have lasted for some months already) ended up in discussing the mission of enterprise architecture. Here we understand mission as defined in Business Motivation Model of OMG. Put simply, mission is for us something we strive to deliver every day, day by day. I admit that a particular EA mission depends pretty much on each and every company, its maturity, organizational position of the department and much more. Nevertheless, as I went through many flavours of the job, I feel quite comfortable with the following mission statement which we put together as one of the key services provided by enterprise architects:

EA Mission: “Provide relevant information for management to make decisions on effective enterprise change”

It still might sound quite abstract, I am much clearer in what I want we aim for with this statement. One reason is that we managed to avoid fuzzy terms (which – frankly – we use quite a lot, at least in my experience) such as “support”, “improve”, “help”, “facilitate”, “mediate”, “align”, “big picture”…

Now let’s break down the statement a bit:

  • Provide – means clearly “to deliver”, no excuse there.
  • Relevant – is on one hand tricky, on the other hand very strong term. Even if we sometimes feel there’s little information available, there’s usually more than enough evidence. The trick is in identifying and collecting information that is related to the issue at hand, drawing conclusions based on facts, putting information in context and distilling just the information that makes difference for a decision maker. The information should be meaningful, useful, unbiased and – of course – in timely manner.
  • Information – this can be basically any sort of information – facts, estimations, assessments, evaluations, outlooks, scenarios, risks, consequences, lessons learned, best practices, cases from the industry and other industries, experience from peers, conferences etc.
  • Management – this is any sort of decision maker, person or a body. By this we are making clear, who is the customer. This however does not mean, that there are no other parties involved that either collaborate or only supply bits of information. This also does not mean, that other parties do not or can not benefit from this information.
  • Effective – eventually it is still up to the decision maker to consider all available information and decide for a course of action (aka “change”). Here we hope that the information is used to make “the right” decision.

It is as simple as that. Now, you might argue that we actually do far more than that (at least we argued:), for example:

  • we provide processes (to govern architecture…)
  • we provide tools (to input and manage information…)
  • we provide structures (to understand problems better, to structure the information for easier management…)
  • we provide communication “vehicles” (discussion boards for sharing information, know how, best practices…)

I tend to see these know differently. I see all these “things” as internal EA tools to keep up with the promised mission. Sometimes we need processes to have in place to ensure that certain information is available (e.g. maintenance costs per component, KPIs, number of changes, number of implemented requirements…), we use tools, which we might provide to others to ease input and management of information (e.g. to application owners to maintain application information) and so on.

I see two major mistakes which we made (by we I mean our team and also teams I worked in before).

1.) We tried to understand all those parties we worked with as potential customer, and we tried to sell them benefits which they might have out of our work. The reason why we basically always failed (although we tried to see it from the bright side) is that most of those people are clearly NOT our customers. At most, they might be beneficiaries. Take application owners as an example. If they could choose between having a fancy tool for filling in information that EA (or somebody else) needs or not having to fill in any information, guess what they would pick?

2.) We have a tendency to market our internal means which we use or implement to achieve our goals instead of the goals themselves. Naturally, with our hunger after real, tangible deliverables we are being led astray easily and we uncover and market what’s under the hood. And by that we confuse our real customers which might rightfully question the real value of those means. Thinking in an analogy, I feel like a company building houses which instead of marketing the houses and their quality would point out to all those things they do behind the scenes, such as moving materials from here to there, shopping for tools, planning workforce etc.

I wonder how you feel about the mission statement. Would you identify yourself with the content? Or do you have completely different experience? Any feedback is appreciated.

Note: Credits for these thoughts go also to Gerold Kathan & Nenad Antic, thanks guys.

Categories: EA
  1. March 20, 2011 at 10:07 pm

    Hi Ondrej,

    In my view, a mission statement plays two roles: It creates context for other people in the organization to understand the particular approach your team is taking in order to deliver in it’s mission, and it motivates the team itself to insure that it’s activities are producing value in that specific way.

    You have created a good mission statement, but I believe it could be a little better.

    a) in an organization, it is important for the mission statement to say “we are different than anyone else.” You must differentiate yourself, or it is easy to lose engagement. If, for example, two teams can deliver the value, can a customer simply choose one over the other? Will they choose EA?

    To that criticism, your mission statement doesn’t differentiate. There are a great many organizations that deliver relevant information to leaders. Why should they pick EA? What do you do uniquely well?

    b) In alignment, I find myself sometimes pointing to an organization’s mission statement in order to explain my reasoning. “You (team1) should take on this responsibility (that you don’t want) because your unique mission statement positions you to do it. You cannot say you want that mission statement but turn away this responsibility!” It’s a reality. Often works too. Does your EA mission statement take a position that the enterprise “sees” the responsibilities that they MUST take on? I don’t see it.

    c) When I’m working with a department, they may be tempted to “add” a capability to their team because it is convenient, or they have staff that understand it, or no one else seems to want it. That leads to complexity in the short run, but as an EA, I have to ask “should they own it in the long run?” I use the mission statement of that department and ask their people, “does that responsibility belong here?” If you are an EA, someone should be able to come to you and ask “should (responsibility ABC) belong in your team?” Can you say “no” based on your mission statement? If you cannot, your statement needs to be improved. If you can say “no,” then your team has the guidance it needs to perform. Give the EA team guiderails… what should they avoid doing?

    Good luck in your efforts.

    — Nick

    • March 21, 2011 at 9:22 am

      Hi Nick,

      the criticism is appropriate and constructive, thanks for that. We are also very well aware of the fact, that the mission statement is nicely “right”, but also that general, that it can be only hardly “wrong”:) What I like about it is less fuzzy statements. In other words, I know exactly what’s that statement commanding me to do. What I dislike is the scope. That’s our next challenge. Not that much to write it down, but do identify more crispy the domain/aspect in which we exclusively operate.

      In that regard, when I think about it, I have written the statement without one important fact from our context. I think I’ll need to write more about it in a special post, but for now at least a brief summary. As we’ve been setting up an EA team, we have observed how differently people understand what EA is (how surprising!). This spans EA as a concrete architecture, usually scoped down to whole IT, a role name for smarter architects, ivory tower strategists and lot more. Then, while trying to keep up to the real meaning of Enterprise Architecture, we realized that there’s much more people that actually really architect the enterprise, while we – the EA team – helps at most with facilitating mutual interactions, finding gaps (in alignment, responsibilities, communication etc.). That means that we are quite happy to add an EA role to our C-levels, directors, Productivity managers, organization developers, process guys and many others. As they all form something that could be called EA discipline. But more on that in upcoming post.

      One more important comment: it’s obvious that for EA one size does not fit all. There are different expectations towards EA teams and from what you can see around, they are pretty different. Clear expectation from our team is “to provide long-term overall perspective on current architectural matters”. In other words, don’t focus that much on how our to-be state is going to look like and how to enforce it (very often a case for many EAs), but rather with all you know and see going on in the company make judgment on what the consequences and risks might be when we make a decision for a certain solution. Sounds too much IT? Yes, a bit. That’s where our input is expected. But the expected input is not in terms of “is the architecture nice and do we like it?”. It’s in terms that directors and C-level can understand: Are we compliant? Can we lose a market? How much “technical debt” do we take on? How much complexity do we need to tackle with? What does it mean for our future growth? What does it mean for sustaining our business? What does it mean for organization/employees?

      In the past I experienced more the attitude/expectation of C-levels that says “Make my wish happen” with tiny letters below saying “without funding, authority or support”. Sorry, we are out of magic today:)

      Well, that’s the way the cookie crumbles. Have a nice day.

    • March 25, 2011 at 4:14 pm

      The promised post is here.

  2. March 20, 2011 at 10:50 pm

    Hi Ondrej,

    I like your mission statement for a couple of reasons. Firstly it does avoid fluffy meaningless terms that cannot be cashed out in practical measures as much as possible (I too have a dread of most of the terms you mention, such as “align”, “support” etc.). Secondly, it focuses on change which I think is an under-appreciated part of EA. There really is little need for Enterprise Architecture if your enterprise isn’t involved in some form of change – either business change (so EA helps change things such as IT systems so that they are effective in the new business situation), or technology change (for instance where obsolete technologies are upgraded, and here EA ensures that the new technologies don’t disrupt existing business). One important thing that I think you should have added is a statement about assisting the same management on executing on the decisions that they have made. What do you think?

    • March 21, 2011 at 9:31 am

      Thanks Doug,

      I’ll take that one on board for discussion. I think you are right. What form of “assistance” do you have in mind? This can vary a lot company to company. Three major forms of “assistance” I can think of now is governance – process-wise approach to transparency; QA – “watch-dog” style of making sure what we want really happens, and reviewing – ex-post chceck of what was delivered and in what quality. But I can imagine also active project management role taken on by EAs.


      • March 29, 2011 at 9:19 am

        Hi Ondrej,

        Governance is one key form of assistance. Developing key parts of the IT architecture for other architects, tech leads and designers to leverage is another. Communicating the vision, goals and desires of those decision-makers to technical staff in terms they can understand is another, as is acting as a go-between when technical staff have questions and concerns. In short making it happen, and making sure that what happens is right, and delivers on that “promise” inherent in that decision.

      • March 29, 2011 at 9:25 am

        Thanks Doug, I like your concise comment.

  3. April 1, 2011 at 6:13 pm

    “EA Mission: “Provide relevant information for management to make decisions on effective enterprise change””


  4. May 30, 2011 at 2:31 pm

    Hi Ondrej, I enjoyed your post and the subsequent discussion. Thanks, Anthony

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: