What is this “Enterprise Architecture” anyway?
Currently there’s quite heavy discussion on The EA Network about the single largest challenge of EA. Based on all those posts one can easily realize how different perceptions and understandings of EA there are. Well, so far nothing new actually. What I would like to share though is a bit different approach to positioning EA in a company.
Just recently, we started building up an official EA function in our company. In fact, it was largely there already, just not called that way and thus mostly understood by others as some “IT thing” only. With this change we had to shape our responsibilities, offer “services” and evangelize our existence and scope of our activities. In the course of our work we went through many stages of realization what the … this EA thing really is (you know that feeling, right?).
This is what we ended up with. Very wide, very inclusive and collaborative view on EA. EA in its real sense of the whole enterprise and its architecture. We created a poster accompanied with this short story:
1) There’s always an architecture in the company if you like it or not, if you manage it or not, if you are aware of it or not. In many cases unintentional and in many cases limiting. There is an architecture of business, its capabilities, information, processes, organization, people’s roles and responsibilities, there is architecture in IT, infrastructure, our business locations, branches etc.
2.) The company does not live in a bubble, there’s outer world which influences us heavily, let it be our customers, competition, suppliers, society and its perception and much more. This all we mean be Enterprise.
3.) For us the Enterprise Architecture is a holistic discipline involving many roles, leveraging information, processes and tools to decide where the company intends to go, what needs to be done to get there, how and when it should be done and then governing and managing the change in daily business towards the goals and company vision.
4.) We are all somehow related to EA, either directly on decision-making level, or indirectly via responsible persons. There’s nobody who would not be influenced on one hand and who could not influence it on the other.
5.) Purpose of the EA function in the company is to support and facilitate intentional enterprise architecture. To be more concrete: e.g. to identify current and future gaps, mis-alignment, risks, opportunities among different verticals, domains, units, people, between business and IT and so forth. Moderating discussions, bringing out transparency, clarity and commitment to carry out the change while manoeuvring through varying personal interests, viewpoints, beliefs, politics, culture… Assisting in creation of sound strategy and communicating this across the company, understanding and being able to talk different lingo.
The bottom line is: EA as a role/function is not the one doing EA, it is the one helping EA to be done by others in an efficient and effective way.
Opinions?
P.S. This is not the RIGHT way. It’s just A way. One of many currently out there.
Note: Credits for this work go also to Gerold ‘Cactus’ Kathan and Nenad Antic.
Enterprise Architect's World 
Excellent post, Ondrej. Diagram is good. I wonder if you have a “public” mission statement and then an “effective” mission statement… the effective one being: “Purpose of the EA function in the company is to support and facilitate intentional enterprise architecture”
That is specific, unique, and clearly bounded. It is actionable, motivational, and helps others see your role.
I get it, by the way. Our mission statement is just as generic. Our EA Mission: To accelerate the transformation of [our enterprise], IT’s value to the business and the business’ leadership position in the market.
I can hardly argue that your mission statement is generic when ours is no better. That said, your thinking in this post is excellent, and I appreciate you sharing it with the community.
100% agree.
Thanks, great diagram, succinct definitions
Hi Ondrej,
First of all thanks for the rather good blog post. But I keep feeling like that a question has to be answered in order to understand what “architecture” is the context you put it.
Is architecture a tool or a goal? I see it as a tool or a form of method to achieve a particular “beneficial” competitive situation. The diagram that you have produced doesn’t show if the architecture itself changes over time and I believe that is fatal flaw in order to obtain an understanding of what “EA” is.
Likewise is the diagram a process or is it blueprinting? How is Enterprise “coherence” achieved and how does the various stakeholders comply to the changes that the EA approach will bring with it?
Nonetheless I think it is a great diagram and I wish you the best with establish the EA function.
Best regards,
Peter Flemming Teunissen Sjoelin
CoherencyArchitect.com
Hi Peter,
you’re touching many points, so obviously the diagram made you think more about it. I am glad. It helps me to see what state of mind the picture creates. I can see that it opens more questions than it answers. That’s perhaps good and I’ll try to answer yours. But before that I have to clarify the purpose of the diagram. It was created to pass on one key message. EA role is not the center of the Universe. EA is also not solely about smart people, or solely about models, or solely about process. It’s all together.
Now to your points. I sometimes find it much easier to explain what EA is then what architecture is. When does it become “design”? And is there any difference at all (when you check wiki you find that one is defined using the other and vice versa)? And when it’s just an implementation? Architecture is a term which I took for granted for a long time but now I am more and more getting to the ground zero realizing varying understanding (understanding is perhaps just too strong word, “glimmer” would fit better here). Nevertheless, my standpoint regarding what is architecture was clear to me and it was expressed the best by Leonard Fehskens here. Roughly quoted: “Architecture defines a class of acceptable solutions that address some goal, need, problem… an architecture must express the essential characteristics that define membership in that class”. And as a practical exercise he poses a question “What makes a chair a chair?”.
Is architecture a tool or a goal? These are to me two different things and architecture is for me both. It’s a tool (I would prefer calling it means) to ends, where ends define the purpose of architecture. And particular architecture can be a goal in order to be able to reach the ends. This is why we use to think of a to-be or target architecture. In this sense it’s a goal, although overall the architecture on its own is good for nothing, it’s just means to an end.
I also implicitly assumed that architecture changes over time, I see no reason it should not or what would inhibit its change. All in all, it’s the primary purpose of most EAs to drive change [of architecture]. So I didn’t get that one, really.
Also the diagram itself is neither a process nor a blueprint. It’s just a picture which tries to send a message, tell a story. Was the question if in the function itself we create processes or blueprints? If so, then the answer is yes, both. And models and other artefacts as well.
Thanks again for input.
cheers
Hi Ondrej,
I really like this post and how you have described your role. It describes what I think EA should or could be, but in my experience – here in NZ – it rarely is. My question is: how much buy in have you had from the rest of the organisation to this wider vision of EA? Does the business still think that EA is just “some IT thing”, or have they accepted your approach?
Cheers,
Doug
Well, this poster and the story not that much, in fact:) I mean, it helped us to ground the notion of EA better, that’s for sure. But it’s just one piece of the puzzle.
First of all, it’s not really supposed to be used for communication to managers. They are from a different planet. This is for people that have time to listen to the story.
Second of all, it still does not say what we actually do. So for most people it remains intangible what we do anyway. They just know very very very roughly that it’s kind of related to “everything” and how they are related to the term EA.
For business I would say that already the term architecture is taboo. So as long as architecture is in the role name, I guess it will be always perceived as some techie thing. No wonder. We do see architecture (structure & relationships) in everything, so naturally in business as well. But when you read MBA or similar business books and dive into “their” world I bet you won’t find a single usage of that word there. So I do not blame them for not getting it. I also heavily try not to bother them with that role name or this poster. I try to use solely lingo they understand. I try to pick analogies or examples from different businesses, finance or so to pass the message. When I talk about particular solution architecture with business then I do my best to use terms they understand, capabilities they use, opportunities they see, consequences they can feel. That’s perhaps what makes them listen and think when you can prove that you not only claim to do enterprise architecture, but you also really understand their realm and can professional discuss their matters.
For managers I believe we earned a little bit of our reputation not with this poster or mission statement or anything of that sort, but real deliverables which they appreciate. In our case merger scenarios, roadmaps, assessment of alternatives where wide overview of matters in the company, dependencies, influencers etc. is what they need (but very often cannot ask for explicitly).
Where the poster perhaps helps a bit is when you’ve got people annoyed that you have such a fancy role name and that you might claim some of their responsibilities (especially normal working roles within the central circle). This approach helps you to get them on board, especially if you can really start collaborating with them in a mutually respectful way appreciating each other’s added value and contribution. But for that you don’t need any poster:)
The bottom line is that it helped us (the EA team) the most. This realization that we are just small figures in the big play made at least me more humble, respectful, more cooperative, open to others viewpoints, much less hungry for authority or this fancy role name and much clearer in our purpose, value and goals, without showing off smartness or superiority in any way. This blog is in fact a small reflection of that as I write it with the primary intention of sorting out my thoughts and having a sanity check of our work from others to see if I am not off the track completely. And I am really grateful for any feedback, because it makes me think.
Cheers
Great post. I really like the diagram. The context which is presented in is based on where the organization is. In the public sector where I am currently engaged they have just undergone a program review that told them that things are seriously screwed up or an election cycle has necessitated some sort of profound change based on a new political reality – i.e – cutting costs.
The organization often doesn’t know where to start and the people there often helped create the problem in the first place. My point to the leadership of my current client is that unless you can agree and document and least a set of business capabilities (in the absence of strategy or an operating model) you can then tie your technology investments to them. Otherwise you pretty much just have an IT architecture initiative which, while helpful, doesn’t address the root cause.
Great post and I’m looking forward to reading more of your work!
Jason
Nice Post. Thanks for sharing it. Would you be able to share what kind of services offered by EA and scope of it in your company? For example in Developing the strategy what is that EA brings to the table? Whatever it brings to the table how it developed that capability (Models, structure etc)? Did that capabilty exist before? If yes did EA do anything to make it better and how? If not how did you justify that EA needs to build that capability? How do measure the value of it to create a business case even before delivering it. As most of the time EA colloborates with many groups for the activities( Example Strategy development) so how do you know whats the contribution of EA?
I am just trying to understand/learn how other folks trying to position EA and functioning in other companies. How they are measuring/Showing the values of it.
Sorry to bother with all the questions but anything you could share that helped you doing the above will be great.
Hi Pradeep, sorry for a late response, vacation, you know:) In my past experience services offered by EA quite varied. Especially regarding strategy this was different in every company. From basically driving facilitation of IT strategy creation and annual strategy revisiting to being those who link strategy with execution – meaning delivering means and tools to depict whether projects are aligned with the strategy or not.
This is kind of a marketing talk. In fact providing this service meant first of all pointing out where it’s not all that clear that projects or activities carried out in the company are not always in the best interest of the business strategy (every project claims it is either strategic or mandatory, right?:). Second of all we pointed out where the strategy is rather vague and does not provide enough detail for directing architecture development and third of all facilitating discussion and creation of more detailed “strategy”. Now strategy here can mean different things for different people, from “tactics”, through principles, policies, or even corporate values. I find this to be quite dependent on corporate culture, sometimes it’s enough to call the same things differently:)
I read some time ago that EA is the glue between the strategy and I have a strong tendency to see t this way and also design provided services.
I’ll provide a very concrete recent example which is just about getting out of the Pampers maturity stage, but it seems to be able to fly on its own. So here it comes (without any detailed context, hope it’s clear enough):
When I joined the company the first think we did in the newly formed EA was to define “business principles”. We argued why business strategy is not enough some biz.representatives to validate them. That was back then as much as we could get. We developed architecture principles as well and did a small roadshow to get buy in. I know very well that nobody’s gonna follow those principles once confronted with a real project. That’s why I talked about principles from the very beginning as a means of communication – a common language among business, IT, architects, BI/DWH folks etc. This is the first time I have experiences that principles got some buy in – quite strong from the CIO and reasonable from some business managers. Good enough to start with. In the second step, we created an assessment methodology for verifying compliance of a solution with the principles. Now, this is a very real and valued service which is being actually requested by business and became mandatory input for steering committees (for project with medium to high architecture impact, here is another story about setting up the governance/assurance part). In the assessment we provide a visual form of which principles are broken and consequences. Put it simply, what impacts it will have on them and or their business. We even try to estimate “technical debt” that’s explicitly accepted by steering committees.
To me the proof that this works is the fact that business detailed one of the high level business principles into seven more detailed and asked for their compliance assessment for every project. This is what they understand and can immediately see if project is aligned with their goals or not.
I hope that this will help to eliminate the blame-IT-for-high-cost-and-low-speed culture and will initiate constructive discussion about developing architecture to align with long term business needs.
Another example of our service – though we define it on the level of our own EA strategy – is facilitation among tons of various architects we have. We promise “One architecture” meaning single opinion on architecture. Man, this is pretty challenging task, yet it can be clearly seen by management as they are getting very contradicting opinions sometimes close to flamewar. So facilitation is also a service we provide and this is both in projects regarding solutions and in definition of a target architecture – the long term view.
And there would be lot more to talk about, plenty of ideas what to do and how:)
Now to measuring the value we deliver. For now we actually don’t. We only recently defined our KPIs – those that are influenced solely by the work we do, and other metrics – those we measure and can indicate real impact of our work on the end result, yet we are not the only influences of these metrics. Nevertheless this is more for us and to get stronger arguments then to prove our value to the outside. In fact, I am very strongly convinced (and yet again this might heavily depend on a company) that you either deliver real value, and then nobody really asks about KPIs, or you don’t, and then no KPI is robust enough to survive questioning.
Hope this helps at least a bit.
cheers
O.
Thanks for taking time and responding to my questions..This helps.