Saturday, July 19, 2008
How to fix IT
"But the consumers at home are also our employees at work. And when they arrive at their desks, they bring a new set of expectations that have been shaped by their experiences with the Internet, cell phones, email, mobile hand-held devices and iPods. These and other innovations have changed the way they consume and interact with information."
- Daniela Barbosa in "The Taxonomy Folksonomy Cookbook", available at http://solutions.dowjones.com/cookbook
One thing is certain: if Information Technology departments continue to perpetuate the status quo - if they continue to conduct business in the way they always have - the problems I discussed in my previous post will be exacerbated; the general utility of IT will continue to decline. In order to break the cycle, IT must change from within. As I said before, this is psychology, not technology.
- IT must adopt a decentralized approach and architecture.
- Core IT staff focus on providing api's, security, data models and business rules.
- Core developers working on corporate-wide applications; ones that will be used by nearly everyone in the organization.
- Developers working on specialized apps that require read-write access to the core databases.
- Developers working on specialized apps that add or improve on existing data.
- Developers working read-only apps, local annotations, and reporting.
- Push information processing tasks toward the user.
- Utilize department-level programmers. These are the people who are outside of the purview of the official IT department, yet still know how to build basic applications. In any organization of appreciable size, they're already there and they are eager to show what they can do. Allowing them to work will alleviate much of the load on the core developers.
- Give users generative tools that will allow them to solve their own problems. Just like the availability of word processors destroyed the notion that typing was something that happened inside of the typing pool, appropriate tools would destroy the notion that programming is something that happens exclusively inside the IT department.
- Graft onto existing, known tools. Organizations are run via ad-hoc, user-created spreadsheets and documents. We need to figure out how to use these documents as interfaces into systems, rather than containers of data. For example, if a copy-and-paste operation could be treated as a pointer to a bit of data, a document created through a series of these operations would become a living document that would update itself whenever those data sources changed. Users have caught on to what copy and paste does; they will understand the difference between that and a pointer to live information, given the right training.
- Training. We do live in the Information Age and ignorance of the basic tools of such cannot be accepted. In addition to basic computer knowledge and system-specific training, some users need to be trained on high-level information processing issues. Things like:
- How to recognize when a task should be automated.
- What kinds of tasks can be automated.
- How to use the tools available to them to solve their own problems.
- Flexible tools & systems.
- Allow for annotations, tagging & user-generated customizations.
- Make all data searchable from outside the application.
- Allow data to be remixed.
- Allow data to be easily extracted.
Out of all of the recommendations that I am making, this is probably the toughest change to make. Changing technology is easy. Changing thought patterns is hard. Nevertheless, it is the essential starting point.
This step is predicated by the realization that the act of processing information not the sole purview of IT. Everyone does, in some way or another; IT just happens to use formalized systems to do so. The structure of the IT department needs to reflect this - IT must become more of a "gravitational centre" than a fortified embankment. I suggest a layered approach with decreasing privileges:

This model pushes development activity out toward the end users and allows IT staff to concentrate on caring for an 'information ecosystem' that will better serve their organization.

In the most excellent article (Ontology is Overrated), Clay Shirky points out how using rigid categorization systems to organize information often doesn't work very well. I believe this conclusion applies to most top-down methods of organization. Real life just doesn't fit into neat compartments and real-world data doesn't cleanly fit into predetermined categories. Trying to predict at design-time all possible uses of an application's data is a fool's errand. Systems must be designed to not only accomplish their primary objectives, but to also:

A few years ago Nicholas Carr wrote "Does IT Matter?". While I feel that the provocative title is somewhat misleading, I have to agree with his conclusions. As it is practiced today, IT is too inwardly-focused, too unwieldy and unresponsive. Most IT departments seem to think that the next multi-million-dollar rollout is going to be the silver-bullet panacea that will fix their problems. That just isn't going to happen. IT's current problems are systemic and to paraphrase Albert Einstein, they won't be solved with the same level of thinking that created them.
Comments:
Links to this post:
<< Home
Thanks for kicking off this post with my quote! And i hope you agree that hybrid approaches are appropriate as well.
I like what you write about leveraging department-level programmers. There are also secondary level business users that can be leveraged if the tools are correct. For example Mashup tools are said to be seen as an enabler but honestly i have not seen the adopter as quickly as i would have predicted. Here are some of my thoughts on the subject- maybe the tools are still not there:
http://danielabarbosa.blogspot.com/2007/05/mashups-in-enterprise-challenges-and.html
I like what you write about leveraging department-level programmers. There are also secondary level business users that can be leveraged if the tools are correct. For example Mashup tools are said to be seen as an enabler but honestly i have not seen the adopter as quickly as i would have predicted. Here are some of my thoughts on the subject- maybe the tools are still not there:
http://danielabarbosa.blogspot.com/2007/05/mashups-in-enterprise-challenges-and.html
Thanks for commenting Daniela.
In Clay's article that I linked to, he talks about when rigid categorization schemes work (small corpus, formal categories, stable entities, restricted entities, clear edges). Those are pretty good guidelines for a strict ontological base. I don't see this as an either/or situation; both approaches complement each other.
I don't see much for tools aimed at the secondary level business user (or departmental programmers). It's a chicken-vs-egg situation. Software vendors don't have any reason to develop tools for an infrastructure that doesn't exist, and organizations don't have any reason to create an infrastructure that will enable users to employ tools that don't exist yet.
Post a Comment
In Clay's article that I linked to, he talks about when rigid categorization schemes work (small corpus, formal categories, stable entities, restricted entities, clear edges). Those are pretty good guidelines for a strict ontological base. I don't see this as an either/or situation; both approaches complement each other.
I don't see much for tools aimed at the secondary level business user (or departmental programmers). It's a chicken-vs-egg situation. Software vendors don't have any reason to develop tools for an infrastructure that doesn't exist, and organizations don't have any reason to create an infrastructure that will enable users to employ tools that don't exist yet.
Links to this post:
<< Home
