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.