The use of computers in business has transformed not only the way we do business, it also has transformed the way we regard and use computers. The first generation of business computers–early mainframes–were nothing but numbers crunchers. Back then we called what we did "data processing." We took raw data–sales numbers, hours worked, mortality statistics–and used that data to tabulate results we then were able to apply to business processes. The programming languages we used on those mainframes–COBOL and FORTRAN–simply processed data.
I remember writing a payroll program in COBOL. It consisted of a couple thousand punch cards of code, followed by a few cards with tax rates, followed by a couple hundred cards with information on the people getting paid. The output was three or four pages of printed green bar that accounting would use to manually type payroll checks. The computer was doing nothing an individual couldn't have done manually. And COBOL wasn't much fun.
The next generation of mainframes–smaller machines–added the functionality of a database. Data was stored in tables, which conceptually mimicked those big, wide ledger sheets you used to see everywhere. I suppose some readers of this column may not even know what I am talking about. Never mind: Think spreadsheet on paper. The ability to store data on the machine was a major breakthrough.
This was all well and good and certainly was proving the value of the computer in the business world. But it wasn't transforming business. We still were just using machines to do the same work a human could do, albeit a little faster. We still were just processing data by creating point solutions for specific business needs.
Distributed Computing
It wasn't until the 1990s that two things occurred in computer technology that changed the focus from data process to information technology: wide acceptance of the personal computer and the ability to interconnect those computers together comprised the tipping point. Suddenly, we had the ability not merely to manipulate data but to create and share information.
Distributed computing not only transformed business, it transformed the way computers were used. The people who know and understand business process are now the same people interactively working with business data to create information. Giving knowledge workers the ability to work with their data changed everything.
Thanks for the Memories
OK. Thanks for the history of Business Computing 101. What is the point of all this?
I was speaking with a friend this week who told me a story about his organization, which had purchased a high-end and expensive tool to work with contracts within the organization. When the staff people began to configure this powerful tool for use, they discovered they could not even reach agreement on what constituted a contract–and therefore, what documents or information even would benefit from the workflow engine.
And that got me thinking about one of the issues I deal with day in and out: information architecture (IA). Businesses are so complex and create and store so much information they lose sense of what information they actually possess. And the corollary to that is they lose a lot of the advantage they have gained by creating an environment that allows efficient interactive distributed computing. Most organizations need a complete assessment of their intellectual properties, the information they have stored "somewhere," all the myriad programs and process they use to access that information, and how all of this integrates with business process.
IA and the Intranet
Information architecture often is referred to only when designing or analyzing intranets or Internets. In that use, it is a way of classifying and organizing information and processes in such a way they can be easily accessed. Typically workers interact with information systems in two ways:
They access, manipulate, store, and share information as it pertains to their job function. Each department, division, or business unit has certain processes it uses to provide value (and thus revenue) to the business as a whole. We can classify this interaction as "private" or "departmental."
Workers also need to access information that lies outside the scope of their job description but is nevertheless critical to the health of the business as a whole. For instance, all workers may need to access their personal records to update their dependent information or change their 401(k) contributions or for countless other reasons. We can classify this information interaction as "public." Thus, corporate intranet often is designed using these basic concepts of "public" and "private" information that must be surfaced to the appropriate individuals or groups of individuals.
Another aspect of information architecture is based on the dichotomy between organization and function. The most obvious way to classify information is to base it on the corporate organization chart. Strictly adhered to, an information architecture based on organization would create islands of information that are unique to each business unit.
Of course, this isn't the way we work (or at least I hope it isn't the way you work). Workers' daily business lives are dictated by performing various tasks, and those tasks or functions typically cross one or more business units. An information architecture based solely on function would result in a web of functional interconnections with no organizational foundation. Neither one of these is desirable. The best information architectures are built on an understanding of the organization of the enterprise as well as the things workers really have to do. Good information architecture is half science, half black magic.
Global IA
What I am proposing we need to do is extend the whole concept of IA away from the intranet or the Internet and examine the information architecture of the organization as a whole. Only then can we truly understand how to provide efficient information systems that will serve that architecture.
This is not an exercise for IT or corporate communications or marketing. This is an exercise for the entire organization. Once we have a map of the current state of information, we then can analyze and recommend the best ways to implement systems that will maximize the use of current information while providing a way to best organize and maintain that information for future use.
Taxonomy Is Not About Bugs
Each functional business unit needs to make an assessment of the information it creates, the information it consumes, the information it provides others, and the information it controls but doesn't fit into the first three buckets. It then needs to list all the tools it uses to interact with that information–and that means everything from office productivity tools to enterprise database tools to instant messaging. In effect, we are asking business process owners to perform their own systems analysis. Now, ideally, we will provide guidelines and staff to facilitate this analysis, but at the end of the day, the map needs to come from the business units.
The next step is to classify the information or data–and that is dependent upon a corporate taxonomy, which means nothing more than classifying data or information. Properly classified information can be more easily located or discovered. The Dewey Decimal System is the first taxonomy system most of us are exposed to. We create a corporate "language" when we create taxonomy. My friend above was in an organization without a well-defined taxonomy. Had it had one, it would have known not only what was and was not a contract but also what metadata is associated with a contract.
All About the Metadata
Taxonomy and information architecture walk hand in hand and also depend on each other in a kind of feedback cycle. As we learn more about the information used by our organization, the better we are able to refine and define our taxonomy. It should include defining what could be called enterprise information types–things such as contracts or purchase orders or RFPs. These information types should have discoverable metadata associated with them. Metadata both allows us to classify and store information in a logical manner based on that metadata and allows us to search easily and effectively for a particular bit of information based on that metadata.
So, we now have the results from a business unit. And let's make sure the definition of a business unit is fairly granular: "Accounting" or "finance" are way too broad. Depending on the size of your organization, even "accounts receivable" may be too broad. The business unit that is analyzing itself should be able to define itself by a particular business process (even though it actually will use more a single business process).
Once the information and the tools used to do something with that information is defined, we begin the black magic. The best way to try to make sense of all this is with index cards or sticky notes. Each type of information next is placed on a white board or its equivalent. The current inventory of tools then is used to connect or classify each type of information. It may be a little ugly at first, but at the end of the exercise, what we are left with is a map of the information a business unit uses and the tools by which it uses that information.
The output from the functional business units then is combined with others in its silo. Understand that even though accounts receivable and accounts payable will roll up into the finance silo, all relevant data, information, and tools will not be contained within that silo. In fact, what you will discover is you can identify new "silos" based on common functionalities that are not necessarily owned by any business unit. Once the functional silos begin to surface, you are beginning to understand your existing corporate information architecture.
Magic
Now comes the fun part. Having identified your existing IA, you can start to work your black magic by designing an information architecture that will replace the existing one without destroying or making more complex any of the current business processes. It actually is a separate exercise to determine whether the business processes themselves are flawed and require restructuring. The obvious things are dealt with first: information identified as existing on a file share or processed via e-mail are easy pickings. Refining taxonomy based on the current IA is another first step. One-off point solutions are identified for replacement or consolidation. Critical path information probably is going to be recommended for retention in a content management system. Holes in Sarbanes compliance are identified and fixed. And so on.
This is an iterative process. It is also a dynamic process. Information architecture is the work of the entire enterprise, but it must be driven by IT. Business units often cannot see beyond the limits of their own silo. It is our job to help them see beyond that horizon. TD
© Touchpoint Markets, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.