Enterprise Architecture: The more we change, the more we stay the same

Last evening I started reading Business Architecture, Ulrich & McWhorter.  I was amazed at seeing the concepts I once extolled over a decade ago in my ZIFA presentation in print.   My mentor John Zachman back then had asked several provoking questions prior to then.  One was just confirming completeness his model of IT Architecture.  This was when time and motivation columns where not part of the framework.  We had several days’ discussion about what do time and motivation artifacts look like.

I would fall back to my dwelling architecture career of the past to answer; building schedules to name one, project plans to name another; both are concern with time or precedence of activity.  But is it important enough to be a dimension John asked.  It fits the reporter’s interrogatives: Who, What, Where, When, Why and How that I believe should be the columns.  “Did you ever think how hard and expensive it is to put a roof on a building without walls or a foundation.  It can be done, but it’s costly.”

The next one had to do with span and depth of Architects.  This was one of the most enjoyable discussions I had with John.  I had brought an old Architecture text book, creating architectural theory, Jon Lang.  In it Lang had described different levels of design, the span and granularity that architects of various types dealt with.  An Urban Planner is not about to design your house and his work products are likely to affect people for generations, look at how various city growth patterns.  These were established decades ago.  

Enterprise Architecture is much the same way.  Many corporations’ architectures are still the same, despite the addition of information technology.  These companies may or may not need to change depending upon the ecosystem they reside in.   However, as ecosystems start to interact with other ecosystems –think globalization—business models and architectures are exposed to others which may be more competitive.  Consider the “Japanese Auto Invasion of the 70s”, was it cheaper cars though cheaper labor as the Detroit elite suggested or was the old mass production model breaking down in the like of a different business model.  History now confirms the later.                  

When I present on Enterprise Architecture around the global, I still use the analogy of dwelling architecture.  The example I typically use to differentiate architecture from design and there is a difference is the various Gothic Cathedrals.  If you overlay them on top of each other each is different.  So it’s not the stone, glass and wood, but how you use these that determines an architecture.  These rules (Design Strategy aka Architecture) determine how the components relate to each other as well as usage of these as a system.

Going back to my technology example, consider the telegraph.  During its introduction it changed how business work around the nation and eventually the globe.  Now consider the next advance in communications technology, the telephone.  Initially productivity didn’t increase with its introduction.  Why?  Consider the old –in the relative sense—paradigm of the telegraph in business usage.  A business owner or manager would dictate a memo to secretary; she would courier it over to the telegraph office where it would be translated into dots and dashes; at the other end the dots and dashes would be translated back to text; couriered to the recipient business’s secretary who would read it to the business person.   Enter the phone; a secretary would take dictation then call the business at the other end, the two secretaries would exchange pleasantries and then dictate the information; which was then either handed to the other business owner or read to him.  During each of this information exchanges misunderstanding and transcription errors could occur.  A simple business transaction could take several days of back and forth.

It wasn’t until two business people broke the model and spoke directly to each other that a competitive advantage ensured.  Those business people that used the technology in a different way become more competitive.

Back to Ulrich & Whorter, they rightfully point out that SOA and Cloud are hyped as the next Holy Grail.  I believe they miss the mark though by tagging vendors and IT groups as the black hats in this story.  These stakeholders are both part of the problem and the solution.  However, business people share a lot of the blame as they continue to look for the silver bullet so they don’t have to think about managing their information or constantly reviewing and revising their business models.  Vendors and IT groups deal with information technology, not information management.  If you substitute drill presses, stamping machines, and an assembly line for servers, networks, databases and browsers we’re back to its not the stone, glass and wood but how you use them.  Vendors and IT shops are good to great at dealing with the mechanics, not so good on defining business models.   This is where Enterprise Architects come into play.  Unfortunately too many EAs are not EAs; they have the title but not the orientation.  They’re just technology or infrastructure architects with an inflated title. 

Failure to understand how to use the new technology in a new way will result in the creation of what my friend John Mancini of AIIM has labeled the Digital Landfill and create more of an Information Glut (think of hardening of a corporation’s knowledge arteries).         

You know you have an EA on your hands when s/he looks at business models & goals, economics, technology paths, organizational capabilities and how to translate these into a series of state changes for the company.     

