Enterprise Abstraction

Explaning Enterprise Architecture

I'm always trying to explain what enterprise architecture is, and why I feel it's important.  Sometimes it's just to explain it to people who ask me what I do for a living, but often it's to sell EA to decision makers within my organization.

Long and detailed explanations are often out of the question.  Most succinct answers don't help.   I need to convey a few key things, but they're concepts that are often mind-bending for those who have not been previously exposed, or those who are caught in a different paradigm.

This diagram is my latest attempt to bridge the gap of EA understanding (click it for a full sized image).  It could use some work... but it's the most succinct diagram of the subject that I could manage.  A possible exception would be Enterprise Architecture = Enterprise Planning... but most people don't seem to fully grasp or accept that.

Comments are welcome as always.

The main thing I think many people miss is the place of EA in the organization.  Many people think that it's about doing technology, or doing technology better.  And while thats true to a point, they don't quite get the high-level up-front, if you will -- Enterprise, nature of the thing.  I always try to explain that it's much more about planning projects and setting directions than about implementing the technology itself.

Well, that said, as an architect my first inclination with propblem solving and communication is to draw something.  Hopefully this will move my clients closer to the target state of better EA understanding.

Complex problem solving

I just found this interesting interactive diagram about the art of complex problem solving.  Lot's of things in the model ring true to me with regard to the architecture field.

It makes me think about times when I've failed to communicate some of my visual models effectively, thus failing to actually communicate the mental model I'd intended in the audience.  When you think about it, it's kind of amazing that we're able to communicate complex ideas at all.

- Via Digg.

Transitional Architecture

An interesting article from IEEE's IT Professional journal entitled ENTERPRISE ARCHITECTURE - Transitional Architectures for Enterprise Evolution by Murat Erder and Pierre Pureur.

The article describes transitional architectures, and introduces the idea of change in architecture avoiding the sometimes difficult direct from current to the "to be" architecture leap.  They propose what they call a prescriptive approach using a series of achievable application plateaus and architecture waves that help to ensure the achievement of business value with each transition  towards the to be architecture, and avoiding being in a constant state of transition. 

Basically, a series of architectural rest stops on the path to the final destination.

In this article, we offer our version of the prescriptive approach:  Why not briefly document the current state of the architecture, define the desired state at the conceptual level,and finally define transitional architectures on the way to reaching that goal? In other words, we introduce the idea of change within the architecture process.By following this approach,you will quickly learn which areas you need to focus on before moving forward with the architecture models and blueprints. Our method also yields several important benefits,including a focus on delivering architecture features that matter most to the business; effective risk mitigation, expectation management, and requirements traceability; and lower costs.

The article is very readable, and may be of interest to developers, designers and business analysts as well.

ITIL

In an interview with Government Computer News (GCN), Malcolm Fry was asked to compare ITIL (Information Technology Infrastructure Library) with Enterprise architecture:

To my mind, ITIL is, to some degree, enterprise architecture. I don’t see a reason [why], when you have six different service desks in an organization, you can’t have one process that they all follow and one database that they all put their incidents into.

My experience with ITIL is quite limited, but based on my understanding, it seems much more concerned with change management and ongoing processes as opposed to EA's focus on business driven, strategic, target state realization.  EA is, with all due respect, is a bit more involved than 'recording incidents' in a common repository.

That said, I'm sure that both practices have their place, and many organizations could benefit from either or both.

Agile, SOA and the Buddhist connection

My previous post SOA and Agile - Peas in a pod got me thinking a little more on some analogies, and  about the up-front/unchanging reputation of traditional architecture practices in comparison with my view of architecture as a (potentially) very nimble and flexible process.

One of the problems with non-traditional (e.g. Agile) development methodologies is the human factor.  The tendency for developers/designers to invest their ego into the software they are working on.  For Agile to work you must be willing to separate your personal investment in your creation, assume that you don't know everything up front, the chance of  change is %100, and that it's quite likely that you are going to have to toss a good portion of your effort away.

It makes me wonder (mostly, but not totally jokingly) if the best agile software developers wouldn't be Buddhist monks, with their four noble truths.  In short:  life is suffering; the cause of suffering is attachment; eliminate attachment, and you eliminate suffering.  These guys are onto something.

In this regard, enterprise architecture and SOA could learn something from the agile (or a Buddhist) school of thought.  We cannot invest ourselves too deeply in the perfect architecture.  1)  it does not exist, 2) things change, and therefore architecture will change.  That's life, deal with it.

Increased satisfaction and effectiveness of architecture and development efforts could be achieved if we bring the agile principles of acceptance of continuous change to EA and SOA.  Architectures cannot flourish and be effective as solitary monoliths of unchanging perfection.  Besides, if they were up-front perfect, what would architects do with themselves?  Sit around a meditate perhaps?