The Governance Air Craft Carrier: Too Big to Sail?
August 31, 2011
In a few days, I disappear into the wilds of a far off land. In theory, a government will pay me, but I am increasingly doubtful of promises made from 3,000 miles from Harrod’s Creek. As part of the run up to my departure, we held a mini webinar/consultation on Tuesday, August 30, 2011, with a particularly energetic company engaged in “governance.” (SharePoint Semantics has dozens of articles about governance. One example is “A Useful Guide to SharePoint Success from Symon Garfield”. The format of the call was basic. The people on the call asked me questions, and I provided only the perspective of three score years and as many online failures can provide. (I will mention SharePoint but my observations apply to other systems as well; for instance, Documentum, Interwoven, FileNet, etc.)
What I want to do in this short write up is identify a subject that we did not tackle directly in that call, which concerned a government project. However, after the call, I realized that what I call an “air craft carrier” problem was germane to the discussion of automated indexing and entity extraction. An air craft carrier today is a modular construction. The idea is that the flight deck is made by one or more vendors, moved to the assembly point, and bolted down. The same approach is taken with cabins, electronics, and weapon systems.
The basic naval engineering best practice is to figure out how to get the design nailed down. Who wants to have propeller assemblies arrive that do not match the hull clearance specification?
What’s an air craft carrier problem? An air craft carrier is a big ship. It is, according to my colleague Rick Fiust, a former naval officer, a “really big ship.” Unlike a rich person’s yacht or a cruise ship, an air craft carrier does more than surprise with its size. Air craft carriers pack a wallop. In grade school I remember learning the phrase “gun boat diplomacy.” The idea was that a couple of gun boats sends a powerful message.
What every content centric system aspires to be. Some information technology professionals will tell their bosses or clients, “You have a state of the art search and content processing system. Everything works.” Unlikely in my experience.
Governance or what I like to think of as “editorial policy” is an air craft carrier. The connotation of governance is broad, involves many different functions, and sends a powerful message. The problem is that when content in an organization becomes unmanageable, the air craft carrier runs aground and the crew is not exactly sure what to to about the problem.
Consider this real life example. A well meaning information technology manager installs SharePoint to allow the professionals in marketing to share their documents, price lists, and snippets from a Web site. Then the company acquires another firm, which runs SharePoint as well as a handful of enterprise applications. On the surface, the situation looks straight forward. However, the task of getting the two organizations’ systems to work smoothly is a bit tricky. There are the standard challenges of permissions and access as well as somewhat more exotic ones of coping with intra-unit indexing and index refreshes. Then a third company is acquired, and it runs SharePoint. Unlike the first two installations which were “by the book”, the third company’s information technology unit used SharePoint as a blank canvas and created specialized features and services, plugged in third party components, and some home grown code.
Now the content issue arises. What content is available, when, to whom, and under what circumstances. Because the SharePoint installation was built in separate modules over time, will these fit together? Nope. There was no equivalent of the naval engineering best practice.
Governance, in my opinion, is the buzz word slapped on content centric systems of which SharePoint is but one example. The same governance problem surfaces when multiple content centric systems are joined.
Will after the fact governance solve the content problems in a SharePoint or other content centric environment? In my experience, the answer is, “Unlikely.” There are four reasons:
Cost. Reworking three systems built on the same platform should be trivial. The work is difficult and in some situations, scrapping the original three systems and starting over may be a more cost effective solution. Who knows what interdependencies lurk within the three systems which are supposed to work as one? Open ended engineering projects are likely to encounter funding problems, and the systems must be used “as is” or fixed a problem at a time.
Expertise. When multiple systems like our three SharePoint implementations are to be integrated, some of the problems are difficult. Specialized expertise may be needed. A partial solution or one that triggers unexpected downstream issues adds to the challenge. Mistakes based on inappropriate or shallow expertise are particularly tricky. Remediation may add to the expense of the project.
Work flow. Employees develop methods of working that are often different from what a work flow expert or a system designer wanted, anticipated, or expected. When employee behaviors are adapting to real time challenges, the engineering team trying to impose “governance” find themselves building a turret where one is not needed. The engineers may have a prize winning bridge from a design point of view. From the users’ perspective, the turret 1is irrelevant.
Reliability. In my experience, governance teams can develop policies, procedures, and methods. Most of the governance projects I have reviewed contain two significant time bombs. The first is that the theory looks great on paper but fails in practice. The idea that marketing will check with the engineering team before creating specifications for a Web page sounds great. The communication often consumes time and all to often, marketing just goes with what it has. The flip side is revealed in the breezy Google centric “I’m Feeling Lucky.” Engineers just change the marketing lingo, often surprising the marketing time. Either way, the governance method is not reliable. The second problem is that people just do what makes sense at the time. Management gurus talk about pushing decision making down into the organization. How well is that working for commercial organizations right now? Governance is not applicable to decisions made based on situational inputs. What suffers? Reliability.
Is integration possible? Yes, and I think one path worth exploring is the use of cloud based services. Many organizations are unable to manage their existing computer and software systems. A cloud service allows an organization’s management to slap a service level agreement on a third party and trim the in house information technology costs.
Will a governance project bring order to information chaos? Based on what I learned in the call on August 30, 2011, I am not sure. When an organization embraces governance, the problem may already be too big to manage.
One might be able to commission a governance project, but when it is complete, it may be too big to sail. What do you do with an unusable air craft carrier? Scrap it.
Stephen E Arnold, August 31, 2011
Sponsored by Pandia.com
Comments
One Response to “The Governance Air Craft Carrier: Too Big to Sail?”
-
- Subscribe to Beyond Search
Feature archive
News archive
-
[…] a basic factor of all types of technologies such as craft, engineering, routine, and non-routine.Information technology (IT) refers to the management and use of information and facts employing comp…is applied broadly in enterprise to refer to anything that ties into the use of computers. Mostly […]