EA Voices

On the opposite side of the spectrum, Burton outlined her baker’s dozen of “worst” enterprise architecture practices. The EA methods that Burton said muddied efforts and missed overall business returns are as follows:

1. No link to business strategic planning and budget process.

2. Confusing “IT Architecture” with “Enterprise Architecture.”

3. Lack of governance.

4. Too much standardization.

5. Focusing on the art/language of EA rather than the outcomes.

6. Strictly adhering to architectural frameworks.

7. An “Ivory Tower” approach by IT and EA team members.

8. Lack of communication and feedback.

9. Limiting the teams to IT resources.

10. Missing performance measures.

11. Picking a tool before understanding business needs.

12. Focusing on the current state first and primarily.

13. Thinking that implementation equals completion.

For both ideas I have the tendency to answer them very similar to Chris Potts: The Architect Designs, as I have also put it in my blog post GLUE Roles and Responsibilities. The [Role] Architect does deliver the [GLUE Discipline] Design. Nevertheless there is an enormous amount of specialized Architecture Titles. And it is in the nature of the discussions between the people who own the title to create clearly defined empires, so that there is preferable no overlap. Reality (for real Enterprise Architecture) is that there is always overlaps. And the good news is that the tension and friction created due to the overlap have a good chance to enforce creation of new (hopefully great) ideas.

So, don’t think you are an [xxx] Architect, but know you are, then you do not have to seek for a perfect definition. (There might be no chance to find the perfect answer, but just a working one. One that works for you only). The key message though is, that it is not a title, but a role. A role which will be fulfilled in any given context, because [Enterprise] Architecture inevitable happens, no matter if the people who perform it are titled in the right way or not.