Monday, September 6, 2010

Enterprise Architecture Top Ten

I think sometimes we lose track of just how much there is to know in our industry when attempting to design a new business solution.  For a moment, let’s put aside all of the business information that is, in and of itself, overwhelmingly complex.

We have architecture options for the user interface of an application, for the business logic, and for database connectivity.  There are options for abstraction, encapsulation, inheritance (multiple, singular, and interfaces), and coupling.  Architects have to select the appropriate solutions for synchronous or asynchronous connectivity, for batch or real-time.

And the list goes on.  In my company we maintain an Architecture Body of Knowledge, which is affectionately referred to as the Architecture wiki.  It contains all of the detail, all the guts of our architecture organized using the Zachman Organizational Model for Enterprise Architecture.  It represents our reference architectures, our dictionary, our goto (can I use that term?) for all things architecture.

But the Wiki can be, in a word, overwhelming.  We have about 300 individuals in the organization that need to reference our Architecture Body of Knowledge.  Over the course of a year, this wiki sees about 45,000 hits.  Do the math and you find that this repository is being referenced all the time.  The numbers indicate that it is a valued resource, which is being referenced again and again.

Imaging trying to learn the English language by reading the dictionary. All the words are there, as are rules for grammar, examples of sentence structure, phonetics, spelling, and punctuation.  Still, no one would think of using a dictionary as a tool for learning the basics.

Top Ten
We have a Top Ten list for internally developed applications, for mainframe applications, for application security, and other architectural areas that could otherwise be tough to navigate and understand.  Now here’s a little secret - we actually developed the Top Ten lists BEFORE delving into the guts of the wiki to flush out all of the architectural details.  We did this because our (your) architecture standards must be usable - and by that I don’t mean that they must be correct, I mean that standards must be understandable by the using community.

If you don’t yet have an architecture repository, or you have one that isn’t generating the activity you’d like, think about how easily your user community (a.k.a. the architects) can comprehend your positions, practices, and policies.  A Top Ten list is a great addition.

Follow by Email