Evolution Was Bad for Neanderthals

If you were a Neanderthal, evolution was bad; at least the dinosaurs left birds. Humans emerged and you were no longer relevant - you and your buds left a lot of nice bones for us to dig up. When technology professionals of the future dig up our bones what will they find? Ancestors or Neanderthals?

In a recent discussion on Linked In's Enterprise Architecture Community, a pundit reminded us of a sobering Gartner prediction - that something like 40% or 60% of EA groups in organizations will go away in the coming years because they have failed to establish their value. As a practitioner of EA, this concerns me but I can totally see it. The posts that get the most attention on EA discussion boards are ones that ask but fail to resolve fundamental questions like "what is EA", "what is an EA framework", and "what value does EA add?" The discussions don't lead anywhere or produce much actionable information. They are fun, but somewhat pointless.

Let me state for the record that I AM REALLY CONCERNED ABOUT OUR PROFESSION. We have to reverse perceptions or die on the vine. At the end of the day, if we do nothing we will cease to be relevant, and if we aren't relevant we will become extinct.


Being a person of action, I'm trying like hell to focus less on what EA is and more on questions like, "what does EA mean to the company that pays me a nice salary to be one?" In asking this question another thought occurred and is the main subject of this post -

What if we could use some 'proven architecture techniques' to come up with a common definition of EA -- then use that definition as a call to action within our own organizations (and make ourselves ancestors to the next generation)?

Imagine - a group of EAs, coming together informally on line to reach a consensus on what it means to be an EA and then carrying that definition to their organizations to actually do something. Huh! Could be powerful. Could be actionable. The point: as a community of professionals who profess to know how to move complexity into action, we need to eat our own dog food.

In my last post I offered a definition that posits EA is the use of proven architecture techniques at an organizational level to achieve benefits such as an actionable plan and governance in the face of complexity. So here we are in the face of some organizational complexity; we have a community of intelligent, experienced and articulate professionals, all with opinions about what it means to be an EA. In fact, with so many opinions, it is difficult to arrive at a consensus in order to harness the power of a common definition and then go do some stuff in our organizations or with our customers.

So let's take some action. I'm a "new" EA - in third year as an officially titled EA, even though I now realize I have been doing EA for years. I've been educating myself on exactly what proven architecture techniques are. Boiling down the essence of the the "xAFs", 1471-2000, etc., here are some simple steps that we could take.

1. Separate ourselves into stakeholder groups that have similar concerns then document those concerns. For example those of use that are former business people will have different concerns from infrastructure people.
2. Decide on common principles and requirements for an EA definition (without defining EA.) Examples - Principal: The definition should be simply worded and as brief as possible without compromising meaning. Requirement: The definition must be actionable.
3. Decide on a few "Views" of EA that address various concerns. For example, a Business View would address the business people's concerns, while a Technical View would address engineering concerns and an Application View would speak to those with a software development background.
4. Split into subgroups and develop the Views. Each view could consist of principles, requirements, a model and a candidate definition.
5. Compare the views, identifying the similarities and friction points, and then identify the enablers and inhibitors to arriving at a common definition.
6. Reach compromises on the friction points and inhibitors; use the similarities and enablers to do this.
7. Define EA (ta-da'!)

With a nifty common definition in hand, we can next analyze the current state of EA; then, based on our definition, define future criteria for use, and create action plans for our organizations (roadmaps).

Is anybody out there interested in doing this? It will be work, but also a chance to prove our craft. Otherwise I fear we are Neanderthals and that is bad.