EA EA OH!

This, I think, would be a short blog, since Enterprise Architecture, in my experience, is like “Bigfoot.”  Traces of both seem to appear occasionally, but on close examination they “prove” nothing, and are useful for campfire (or war) stories but little else.

Feeling lazy today, I am eager to be right about this, so I can quit writing and meet my deadline with minimal effort.  Hmmm, why DO I think EA is a myth?  Thinking fast (not hard), the following comes to mind (ooh ooh ooh! If I indent this it will fill more space – don’t tell my editor!):

As a BA, I have had to create my own “Enterprise Architecture” for every project I ever worked on.  Even in the face of overwhelming project success, these “architecture artifacts” would disappear from the organization’s consciousness almost as fast as “code hit the ground,” 

One would think that a process like payroll would be a foundational ROCK in any organization’s EA, yet I have witnessed the elimination of a payroll processing system in favor of a “nag processing system.” The purpose of the “nag processing system” was to allow a manager to track paychecks that had not yet been issued and to nag people to get them done faster (albeit without a working payroll system).

Eager to validate my “excellent” opinion and get a “quick blog win for minimal effort” (maybe a Nobel prize?), I do a little research.  If I am lucky, I can put a big fat quote in to make the blog look longer, weigh more, and fool my editors:

According to Wikipedia:

“An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g. the behavior) between them. EA describes the terminology, the composition of enterprise components, and their relationships with the external environment, and the guiding principles for the requirement (analysis), design, and evolution of an enterprise. This description is comprehensive, including enterprise goals, business process, roles, organizational structures, organizational behaviors, business information, software applications and computer systems.”

Ah ha!  Here is part of the evidence I seek to prove my opinion.  Notice the definition begins with the words “rigorous description” and continues with “This description is comprehensive.”  This, I am sure, I have NEVER seen.  I am tempted to rest my case, but I suddenly sense the chill shadow of my editors looming over my shoulder. 

As I think about cheesing some quick boilerplate and trying to fool the editors with a quick close, it occurs to me that a “rigorous” Enterprise Architecture would be extremely valuable to an organization, and even more so to the organization’s competitors. This could explain why such EAs are never seen (and why elicitation can be so challenging).  Could it be that they are SECRET?

I am intrigued, and decide to look further:

According to BABOK^® 2.0:

“The enterprise architecture defines the current capabilities

of an organization.”

“< It > Describes the current state of the enterprise, including the organizational structure, business processes, systems, information, etc.”

“< It > Describes the organizational units that exist, their interactions with other organizational units, customers, and suppliers, their responsibilities within the organization, and the roles and relationships within each organizational unit.”

“Enterprise architecture is a description of an organization’s business processes, IT software and hardware, people, operations and projects, and the relationships between them.”

Here is yet ANOTHER clue.  The BOK definition tracks with Wikipedia, but REALLY emphasizes relationships.  I think I am beginning to understand.  There IS Enterprise Architecture – the organization clearly has current capabilities, the relationships within and across organizational units clearly exist, and if you listen to your stakeholders complain, it is clear that the EA gets “described.”  Why then, when I ask for EA documentation, is it so incomplete, fragmented and often just wrong?

Then it hits me.  In a flash!  It’s almost over, for now.  I could be done, finished, headed home, completo, finito, kaput (Kaput?  Wait a minute!).  There are several things going on.

1. EA documentation at the highest strategic levels does exist, and includes organizational visions and goals and missions and strategies, organizational charts with assigned departmental process and role responsibilities, written policies and regulations, IT documentation of existing systems, employee job guides & training, departmental operational and project plans, project plans, etc.
2. These EA artifacts ARE fragmented – they represent the distinct views and understanding of executives, lawyers, salespersons, human resources experts, IT, manufacturing, operations, and many more stakeholders.
3. Relationships between these cross department stakeholders are mostly described in org chart and policy documents and role descriptions and sometimes (sometimes) context diagrams showing some data or responsibility exchange between entities.
4. As the BA, I must go deeper into these relationships, which only show up in actual business PROCESSES, as they are executed in fact, not as they are imagined.
5. It is this sense of PROCESS between entities, within or across organizational boundaries, that is the TRUE relationship between the entities. Love, they say, is a VERB. This sense of commitment to action is rarely documented, except by some of the most successful organizations in the world. Every big franchise is a “process documentation monster” but even some large organizations will survive on culture and attitude over process, especially when they are growing fast. Keep an eye on Google – does anyone know their EA secrets?

At last the punchline, possibly the first in history ever rendered as a use case.  Can it be that I am done, because EA exists and it IS a secret?

The documented relationship tends to be:

Once a customer is signed up by Sales, Service is responsible for customer satisfaction.

The actual relationship is easy to illuminate by simply going one level below the “official policy relationship” to the “stakeholder rubber on the road” (no, don’t, stop, don’t think that oh oh oh why do the words “road kill” come to mind?):

Main Success Scenario:

1. Salesperson closes sale.
2. Customer signs up.
3. Serviceperson delivers “product.”
4. Customer is happy.

Extensions, variations, details:

• 1a. Salesperson does x, y, z….
• 2a. Customer does a, b, c….
• 3a. Serviceperson does l, m, n…
• 4a. Customer is unhappy because:
• 4a1. Salesperson over-promised…or customer over-expected
• 4a2. Salesperson under-explained….or customer misunderstood
• 4a3. Salesperson won top bonuses for sale…or nothing, so it goes?
• 4a4. Etc…

No wonder EA is a secret!

The lesson is clear for those who WANT real EA.  GET a BA, and start analyzing the real impact across stakeholder silos.  EA can only drive real results WHEN YOU GO UNDER THE COVERS TO PROCESS AND ACTION.

Here is a thought for CEOs and other top leaders – if the way to connect abstract visions to rubber on the road is through process, then your best strategy is to “command the BA Army.”  You have one, and don’t even know it.  Many of them are not called BAs, some you will know as vague “nuisances.” 

These BA types think strategically like you, have an eye for critical details that you don’t have time for and want what is good for the organization.  Most BAs are less charming and charismatic than you are, and just need a little love (action by you).  If you back them through the occasional “political hiccup,” you will get far more rubber on the road.

So much for minimal effort.

EA, EA Oh!

Don’t forget to leave your comments below.