What I still see on the horizon is Information Management Maturity.  Today I see signs that some organizations are seeing that need.  2020 Roadmaps talk to managing information more like assets.  Disciplines like Information Architecture while popular are still in its infancy, you’ll hear terms like taxonomy and ontology however, these are just exploratory projects in many corporations.  Technologies like SharePoint that could exploit the design intent that these terms represent are left waiting for the discipline to mature as well as a strategic execution system to deploy. 

    

For those of you wondering, these slides were presented in 1996 at the ZIFA conference

Information Management Methodology: Part 2 – Are you sure Kelly Johnson started this way?

Last week I started documenting the “what” with an eye towards the “how” I’ve used during past engagements.   This post will not be the “how” but will list some of the methods I’ve assembled through the years that will eventually become the “how”.

In the previous post I mentioned listing the forms and other artifacts in an enterprise or quanta as I call these.  I’ve used an abstract term, quanta, for these collections of information as the physical or electronic equivalents bring other biases and aberrations.  I’m only interested in the pure semantics and relationships of this information.  However, to get to these I first have to collect the artifacts.

The technique I’ve used is much the same as those created by Taylor a century ago; observation.  My twist on observation is that I typically submerge myself into the processes that operate on this information.   When I designed systems for the management of aerospace tubing and wire harnesses, I followed the process. However, I followed it from the inside.  What I mean by that was I became the tube.   Not is the physical sense.  I put a post-it note on my forehead and walked the entire process; from when the engineer first was assigned the task to when it rolled of the assembly line and was installed in the aircraft.

Mind you I got a lot of laughs from all those concern.  Some of the management I dealt with was sure I was two steps away from a rubber room.  However, by walking the process I got more direct information and an appreciation of the context of how the information was created and handled.  This is something that is missing from only examining a data dictionary or other sterile reports that contains information about information.  True I will eventually remove some of the attributes as I create my quanta, but that information will be saved and associated with the quanta later.

When I had completed by little trip around the corporation gather this information I charted it out, all the flows to/from, activity steps, state changes and name changes.   Once I had a comprehensive diagram I invited representatives from all the groups associated with the information I just collected to review.  At that time White Boards were not as ubiquitous as they are now.  Instead I had access to a HP plotter, so I created a forty-five foot plot of the information’s journey in the corporation from birth to death.

The interesting thing about the meeting was; first people for the first time –may be ever—got a comprehensive view of the entire journey, second discussions emerged asking why certain information was needed or why it wasn’t available.  In a short three hours –the meeting was scheduled for only one, but people did not want to leave—I had a marked up diagram that not only had more detail (business rules, etc.) about the information but on the fly the group determined how to reduce the process steps, cycle time and non-value add information.

This short project synopsis illustrates the first objective.  Get intimate with the information.  Analysts that handle the information at a distance miss details and insights.  This was illustrated by the fact that all of the reviewers came away with a greater appreciation of what it took to design and manufacture a tube.  Prior to that it was just data passing around, after this point it was representative of a product in some stage of creation.  It was the interface between people and the task they performed.                

Rediscovering Information Management Methodology

About a century ago –no I’m not that old—companies were using advance information management tools called paper, file folders and filing cabinets.   Much of the daily course of business was concern with moving physical parts and products.  The movement and storage of information was also a physical effort; paper and files were routed throughout the organization which contained the information needed to monitor and control the organization. 

A gentleman Frederick Taylor came on the scene.  People either praise him or curse him now as he introduced the practice of scientific management which was instrumental in introducing the management consulting practice.  Later Marvin Bowers of McKinsey fame improved upon the practice. 

Mr. Taylor’s approach seems like a simple idea today, but it radically changed the landscape of industrial work and today is influencing information work (aka Information Worker).  The approach was to find the most efficient step of steps to accomplish a task, document and train others to use follow it thereby optimizing the time to output ratio.

Today we’re posed to accomplish similar automation for workers using information.  The problem that arises is that those in I.T. are ill prepared to accomplish this task.  Sure Developers and I.T. staff can lay down code to create a sequence of steps a computer will repeat at lightning speed till the cpu fries itself in some distant time.   The problem comes into play when you realize most programmers know software, software tools, and hardware, but don’t know your business. 

This is where business architects and analysts come in.  Analysts spend time learning how businesses conduct work and reduce these down to a set of descriptions in a standard language that programmers can further translate into computer-ease.   Architects look identify patterns and replicated them to accomplish similar work across the corporation.  Thus they are for lack of a better term super-analysts.

