Author: Marcos Ferrer

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.

It is important to remember that soft skills determine how our stakeholders judge our performance. This is not merely a case of an empty “image” or perception.  Our soft skills actually make the biggest difference in our ability to elicit and build consensus around quality requirements.  Most stakeholders WANT their projects to make sense, and don’t want to waste time.  If we cannot handle “requirements nonsense” without giving offense, we lose momentum and influence with our stakeholders. 

The following true story (all names and dates are changed or not revealed) illustrates the difference between “junior” and “senior” performance levels.

In 2007 a large government agency restarted a workflow automation project that had repeatedly failed for more than 10 years.  Every attempt to deliver a set of acceptable, feasible requirements had resulted in nothing – zero, zip, nada. The most recent attempt had taken two years, and was contracted to a very large consulting firm.  The only deliverable deemed acceptable after all this effort was a “high level” requirements document, barely more than a vision, a few business requirements and a smattering of technical requirements.

The diagnosis was that the problem the project was trying to solve was extremely complex.  It was so complex that meetings to discuss requirements bogged down in endless discussions of seemingly infinite details.  The stakeholders and the analysts were all overwhelmed by the complexity.

The solution was to narrow the scope and break it into more parts (good idea) and to elicit the requirements from stakeholders by using a GUI prototype.  A new contractor was selected that had a junior BA with GUI prototyping skills.

Just before the project kicked off, the government insisted that a Senior BA be hired, and this was done.  The junior BA was assigned to facilitate stakeholder meetings and create all the GUI prototypes, and the Senior BA (being the outsider on the team) was instructed to capture notes from the meetings and to produce the final deliverable requirements document. 

As the stakeholder GUI sessions were held, it became apparent that there were misunderstandings between the facilitator and the stakeholders.  The facilitator got trapped in discussions trying to explain the GUI and what it meant.  The facilitator (a GUI expert) was convinced that once the stakeholders understood the GUI concepts that they would agree that the facilitator had gotten it right. Because of the confusion, the stakeholders would insist on GUI changes one week, and then they would insist on reverting to the prior version the very next week.  Everyone was talking at cross-purposes, and intervention by the Senior BA was NOT welcomed.  The Senior BA patiently bided his time, always collecting requirements, regardless of surface chaos.  The contract was to produce a requirements “deliverable”, and as long as that could be done there was no need to insist on intervention – it was enough to offer suggestions and, then let it go.

This went on for weeks, causing great stress to the junior BA.  The Senior BA continued to prepare the requirements for delivery and review with stakeholders, confident that correct requirements were becoming apparent in spite of the debates, and that these could be analyzed and presented in a clear way, eliminating confusion. 

When the time came to present a “to-be” requirements model, the Senior BA was ready.  In one afternoon, after weeks of unending debate, the Senior BA presented the requirements as they were understood from the many “GUI meetings”, but did so without using GUIs – can you guess how?

The nature of the stakeholder discussion immediately changed.  Suddenly the stakeholders were excited to update the requirements and to hold the next review.  While there were still disagreements and frustrations to be worked out, these were now focused on larger, more important issues.  Instead of fighting minor issues related to data “labeling” vs. content, or the difference between a “workflow status” and the work’s physical location, stakeholders were now trying to decide what steps in the existing, broken process needed to change, which steps needed to be eliminated, and which needed to be enhanced.

What was the difference?  How was trust lost by the junior BA, and how could they have gotten it back?   What role could improved listening skills have played in helping the junior BA to get past the misunderstanding?  Would the junior BA alone have been able to complete the requirements without serious errors and gaps, given the confusion around larger issues and too much focus on “small” issues?  The Senior BA did nothing directly to resolve the issues – how were the issues resolved so quickly?

What?  No answers?  Yes, just questions.  If you think you know some of the answers, please leave a comment.

To make up for this slime ball move, making you do the thinking, I offer a free joke (groaning is also best done with a comment, no threats please J):

Q:  Why did the BA cross the road?

–

–

–

–

A:  BOK, bok, bok, bok, bok!

Don’t forget to leave your comments below.