>Common Language for Enterprise Architecture

>

What happens when one set of enterprise architects can’t read another’s enterprise architecture “artifacts”?

This may sound ridiculous, but this is a very real problem at the Department of Defense (DoD) and at many other agencies.

Government Computer News, 1 February 2010, has an article on “Primitives and the Future of SOA” about how “DoD looks to develop a common vocabulary to improve system design.”

Dennis Wisnosky, the chief technical officer at the DoD Business Transformation Agency came face-to-face with this problem:

“We were building a business enterprise architecture when the whole team changed because the contract [that the work was being performed under] was won by different people…The new company came in and, all of a sudden, their people had different ideas for how the architecture should be built…Their way might have been a good way, but we had already invested hundreds of millions of dollars in another way, and it seemed to be a wiser course of business action to get these new people to learn the old way.”

Mr. Wisnosky tackled the problem head-on:

Like the periodic table of 117 core elements that make up everything in our world, Mr. Wisnosky set out to build the DoD architecture using a set of primitives or basic building blocks. “Primitives are a standard set of viewing elements and associated symbols” based in DoD’s case on the Business Process Modeling Notation (BPMN)”—a graphical representation for processes in a workflow. Armed with the set of primitives, DoD was able to get “the business process architecture, so that they are described in a way that the meaning of this architecture…is absolutely clear to everyone.”

Wisnosky aptly compared using a common language (or set of primitives) for EA, so everyone could read and understand it, regardless of their particular EA methodology to how musicians anywhere in the world can read standard music notation and similarly how electrical engineers can read electrical diagrams based on standards symbols.

This is a big step for EA, where traditional architecture artifacts are not as user-centric as they should be and often leave their readers/audience questioning the purpose and message intended. In contrast, the use of a common EA vocabulary and set of symbols is right in line with developing a user-centric enterprise architecture that is easy for users to understand and apply, because once you know the standard set of primitives you can read and understand the architecture better than an architecture based on a proprietary or ever changing vocabulary.

As Wisnosky points out, primitives are also a nice fit with Service Oriented Architecture, because you can use primitives or patterns of primitives to represent standard business processes and these can be used over and over again for the same services that are needed throughout the business.

This use of primitives for business process notation is consistent with the use of the National Information Exchange Model (NIEM) for information notation. “NIEM enables information sharing, focusing on information exchanged among organizations as part of their current or intended business practices. The NIEM exchange development methodology results in a common semantic understanding among participating organizations and data formatted in a semantically consistent manner. NIEM will standardize content (actual data exchange standards), provide tools, and managed processes.”

While, we need to leave a certain amount of flexibility in EA for architects to apply their trade to meet specific agency requirements, there is a huge benefit to standardizing on a common vocabulary, so architects can speak the same language. This concept is all the better when the language and design methodology selected for EA is simple and clear so that even non-EA’s (our regular business and IT people) can read and understand the architecture.

Building EA with primitives and clear and simple vocabulary and design represents a user-centric EA moment that I for one, applaud loudly. Another way to say this is that an EA without primitives is a primitive EA.

>What It Means to Get Madoff-ed

>”Saying he was ‘deeply sorry and ashamed,’ Bernard Madoff pleaded guilty Thursday to pulling off perhaps the biggest swindle in Wall Street history and was immediately led off to jail in handcuffs to the delight of his seething victims. Madoff, 70, could get up to 150 years in prison when he is sentenced in June.” -Associated Press

In enterprise architecture, defining data terms and usage is very important. So everyone is talking the same language!

Well with Bernie Madoff’s plea of guilt to all 11 charges against him today involving a $50 billion Ponzi scheme (named after another financial crook), I believe are witnessing the birth of a new word in the English lexicon.

Here on in, Madoff will mean:

-verb
to swindle, cheat, defraud, deceive.

-noun
a person who swindles, cheats, defrauds, and deceives.

Congratulations Bernie, you lousy Madoff!

Another way to think of this new word…
he MADe OFF with a lot of people’s hard-earned money.

>John Zachman and Enterprise Architecture

>In the Journal of Enterprise Architecture, February 2008, John Zachman, the father of EA, talks about core definitional elements of enterprise architecture.

  • Enterprise versus IT or Applications Architecture—”First Enterprise Architecture constitutes a paradigm shift and many people have not yet been inclined to make the mental, cultural, and behavioral adjustment to engineering and manufacturing the enterprise” and I love that phase—engineering the enterprise!

