7 Ways to Kill an Enterprise Architecture Initiative

Bas van Gils & Remco Blom
Posted by Bas van Gils & Remco Blom on May 2, 2013

Enterprise Architecture

Even though Enterprise Architecture has evolved into a mature business discipline that drives strategic change, we often see Enterprise Architecture initiatives fail. Both when the Enterprise Architecture function is a great success, and when it is not successful, people may want to throw a bomb on the Enterprise Architecture initiative. In some cases, business managers, project managers or others that consider themselves stakeholders of Enterprise Architecture, are spreading negative messages about Enterprise Architecture in general and the current functioning of the architects in the team in particular: They are after your budget, they are bothered by your principles, or they just don’t understand your value! The consequences may be severe for the Enterprise Architecture team. In this post we explore the 7 most common statements used to criticize or even kill an Enterprise Architecture initiative. We also explore your options to survive as an Enterprise Architecture team. 

“Enterprise Architecture is about everything, so it’s about nothing!”

Architecture is often positioned and sold as a tool that will solve all business problems related to the complexities of change. With ambitions that are high, and with the pressure of many projects and day to day issues that have to be solved, there is a high risk for the focus of the Enterprise Architecture team to become dispersed.

Enterprise Architecture is a useful tool when (a) complexity and change go hand in hand, or (b) when IT is of strategic importance, or (c) when both (a) and (b) are true.

Tips for survival:

  • Make sure that the Enterprise Architecture initiative has a clear scope (and validate their effectiveness accordingly).
  • Come to grips with strategy implementation: support investment decisions with careful impact analysis across the entire architecture landscape.
  • Focus on integration: make sure that new developments ‘fit’ the existing structure.
  • Support projects in the here and now: govern standards, avoid re-inventing the wheel, and help projects in delivering what was intended – on time and on budget. Projects and current problems are always discussed at the new year reception, anniversaries and team building sessions. Your architects should be present there!

“Those architects are only busy making vague pictures!”

Architects have a reputation of being ‘those guys that run around with big, complex diagrams’. This is the physical manifestation, the thing that people see as the result of the architecture process. It is not the end, though, it’s just the beginning! In Enterprise Architecture we should focus on the process of supporting/driving business initiatives. Architecture products – such as models – are a means to an end. 

Tips for survival:

  • The purpose of your visualizations and the stakeholders you present them to determine the success of every model and visualization.
  • Architects should focus on selecting proper viewpoints and visualizations to address the concerns of these stakeholders. Being relevant is more about leaving stuff out, than about being complete.
  • Do not stick with the traditional boxes and lines. Also cartoons, matrices, lists, text, simple drawings, complex drawings, detailed analyses, cost indications are all valid deliverables of the EA process!
  • Also (and not just) make a visualization that will make it to the wall of business management’s offices. Get to know the management in an informal way to learn about their preferences and agenda.

"Enterprise Architecture doesn’t deliver results for our customers. And we exist to serve our customers, right?!“ 

Yes… sorry, but it’s the truth. Your Enterprise Architecture does not deliver direct results to our customers. Enterprise Architecture gives an answer to the question “how should we organize ourselves?” and provides a roadmap for the organization to get from where we are to where we want to be. As such, customers should not directly observe (the results of) Enterprise Architecture. Indirectly, however, they will definitely experience the effect of a strong Enterprise Architecture capability in the organization. But Enterprise Architectures should have a clear view on the business model of your organization and they should be able to explain how their work is related to the success of your organization.

Tips for survival:

  • Get a common understanding of the Business Model for the Enterprise Architecture team.
  • Communicate your added value in term of the business strategy. Always communicate the value of EA in terms of money, risk, time and quality.
  • Potential customer benefits from Enterprise Architecture are:
  • Service levels will go up because EA will result in improved grip on the way we run our business.
  • Shorter time to market because of re-use of existing processes, IT etc.
  • Cost reduction could result in better prices.

“We are trying to do Enterprise Architecture now for the third time. Why will it be successful this time?” 

This is a “standard” tactic for attempting to kill any initiative. Enterprise Architecture is not easy and it is a constant process of learning and tuning. In most organizations we see “waves of architecture”. After the first period of attention and investment in architecture, the swing moves more towards delivery and project orientation, after which organizations see that more attention for the long term is needed and architecture comes back on top of the agenda again.

