A common phrase used to describe an enterprise architecture is a set of “living documents”.  I like it.  Short, simple, easy to understand … a living document.  Of course there is a dangerously complex implication lying just below the veneer of this simple metaphor.  Living implies change and growth.  It would seem to need to be feed and cared for.  Most importantly it begins as an immature child and develops into a mature contributor to its society.

Those of us who interact with enterprise architectures are affected by the living document metaphor in different ways depending on our role and the maturity of the architecture. 

You may be the parent, growing the architecture with new ideas, carefully cleaning away the little day to day dirt and grim that accumulates during the early draft phases.  You are its protector, fending off hungry projects looking to gorge on its young unallocated funding.  And you are its champion, fighting the good fight.  You turn nay-sayers in to supporters with tales of possibilities and the obvious future value your enterprise architecture will provide.

When initiating an enterprise architecture you survey your environment, talking to representative users, reading existing documentation, and studying current systems.  You seek the inherent problems the enterprise has in accomplishing the tasks it needs to perform in order to be successful.  You boil down the potentially voluminous data gathered and abstract your findings into the conceptual diagrams.  You aggregate important policies and standards into a cohesive and broadly applicable guidance document.  Applying some well known patterns and a few of your favorite concepts you evolve working documents into drafts and eventually into your proposed architecture.  Educated and armed, you lobby superiors, peers, and subordinates to aid you in implementing your new born document.

You may be the doctor, having received an urgent request from the worried parents you make a house call in hopes of identifying and repairing an ailing architecture.  Your years of experience, your deep understanding of how architectures work, and of course your calm bedside manner come together to reduce the fears and sooth away the pains.  Your prescriptions are sometimes difficult to take and always come with warnings.  Crisis averted you can only hope the parents will implement both recommended treatments and get you back for follow up visits.

You might tell yourself “no one calls when things are going well”.  It helps fight the cynicism induced by seeing nothing but sick, or failing architectures.  Doctoring and enterprise architecture is a fairly predictable process.  Assess the situation, calm the managers, gain their confidence, diagnose the most serious of the ailments, prescribe corrective actions, and hope you get the chance to move to a more preventative role.  The first three steps are pure soft skills.  You need to identify the ‘age’ of the architecture.  Are you a pediatrician, a general practitioner, or a gerontologist? Once you understand the context you need clear, truthful information from the locals to begin diagnosing the problems.  What are the symptoms? Are they based on real measurable facts (high temperature, low transaction rate) or are they ambiguous (stomach ache, security issues).  If the problem is clear you can certainly look at historically successful corrective measures but it is likely you will need to do a few tests first.  If the architecture is young you may create a few models to get a better understanding of the issues.  If it’s more mature you may use profilers, performance monitors, and debuggers to investigate further.  Armed with your test results you can provide the declarative remedy (with the necessary warning of possible side effects and encouragement to call again should symptoms continue or worsen.)

You may be the teacher, seeing the untapped potential in the enterprise architecture; you carefully insert just the right information at the right time.  While very young you provide stories of other successful architectures and their exploits.  You paint colorful pictures of systems supporting terabytes of data, massive concurrency, very high transaction rates, and global user communities.  These are the super heroes of the enterprise architecture world. You can but hope to instill a sense of the possible.  Later you begin the monotonous lessons relating rigor, discipline, reviews, change management, and the build process.  No glamour, just facts.  Hoping to build knowledge on who’s shoulders understanding can later stand.

Being an enterprise architecture consultant is very different than being an enterprise architect.  As a consultant we bring our experience, and hopefully the ability to transfer knowledge, to help others so that they may achieve.  We don’t build anything.  (OK, maybe we build confidence, but that’s not really the point.)  Ours is an art of subtle manipulation.  We can’t dump a well formed architecture on our customers and expect them to succeed any more than buying a 12 year old a set of encyclopedias and believing they now know everything.  The most successful consultants I know have a plan.  They know what needs to be addressed first and what needs a foundation in place to be useful.  Explaining the intricacies involved in balancing risks, constraints, dependencies, resources against tasks, goals, and metrics is silly if the enterprise lacks basic structure, clear scope, and tools.  Teaching takes time … teaching enterprise architecture takes LOTS of time … years, not days.  Ours is a commitment to stay the course.

Eventually, the enterprise architecture matures, becoming a stable adult and valuable participant in the larger system within which it lives and works.  Its boundaries and capabilities are well defined for all to see and interact with.  Less reticent to see a doctor the enterprise invites scrutiny, takes all feedback (the good and the bad) and implements controlled change to integrate it.  The prideful arrogance of youth has been replaced with an open team structure.  Any and all projects are welcome to use the architecture and more importantly promote parts of themselves into the core architectural constructs.

With age comes rigorous process, clarity of definition, and actionable intent.  Mature enterprise architectures have well defined and executed processes in place for continuous improvement.  Communication is the cornerstone of the teams working with and on the enterprise architecture.  Lessons learned, good and bad, are rapidly communicated to everyone in the enterprise through well known channels.  Reviews are sufficient without being onerous on the participants.  All in the architecture ambles along a well worn path in a predictable fashion … until the next generation comes on the scene.  Then it all begins again.