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 Maturity and I.T. ROI

I spent the beginning of my morning preparing for an ISV Product Assessment Deep Dive and reviewing some old Gartner group reports.  I’m an Industry Analyst for two Research firms in my off time.   As I scanned the graphs in the Gartner report I noticed an interesting trend from year to year.  The amount of I.T. budget spent on business transformation – pundit-speak—for improved capabilities for the business continues to shrink, while infrastructure and maintenance costs continue to rise.  The figures quoted for 2003 were 19% for transformation.   During the 1970s new application development –old category name for business transformation—was hovering between 30% to 40%.

The interesting issue around this fact is that vendors are all over talking about virtualization and cloud, yet when I look at the benefits of both they’re focused around reducing the hardware maintenance and platform cost footprint.  Oddly enough that’s one of the least costly items in the budget.  A simple Pareto Analysis suggest developing and working on means to reduce software, specifically application,  maintenance costs would give a better payback.  Simply put a reduction of 10% of 90% is more than a reduction of 40% of 20%.

Hopefully Cloud vendors and tool purveyors will crack tat nut.  I am hopeful given enabling technologies such as AgilePoint and Concatenate.  However that presupposes I.T. organization move up the food chain from 1990s design patterns to present day.  A recent spot check has too many customers using SharePoint as a web frontend to a shared drive.  Simply put many organizations are managing files not information.

Last month I kicked off a project to produce a White Paper: From File Management to Information Management an organizational maturity road map.  During the SharePoint Salon in Anaheim this month many of the participants contributed towards that body of knowledge with the intent of developing a practice based on a sound body of work.  Hopefully the next Salon I hold in a few months will advance the discourse as much as the previous ones have.        

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

Search and Navigation: Taxonomy Usage

Started reviewing my notes from deep dives I conducted at SharePoint 2011 conference last week.  As I focused on the data I continue to brainstorm about revising the SharePoint ISV Partner Ecosystem Taxonomy. 

While the current framework matches the SharePoint 2010 Wheel, the categorizations distort the core capabilities of many of the ISVs.  

The Framework’s secondary level category “Search” is used in the very broad sense which strikes me as a semantic dissonance that navigation is subsumed in that taxonomy.  My belief is that search and navigation are two sides of the same coin; retrieval methods. 

Searching suggests a wide net then filtering down and sorting; while navigation infers production rules to either predict where a member will be or the path where a specific type of member should reside. 

The first methods use keywords and possibly syntax as means to identify membership.  The second has a classification schema which surfaces some aspects of the semantics of the organizational system the author created and is used for direct storage and retrieval in context.  An example of such a simple list:

  • Black
  • Brown
  • Red
  • Orange
  • Yellow
  •  Green
  • Blue
  • Violet
  • Grey
  • White       

It does not follow the ordered hierarchy of the color frequency spectrum, so it’s not a standard spectrum.  It’s not an alphabetic list of color keywords.  Is this a random list of colors or is there some semantic schema behind the order?

If you have some electronic engineering background you might remember it better with the mnemonic:   Bad Boys Ravish Only Young Girls, But Violet Gives Willingly.  This was used in the 50s to remember the resistance color classification: http://www.hirophysics.com/Labsheet/resis-codes/resis-codes.html    

While I could sort resistors by color irrespective of the meaning behind the classification scheme, I’m likely to arrange these by color frequency.  This would have the resistors organized out of order by electrical application.  It may be easy to do a quick search by causal users, but an electronics engineer or circuit designer would find this a difficult to use such a navigation system.     

Information Management Segment

The area I’m focused on this month information management (IM) crosses the boundaries of several categories in the current framework.  Examples of members in IM are:

  • Wand
  • Concept Searching
  • Pingar
  • BA-Insight

Wand, ConceptSearching, Pingar  and BA-Insight all appear under the secondary wheel categorization under search.  A tertiary classification would have Wand, ConceptSearching and Pingar listed as Linguistic and Sound Semantics, however, a deep dive would show these products are fundamentally different.  As a result I am theorizing the following revision to this branch of the taxonomy as follows:      

  • Navigation Schemas
  • Organization  Generation [Taxonomy]
  • Content Classification
  • Semantic Analysis
  • Visualization
  • Navigation

This is my current working sub classification as I continue my deep drives which is subject to change based upon feedback and additional analysis.

SharePointDirections Reports

Fresh back from SharePoint 2011 Conference, SharePoint Salon, SharePoint Sushi; now I am fired up.  During the conference Owen Allen and I discussed framing a series of reports for SharePointDirections to produce after October; that’s the easy part.  Now I’m assembling information on ISVs that I gathered during deep dives with each. 

We’ll be revising the SharePoint EcoSystem Map during November for publication on the SharePointDirections website.  The map will take on more of an Enterprise flavor given SharePoint’s acceptance as an Enterprise level platform with the introduction of 2010.   The first report under consideration will cover the information management segment, followed by the process and workflow segment.  However, I’ve yet to schedule deep drives with ISVs in that segment.