Tips for survival:

  • Stay out of discussions about the past. It is all about here and now, or even the future!
  • Do make an analysis on the factors that made the former initiative fail. You really need to learn, and so does the organization you work for.
  • Use proven methods, tools and if needed, consultants.
  • Get yourself an active sponsor to back you up. It is not your architecture, you are only the architect putting it on paper and making it come alive! Your (future) sponsor is preferably the person explaining the business strategy at the new year drinks reception, so be there and get yourself introduced.

“Architects are just a bunch of promoted designers working in projects!” 

In some cases this bold statement is just what it is. Architecture is a discipline that requires strong, communicators with a vision. When the architects are only active in projects, Enterprise Architecture will never grow beyond tactical problem solving.

Tips for survival:

  • Don’t just run in projects. Work closer to the strategy and closer to the strategists
  • Create a set of principles, in collaboration with business management
  • Make models that make policies come alive. This will not be easy, but very useful in all domains.
  • Introduce TOGAF to give you a structure to work from the vision down to the definition of projects (typically in collaboration with a PMO), instead of being the person that hits the brake in all projects.
  • Get your training and certifications in place to learn what it takes to be more than a promoted designer.

“Enterprise Architecture is about computers. It is all about the business in this phase, so come back when we are done!”

Wrong! IT-architecture might be about applications and infrastructure (which is more than computer alone, but that is a whole other discussion). Enterprise Architecture is about “everything the organization is and does”, and covers various aspects of the organization: product architecture, process architecture, organization architecture, information architecture, and last but not least, applications, data and infrastructure. The position of the Enterprise Architecture team in the organization largely determines its scope/range of influence. Of course it’s hard work, being under the CIO, getting people to understand that you should also be involved in the business architecture.

Tips for survival:

  • Never do the jobs that the business management should do. But always be the first to help them, with tips, tools, time and testimonials from others who were successful in doing real Enterprise Architecture.
  • Emphasize the need for business-IT alignment (or maybe even business-IT fusion?). If your stakeholders understand that this is important, they will understand that a holistic Enterprise Architecture approach overarching all domains is a necessity.
  • Build a success story. It is not a bad thing per se if this is in the IT domain. What you need is benefits in terms of currency, time, quality and/or risk. Only that will really be impressive for your stakeholders in the business. Pitch it at a party and get yourself at the table.

“The Architects never descend from the ivory tower!”

 Architects have a specific interest in the truth, definitions, methods and models. As every group of professionals, architects have their own vocabulary, with concepts such as “Business transformation readiness assessments” (taken from TOGAF), “data dissemination diagram” (again from TOGAF) and “stakeholder specific viewpoints” (from ISO/IEC/IEEE 42010:2011). This helps architects to better understand their own work and have a professional chat with other architects. This mystifies the field or architecture for everybody who is not part of the elite group of certified architects.

Tips for survival:

  • Let it go… there is no such thing as the truth
  • Let it go… there is no such thing as an up-to-date model of the current situation. The current situation of today will be the old situation of tomorrow. Take it all up a level and introduce the term “Baseline” to make it a specific moment in time that can be in the future or the past.
  • Stop talking jibber jabber, and start talking simple. Build an elevator pitch and test it. It should contain simple answers to simple questions. Start with these four: What is Enterprise Architecture? Why is Enterprise Architecture important? What does an architect do? (also needed at birthday parties) What do architects make?
  • Get out! And stay out! Your success will not be measured against your models or your method, but against your effect! Effects are made in dialogue with the business and in the projects that you steer with your architecture! The best place to start a dialogue is over lunch, or even better, at a party!

Embrace your criticasters

Whether your Enterprise Architecture team is a fully trained army ready to jump in and get the job done, or a small group of guerilla warriors who mostly work under the radar: you should always be able to present your added value! Especially to your criticasters. If they buy your pitch and pictures, it is likely that everybody will buy it. Do not avoid your criticasters, but go out and meet them anytime you can. I think we have given plenty of reasons to attend parties! A normal conversation is more effective than a fight. Take the resistance against Enterprise Architecture as a signal to improve your work and your communication. Never throw your architecture jargon around the room, and be conscious about the complexity of your visualization. Whatever strategy you choose, we look forward to helping you to professionalize and communicate architecture!

Forrester Wave Enterprise Architecture 2017


Join 10.000+ others! Get BiZZdesign's latest articles straight
to your inbox. Enter your email address below:


Subscribe to Email Updates

comments powered by Disqus