I have long been an advocate of Enterprise Architecture as a concept, and have successfully helped roll out various forms of EA across different companies. However one constant has always been that EA needed to be redefined to address the widely varying views of what it was, and what benefits it could provide. In some cases this extended to changing or repairing some existing negative views. Those views could be because of one person (the architect that team or individual worked with), or as an opinion of the whole EA process.

This post shares some of those negative views, with the aim of helping architects understanding what stakeholders might think of EA and how to address them. It also allows me to be a bit negative towards EA, as I have certainly seen implementations of EA that are more a hindrance than help. As I’m currently helping roll out EA with a new company, I also want to make sure I don’t fall foul of the below perceptions.

The Government

One very common, and not entirely unjustified view, is that EA isthe remit of failed engineers or simply tech academia (e.g. those that can’t do, teach). It imposes frameworks and governance that only serve to centralise decision making and slow down the velocity of change and progress. This view can even sometimes come from architects themselves, especially Solutions Architects used to more agile processes, who would often be frustrated while waiting on their next ten minute opportunity within the bi-weekly Architecture Board to discuss their proposal for the replatforming of an entire system (or something like that). I see this view perpetrated by the more bureaucratic organisations where phrases like ‘we are not a tech company’ are prevalent (by the way, that’s probably the phrase I fear the most in any company I have worked for). In those types of companies, EA serves exactly that purpose, to slow things down, and provide assurances and accountability into any IT change. This in my opinion is the worst use of EA, and tarnishes it’s goals for others.

Rectifying this view comes down to collaboration with engineers, and building credibility with technical teams. This may also involve reviewing processes and relaxing the governance somewhat to ensure EA is guiding and not hindering development. From the business side it may also be necessary to begin demonstrating real business value quickly, and re-communicating the role of EA, along with any strategy or vision.

The Consultant

Another view of EA is the consultant view, in which architects only come into a project at certain times, spout advice and guidance, and then disappear until the end, or when something goes wrong. This view sees the architect as a bit of the ivory tower type, supercilious and not connected (or possibly experienced) with real projects. This view often stems from when actual consultants have been used to rollout EA, and their methods have been adopted by permanent replacements. This can also sometimes be the case when architects are simply stretched too thin, and can only spare time up front according to business priorities.

If you find this is the case in your practice, then consider who you have available to perform the role of Solutions s Architect within each team. this doesn’t always have to be a dedicated role, and often a lead engineer can perform this function well. Using these guys will help delegation, and also gains more buy in from engineering teams. Ultimately if you find you aren’t adding anything to a project, then simply refocus on priorities until you demonstrate the benefit that allows you the budget to get more architects.

The Thinker

Perhaps more of a character portrait, but this is certainly the view I have held myself of certain architects I’ve worked with (and unfortunately reported to). These architects tend to enjoy the blue sky thinking involved in architecture, and are typically the ones designing new processes, new templates, new acronyms, and have very little input into detail. Ideas coming from these guys tend to be quite ideological and seldom have any indication of how these visions and ideas might be achieved, at least not in any detail.

One simple solution to this one, start delivering real value. Architects need to resist the temptation to perfect everything they are doing upfront, and instead learn to be more agile and responsive. designs can change along the way, and often will. As George Patton once said;

“A good plan violently executed now is better than a perfect plan executed next week”

So how do I fix it?

All of these views derive from EA practices that have been poorly implemented, or have been implemented as top level governance frameworks with little connection to engineering and delivery. if you are in these positions, or perhaps are now implementing EA at your company, then keep these things in mind;

• Although EA is about making IT align with business, the engineering teams are a critical part of this delivery, and their ability to deliver should be a key consideration.
• As with all areas of business, EA needs to be seen to deliver value. In my opinion it is unacceptable for architects to spend a year in a dark room and then emerge with a radical framework designed for global dominance. Ensure you start delivering from day one, and resist overthinking or perfecting everything.
• Although architects should be key resources and leaders of technical knowledge, don’t become the only guy with the knowledge. Ensure you have good knowledge management processes (thing Brown bag lunches , coding dojos etc), as it will upskill everyone and lighten your own workload.
• Use diagrams as temporary tools to demonstrate thinking, and not as a governance tool to indicate an agreed design. Things change quickly in development, and adhering to thinking at the beginning of a project is dangerous. At minimum, you will find these diagrams become quickly out of date and will dilute your process. Diagrams can be given to agree an ‘approach’, and then architects should work closely engineering to ensure the final output is true to the ‘approach’, if not the actual design.