| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 |
||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||
 COLUMN
Customizing our software worlds Warren Kendall Lewis, who entered MIT in 1901, was one of the founders of the field of chemical engineering. His granddaughter, Rosalind Williams, who runs MIT's Program in Science, Technology, and Society, recently published a fascinating book called "Retooling: A Historian Confronts Technological Change."[1]
I've traveled a lot since joining InfoWorld six months ago, but have yet to visit the home office in San Francisco. A number of my colleagues are elsewhere, such as Texas, New York, and Virginia. Like many virtual teams, the "settlement" we inhabit is an artificial world made of business processes and sustained by technology. We're often surprised by how much people care about the architectures of these artificial worlds. Mitch Kapor, for example, discovered recently[2] that there were "substantive points about how replies to [mailing] lists should form the To: address" -- an issue that suddenly mattered when he began to organize a community effort around his new software project, Chandler[3]. Deep convictions about such seemingly trivial things shouldn't surprise us, though. Increasingly we live and work in virtual spaces: mailing lists, teleconferences, Webex demos. We shape these constructs to emulate real-world environments, but we are also shaped by them. And although virtual spaces are made of nothing tangible -- actually, because of that -- it's quite difficult to rearrange the furniture. This all sounds kind of touchy-feely, I know. But if you embark on an enterprise deployment of, say, SAP R/3, these are just the kinds of issues that will keep you up nights. As it happens, Williams had an administrative ringside seat (as dean of student services) during MIT's own SAP deployment, which was undertaken as part of a major business process re-engineering effort. Inevitably, some of the assumptions built into the software did not match the reality of the business. The "social structure" of purchasing was one such mismatch. In business, purchasing is normally handled by financial specialists, Williams says, but in a university environment, that task can devolve to postdocs and grad students. Granting them purchasing authority would cut across the grain of SAP's authorization system. The problem wasn't just that SAP's financial system didn't match the specific needs of universities. During this period SAP was also developing university-specific software, but Williams says MIT's curricular rules were not readily adaptable to it. When the current system is eventually replaced, she predicts, faculty will inevitably be asked to adjust some of the rules to make software development easier. There will be resistance, conflict, and painful adaptation. For those of us who act as agents of technological change, it's tempting to chalk up resistance to fear of change. Users can't, or won't, learn new ways, we say, and sometimes we're right. But the reverse holds true as well. We can't, or won't, model -- and usefully assist with software -- the culture that drives the business. We standardize our software and impose that standardization on business process, because we lack the ability to customize. The reality is that, in many cases, that is the rational course. For the good of the organization, people do often need to change their ways to adapt to the software. But let's be careful, Williams suggests, about labeling the resisters as technophobes. She writes, "This is one of the oldest patterns of conflict in the history of technology: conflict between work performed with local knowledge and specialized skills, and standardized systems introduced to enlarge markets, cut costs, and assert managerial control." As the Web services movement hauls itself up the layered technology stack that it is building, the realm of business process re-engineering heaves, once again, into view. Will anything be different this time? I'm not expecting a miracle. But the medium in which we are working -- XML, HTTP -- is more flexible than anything we've seen before. Let's hope that will yield more and better customization than we've been able to achieve so far. 1. http://www.amazon.com/exec/obidos/tg/detail/-/0262232235 2. http://blogs.osafoundation.org/mitch/2002_10.html 3. http://www.osafoundation.org/our_product_desc.htm Jon Udell is lead analyst at the InfoWorld Test Center. Contact him at jon_udell@infoworld.com and check out his Weblog at http://weblog.infoworld.com/udell.  RELATED SUBJECTS  Web TechnologiesSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