“Because…many of the skills required to the work of enterprise architecture are typically found in the Information Systems community, some people misconstrue the Framework intent as an Information Systems schema rather than its true intent as an ENTERPRISE schema.”

And not only is the Zachman Framework misconstrued as an Information Systems schema, but many people mistakenly confuse the whole EA with IT or applications architecture. But EA is not focused on IT or applications, but rather on the overall organization—the enterprise.

  • Lexicon—“As global communication and collaboration expands, there is an increasing requirement for semantic coherence. If people’s words do not mean the same thing, there is neither communication nor collaboration”—another good one, semantic coherence!

Without a lexicon with common definitions and standards for usage, we will not be talking to each other, but past each other.

Moreover, if we can’t even define EA elements in a common way, then how can we ever make them interoperable?

As Zachman says, “The underlying classification and components of architecture must be consistent for any interoperability (internal or external) to be effected.”

  • Classification, Taxonomy, and Ontology—“Enterprises are complex. Managing the knowledge base of the enterprise that is required for enterprise operation and change is complex. The key to managing complexity is classification.”

This is so true. We need to categorize and relate items to make sense of them. Moreover, I would say we need to roll this information up to what I call the profile level—the big picture, strategic view using information visualization—so that our executives and decision makers can quickly understand the information and come to a decision point.

“Humanity for seven thousand years has found no mechanism for accommodating complexity and change other than architecture,” says Zachman.

EA is the way to plan, manage, and measure change in our increasingly complex world. And if we don’t take control over our enterprises and their future destiny, then we will be controlled by them.

>Leetspeak and Enterprise Architecture

>

Leetspeak is the new online language of the internet world, where words are misspelled (based on striking neighboring letters to the correct one) or symbols or numbers substitute for similar-looking alphabetical letters. So for example, leetspeak could be written as 133t 5p34k.

The Wall Street Journal, 23 August 2007 reports that “leetspeak stemmed partly from wanting to find faster ways to express themselves online. As with other forms of jargon, it also enhanced a sense of belonging to a community.”

Leetspeak, as the new lexicon for the hip and cool of the internet generation, represents a way of communication faster and expressing oneself better (although many would say this is actually worse) in the sense that you do not limit yourself by grammar, capitalization, or punctuation.

In User-centric EA, lexicon is a critical component of developing an enterprise architecture. The basis for information discovery, exchange, and overall sharing is that there is a common lexicon that we use with common definitions and standards for usage. Metadata (or data about data) helps us develop these standards to facilitate information architecture. So while leetspeak is cool and maybe convenient, I think even some of our super computers may have a hard time deciphering it.

So do you think there a place in EA for leetspeak?

>Tower of Babel and Enterprise Architecture

>

“And the whole earth was of one language, and of one speech…and they said, go to, let us build us a city and a tower whose top may reach unto heaven…and the Lord said…the people is one and they have all one language, and this they begin to do, and now nothing will be restrained from them, which they have imagined to do…[and he] confounded their language, that they may not understand one another’s speech. So the Lord scattered them abroad from then upon the face of all the earth.”

Am amazing story from the Torah (Bible)!

As an enterprise architect, some lessons that are striking to me are the following:

  • LEXICON: When everyone has a common language or lexicon (something we strive for in EA), “nothing will be restrained from them, which they have imagined to do.”—i.e. with a common enterprise lexicon, data standards, and mechanism for discovery and exchange, we can do great things and our imagination is the limit.
  • EA PLANNING: When everyone functions together (“the people is one”) to undertake a tremendous task (such as building a city and a tower), they can really get things going. As the adage states: there is power in numbers. From an enterprise architecture standpoint, when the enterprise is unified in its planning and governance, they can achieve amazing business and technical feats.

A major question that I am left with is…

Why is G-d displeased when people work together, communicate (the same language), and undertake to follow their imagination (have a vision) and achieve great things (“build a city and a tower”)?

From a religious didactic stand point, I understand that G-d wants us to be humble and not think that we have any real power to take on these tasks without him! And that we have to recognize and worship him (where all power and vision ultimately comes).

From a User-centric EA perspective, the ideals of unifying the organization towards common business and technical plans, goals, standards, solutions, lexicon, and so on, helps us build a better, stronger organization that can achieve great things (as long as we always remember that we are doing HIS bidding).