Ten Ways to Kill An Enterprise Architecture Practice

Have you seen practices that you know could kill an Enterprise Architecture practice?  I have.  A recent LinkedIn thread asked for examples, and I came up with my top ten.  I’d love to hear your additions to the list.

How to screw up an EA practice

  1. Get a senior leader to ask for EA without any idea of what he is going to get for it. If necessary, lie. Tell leaders that EA will improve their agility or reduce complexity without telling them that THEY and THEIR BUSINESS will have to change.
  2. Set no goals. Allow individual architects to find their own architecture opportunities and to do them any way they want.   Encourage cowboy architecture.
  3. Buy a tool first. Tell everyone that they need to wait for results until the tool is implemented and all the integration is complete.
  4. Get everyone trained on a “shell framework” like Zachman. Then tell your stakeholders that using the framework will provide immediate benefits.
  5. Work with stakeholders to make sure that your EA’s are involved in their processes without any clear idea of what the EA is supposed to do there. Just toss ’em in and let them float.
  6. Delete all the data from your tool. Give no one any reason why. You were just having a bad hair day.
  7. Get in front of the most senior people you can, and when you get there, tell them how badly they do strategic planning.
  8. Change your offerings every four months. Each time, only share the new set of architectural services with about 20% of your stakeholders.
  9. Create a conceptual model of the enterprise that uses terms that no one in the enterprise uses. Refer to well known business thinkers as sources. When people complain, tell them that they are wrong. Never allow aliases.
  10. Every time you touch an IT project, slow it down. Occasionally throw a fit and stop an IT project just for fun. Escalate as high as you can every time. Win your battles at all costs.

Your career will be short. 🙂

From http://blogs.msdn.com/b/nickmalik/archive/2013/09/05/ten-ways-to-kill-an-enterprise-architecture-practice.aspx

EA Generalist

A generalist knows a little about a lot of things, and, crucially, how to connect them together. Good generalists are well aware that they are actually quite small fish in what is often a very big pond.

A specialist knows a lot about a single often very-little thing. Good specialists can be quite big fish, though only in a relative sense within their own often quite small pond.