Our goal is to provide a qualitative assessment of products in each segment initially, position them on a grid to help clients make informed decisions, and eventually perform a qualitative analysis on each.  I know that later is a big task, participating in similar activities in the engineering software market.  Check out Cyon Research.  

In the meantime my personal Blog will still continue exploring concepts and issues around Enterprise Architecture as well as a collaboration area with peers.             

Information Management: Taxonomy creation methodology

Made more progress on Taxonomy creation methodology yesterday on several front.  Enlisted several peer to collaborate or comment of the core aspects of developing a system to determine taxonomy approach; Richard Harbridge and Ruven Gotz.   I was pleased that Richard had picked up my recommendation and read Patrick Lambe’s Organizing Knowledge.  It gives use some common ground to discuss going forward. 

The materials Lambe covers look to drive core of the methodology.  Richard and I discussed the design of the methodology and agreed on next steps he’d take on.  He pointed out developing key questions to help make assessments possible was a key component and volunteered to develop such.  I’m working on the translation of those questions into matrices.  We had initially some disagreement on whether the results should be a set of matrices or a gradient scale.   We resolved that issue as just a presentation option that consultants can select as per their preference.

The system design appears to have the same pattern as the marketing management process (MMP) I reengineered for IBM ten years ago.  I guess I shouldn’t be surprised by that as the nature of both problem spaces have similar attributes; both have elements of unstructured and structured knowledge. The mechanisms I used for MMP included: multiple routes through the process; a capability maturity model; ISO9000 verification and validation; and several six sigma measurement methods. 

The key concern both Richard and I share about formalizing an approach is avoiding creating a technical religion with a priesthood. However, I’m sure we can avoid establishing such by putting the approach in the public domain.  As we progress I will continue to post the results on this Blog which is covered by the Creative Commons License or on Microsoft’s Office Templates Online for free downloads.  The only restrictions I believe my collaborators agreed on and I have on reuse are spelled out in that license.  Basically we want to ensure credit is given to those that have either directly contributed or contributed through their published works (e.g., Partrick Lambe, etc.)

Next post will contain the reading list on Information Management topics I’m using.        

Visual Thinking

This morning I started reading “Turning numbers into Knowledge” by Koomey; an interesting book gear more towards academics and researchers than typical knowledge workers.  When I say geared, it’s the style and tone of writing more so than the information contained within.  The book presents a how-to organize your problem solving.  The small amount I’ve read so far had me thinking about the problem of problem solving and if in the scheme of issues it ranked high on an organization’s the Pareto List of critical items to address.  Combing through my various graphical notes

–I typically create diagrams and sketches for notes rather than text; I had found visual note taking and thinking to be more information intensive than typical text when I was studying architecture.  This was later reinforced by a business associate, Eileen Clegg; I met at the Congress on the Future of Engineering Software (COFES) several years ago.  Her company Visual Insights      http://www.visualinsight.net/ is a welcomed regular fixture at this annual event.  I think the one year she missed attendance there were several people, myself included, asking why.  Many of the Engineering and Engineering Software community’s best; the most creative, innovative and productive are visual thinkers.  I can’t recall a single member of this esteemed group that didn’t have to have a whiteboard or some graphical tool suite in order to think or relate information during our conversations.

At first I thought it was because these were complex topics with lots of detail, which each could be.  The diagrams and pictures though were for the most part very simple, no more than a few simple lines, circles and arcs, etc.  However, like the Chinese saying “One picture is worth a thousand words” these minimalist sketches were very dense in the information they chaptered and represented.–        

 I bring up graphical notes as to indicate that during my career, as I’ve taken notes, I have captured in my graphical journaling much more details than just the issue that was to be address at the time.  Many times I would capture the process of how the group solved the problem or made the decision.  The various projects I’ve been involved with regarding reengineering processes for Rockwell, Boeing, Microsoft, IBM, Samsung and a host of small companies has introduced me to multiple graphical techniques.  Even as I write this post this morning I find myself drawn to mindmap my thoughts as opposed to writing out these ideas.  Writing –as skill I’m trying to improve upon these past few years—is basically one dimensional while my thinking in multidimensional so relationships between concepts are lost in translation as I peck out the words.  Thankfully Hypertext had been created, so I can come back at a later date and establish those relationships.  This has become a long way around and may still have some missing links between my initial thoughts and the insight below, but I’ll come back at a later time and address that bridging issue.

 What I discover –again, which was the rationale for creating Intellectual Arbitrage Group—was that most problems companies are addressing are the same.  What makes them appear different is the context in which they live.  The majority of the activity people in organizations perform is not really deep problem solving but daily searching and translation to the context they’re working in.  Some of the interesting issues around that is identifying the core solution set.  Often because problem/solution pairs are not well documented, people will take the closest solution metaphor at hand to use.  This from my findings is one of the root causes of project failure as opposed to technical failure.  So the end results of many projects are technical success but not achievement of business objectives.

 The cause of this misalignment and how to avoid such will be the topic of future post as I continue to diagram out a working Information Management Methodology.