Enterprise Architecture and Modelling

Enterprise Architecture is a management tool that tries the to solve the problem of runaway complexity in an organization. This runaway complexity , also known as incidental complexity, is the enemy of organization, planning, and change management and can lead to solutions introducing different more severe problems, aka the butterfly effect or complexity theory. The way you deal with complex problems is to divide it into parts, this is good advice in every domain, not just EA. When dealing with a complex problem, like the ones you get in case studies and case interviews, you break a problem down into its component parts and then break the individual parts into their components and so on till you get to a level of detail where you feel comfortable analyzing the problem and recommending solutions.

To draw an analogy, software architecture is concerned with maintaining logical integrity and managing complexity within an application, enterprise architecture does the same thing, but at the level of the organization. Traditional Software Architecture uses models to describe parts of the solution in a way that encapsulates solution components, models like class diagrams, state diagrams and entity relationship diagrams are generally accepted software architecture diagrams. In EA, which operates at the organization level more abstract diagrams are used to encapsulate components, we have business architecture components, data architecture components, software architecture etc. The one thing that we have to be careful of in EA as well as other domains that use models is that a model is just that, an abstract view of an object, and as such is limited in how much it can help us in understanding the object and its interactions with other objects. One spurious way to solve this is to make the model as complex as the real object. This, however, defeats the purpose of modelling. The other way to deal with this limitation is to realize that models are abstractions and base all decisions on this understanding. In other words, lower your expectations of what a model can do and in turn what disciplines that rely on models can do. 

Left Brain, Right Brain Enterprise Architects

I was recently reading some of the literature regarding the differences between the left brain and the right brain, and how challenging it was to move from doing work that primarily involved one side of the brain to work that needed the other side. Regardless of where you stand on the issue of lateralization of the brain, i.e. each side of the brain specializes in certain functions, it stands to reason that the type of skills needed to succeed as technical or solution architect are different from the kind of skills needed to succeed as an Enterprise Architect. There is some overlap between the two roles, but by and large, Enterprise Architects tend to look at the big picture, while solution architects tend to be focused on making sure the solution fits the problem in terms of the specific domain. What happens then when you tell an Enterprise Architect to solve a specific, concrete business issue? They start to look at big picture and the project seems to spiral out of proportion when the EA suggests connections and impacts all over the organization. Remember that old nursery rhyme? 

"Your toe bone connected to your foot bone,
Your foot bone connected to your ankle bone,
Your ankle bone connected to your leg bone,
Your leg bone connected to your knee bone,
Your knee bone connected to your thigh bone,
Your thigh bone connected to your hip bone,
Your hip bone connected to your back bone,
Your back bone connected to your shoulder bone,"

This is the world an Enterprise Architect lives in, the solution architect will solve the problem you face, and that might be exactly what you need, but the Enterprise Architect will dig up connections and issues that need to be addressed before the final outcome is reached. This big picture thinking sometimes causes friction between the client and the EA, and often leads to raised voices and heated discussions about the scope of the problem, which was supposedly decided before the EA project began. The freedom to pursue the problem and come up with a creative solution is not an issue faced by the right brained EA's alone. An experiment was conducted in the 1990s, by a team of researchers led by Harvard Business School’s Teresa Amabile, with visual artists. Amabile asked 23 painters and sculptors to randomly select 10 of their commissioned works and 10 of their non-commissioned works. Then she presented the 460 pieces to a panel of art experts – museum curators, art historians, gallery owners, and so on, who didn't know where the works came from – to evaluate the art.

“Our results were quite startling,” Amabile and her colleagues reported. “The commissioned works were rated as significantly less creative than the non-commissioned works, yet they were not rated as different in technical quality.”
Put another way, the commissioned art was good. But the works that were great were consistently the non-commissioned ones.
One reason for this may have been the limitations put on the artists to deliver the art work in a specific platform focusing on a specific object as the inspiration, rather than letting the artists run free with their imagination.
I'm not suggesting that EA's be allowed to run free, in honesty most of us come from technical and systems engineering backgrounds and can't run rampant, but I am suggesting letting EA's work within broader boundaries to solve the business problems they are asked to solve.