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.                              

Advertisements

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.        

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.