This entire preamble is to reintroduce a simple concept.  When management consultants where called in years ago, one of the techniques they used was to toss out every form in the place.  Next they would ask staff to create forms only when they needed them and only contain the specific information they needed to accomplish the immediate job.  This had the ability to streamline processes.  The past few decades’ variations of this approach have hit the BPR and IT domains with mantras like “simplify and automate”.  The question become at what level of simplification or generalization should one stop at.

Tonight I’m working on developing two SharePoint implementation architectures which will become these company’s operational infrastructures. [Yes, I’m crazy enough to two projects simultaneously]  Fortunately both are new, small firms, so much of the politics and complexity have not developed yet.

So how to start?  My typical approach has been to identify quanta of information that is produced and used throughout the organization, then document how these are created, distributed, used and disposed of.  Now my data-oriented friends will cheer at that.  However, my process-oriented friends will point out that I’m documented processes also.  And if the rest of my friends across the Zachman Information Architecture spectrum are reading yes, I go through all the columns with special emphasis on why.

Being I’m translating this to a SharePoint implementation, I’ll define these quanta as “Content Types” and define the attributes that are required for each. [My Information Architecture colleague Carol Corneby] will be happy.   This is where translation from business architecture and SharePoint design overlaps and transitions.   SharePoint developers will now start to understand what must be build.  Concepts such as information flows and stores will be converted to libraries –which are nothing but viewports limiting enterprise data to the subset a business person using the system needs—and workflows that are subsets of the business process or the value chain an enterprise manages to operate the business.

The methods for identification and translation of these abstractions and the conversion process is what I hope to eventually explicate this year as I’ve been doing this so long as have other peers like Ruven Gotz that we just do it without a second thought.  As we continue our SharePoint Salons our objective is to accomplish this and disseminate the information to others.                              

Information Management/Taxonomy reading list

Going back through my posts this evening.  Found that I didn’t post the Information Management/Taxonomy reading list I had stated I would.  Here it is in no particular order:

  • Quality Information and Knowledge, Huang, et al
  • Data Smog, Shenk
  • The Accidental Taxonomist, Hedden
  •  Organizing Knowledge, Lambe
  •  Finding the Concept, Not just the Word, King
  • Business Metadata, Inmon
  • Principles of Semantic Networks, Sowa
  • Semantics in Business, McComb
  • Information Space, Boist

Brainstorming weekend: Information Management, ITIL, and SharePoint

Spent part of the weekend at INC500 Banquet to receive award and participating in an interview video sponsored by Chase, the rest of the weekend I continued diagraming concepts on the Information Management Methodology (IMM) I’ve been brainstorming with various peers over the course of the past several months.  My goal is to have the methodology and practice defined by April for release at Share 2012 in Atlanta.   Some of the components of the methodology will include: 

 I’ve a few more days left working on my Using SharePoint to enable ITIL white paper (draft).  I should have draft ready for discussion at SharePoint 2011 conference with the peer group assembling in Anaheim on Sunday the 2nd.   Should be a lively discussion.    

New Methodology/Book Project

After reading Content Strategy for the Web by Kristina Halvorson, decided assembling a book on how to develop an Information Architecture for an Enterprise was doable.   Expect it will take about a year, as simlair efforts I’ve had for Microsoft and IBM to build methodologies took about the same time.

Have started collecting methods, tools & techniques with the purpose of codifying and creating a methodology for Business Oriented Information Architecture.  Basically the prework that should be done before standing up SharePoint site hierarchies, Metatag taxonomies, etc.

I’ll be looking for submissions as well as technical reviewers over the next 12 months

Book Review: Content Strategy for the WEB

One of the missing elements in most Web projects these days is the creation and management of content.  It’s as though  teams think its enough to just put up a container and content will appear. 

During the past year I’ve watch multiple sites stood up with weeks of effort and then try to cram content creation in two days.  The results have always been a disaster.  I don’t know why this is, but it seems a consistent theme.  Good content takes time and effort.  

I’m just finishing up Kristina Halvorson‘s book,  ISBN 978-0321620064, Well worth the read for anyone working with WEB, SharePoint or Information Management in general.   It’s a short, very concentrated read full of good insights on the why and how to’s of managing the Content Development Process.  She doesn’t address the why content is often overlooked, but she does address the process behind creating good content.

Included in her book are references to many other books that dive deeper into specific topics, such as Influencer Marketing, MultiMedia content, and Information Architecture.   I’d call it the Cliff Notes of Content Management.