Case Topics: IT http://topics.case.edu/IT 2008-10-07T02:41:39Z Can I Link to It? http://blog.case.edu/jeremy.smith/2007/12/29/can_i_link_to_it 2007-12-29T18:17:23Z 2008-01-23T23:58:38Z
Tom Scott, of the BBC, comments on Jamie’s comments about Jamie's work on the design of BBC’s /programmes service in his post Web design 2.0 - it’s all about the resource and its URL. It touches on something I constantly hammer on: Everything important should have a URL Put another way: Can I link to it? That's the way I phrase it in meetings when people say something like "I am-developing/have-developed web blah-blah-blah so-on-and-so-forth." The next thing out of my mouth is " can I link to it?" And I don't mean link to a page that shows it. I mean directly link to the "web thing" (i.e. "resource"; i.e. "data") that was created. Sure, it's a blanket statement that ignores nuances and such (I don't even want to get into ETags with the people). I just find that it is a useful question for an "inside the Enterprise" environment in trying to improve IT architecture — it's catchy; it's to the point; and it can be (in general) easily comprehendible by people. (By the way, the web design at derivadow.com (which, according to the site's colophon is based on the " ChaosTheory" Wordpress theme) looks a lot like Khio Vinh's subtraction.com.)
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith RealPlayer 11 Beta http://blog.case.edu/stm/2007/09/10/realplayer_11_beta 2007-09-10T14:10:41Z 2007-09-10T14:49:41Z
I had to install Realplayer 11 Beta on some older machines to be imaged, and it was exhibiting some peculiar behavior. The executable forked (or whatever the windows equivalent might be) and was running two instances of itself. The one instance was spiking at around 97% to 100% CPU usage, and the other one was using what was left. I left the install run for about 30 minutes and it had only made it to 60% completion. Here is where it gets really weird... By accident I drug the task manager over the installer window so that it covered the picture area where the installer was trying to show animations or something. At this point the second instance of the installer process jumped up to around 30% CPU usage and the install finished in a couple minutes. I was doing it on two machines at the same time so I did the same thing to the other one. The second machine was just starting the install (around 10% done or so) but it also reacted the same way. When I drug the task manager over the animation area it began using more CPU on the second process and finished installing in a couple minutes. I'm guessing maybe this has something to do with DirectX? Maybe placing one window over the other meant RP could not access that part of video memory, or meant it returned false for some "is visible" type of boolean test? I had installed RealPlayer 11 Beta on a couple newer machine last week and it did not do this... Any thoughts are welcome.
 Sean Maxwell sean.maxwell@case.edu http://blog.case.edu/stm MyCase http://blog.case.edu/ajw33/2007/08/31/mycase 2007-08-31T06:41:48Z 2007-08-31T06:57:38Z
When I first paid attention to the logged-out state of the new my.case.edu this afternoon, I was pleasantly shocked to see the following two portlets in the default view: forum.gif planet.gif I was surprised not only by the choice of content, but by the choice of iconography. Both seemed rather un-ITS-like (in a good way). Bravo. I guess what I'm trying to say is, thanks for the compliment. Now get a proper small caps version of Garamond. :)
 Andrew Witte andrew.witte@case.edu http://blog.case.edu/ajw33 History of ITS's Internal Wiki http://blog.case.edu/jeremy.smith/2006/11/06/history_of_its_internal_wiki 2006-11-06T18:23:13Z 2006-11-06T20:47:48Z
I was trying to figure out how long we, here in ITS, have been using an internal wiki to document "things." After hunting around the old filesystems, I found one of the original installs of Kwiki dating back to July 20th, 2004. I came from Weatherhead to ITS in February of 2003, and I remember setting up the wiki fairly quickly between helping get the new Email system launched and redesigning our internal Identity Management system (I used the wiki to document the redesign). The July 2004 date didn't seem early enough. The July 20th, 2004 number coincides closely with the Kwiki .3x release according to Kwiki's changelog, but I remember using the .1x version (when it was CGI::Kwiki) for quite a while before leaping to the completely rewritten codebase of the .3x series. There's no history of the .1x versions on the Kwiki website or the Kwiki CPAN page. The Wayback machine helped me nail it down to a closer date because I remember doing the upgrade from .17 to .18. .17 was released on June 10th, 2003 according to this wayback page. .18 was released on September 10th, 2003 according to this wayback page. So I'm going to estimate that the internal wiki was first in use circa July of 2003. Since that time, we've switched to DokuWiki.
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith Two Programmers http://blog.case.edu/jeremy.smith/2006/11/03/two_programmers 2006-11-03T16:41:01Z 2006-11-03T16:40:11Z
The Parable of the Two Programmers An oldie but goodie. You have to read it through to the end.
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith SOA http://blog.case.edu/jeremy.smith/2006/11/02/soa 2006-11-02T07:13:43Z 2006-11-02T07:15:05Z Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith Online Calendaring at Case http://blog.case.edu/ajw33/2006/09/03/online_calendaring_at_case 2006-09-04T03:47:37Z 2006-09-04T04:09:19Z
An online, campus-wide calendar system is a commonly-desired IT system at Case. In fact, demand for the service is so high that, to my knowledge, at least four groups ( ITS Middleware Services Engineering, SIS, CaseLife, USG) have considered addressing the problem. I have been involved in a few discussions of the issue over the last year. But, not much progress has been made. (CaseLife does include data from various calendars, but not a very large number of them, and it does not yet provide any sort of machine-readable version of the data it collects.) This is because the problem is a difficult one.
 Andrew Witte andrew.witte@case.edu http://blog.case.edu/ajw33 Using "Google Apps for Education" at Case Western http://blog.case.edu/jeremy.smith/2006/08/30/using_google_apps_for_education_at_case_western 2006-08-30T23:11:13Z 2006-08-30T23:20:22Z
I may be about to shock you. You see, if you know me, you would think that Google Apps for Education is something I would be all about. I would be wearing a T-shirt reading, carrying a sign saying, and chanting " We Should be Using Google Apps for Education." I'm not. And I don't think we should. I'll try to explain. There are several ways this could be done. One way is to convert all the Case accounts to Google accounts. Another way is to just convert a section of accounts to Google accounts (like "students," for example). Yet another way is to have everyone maintain two accounts.
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith Email Users' Storage Stats http://blog.case.edu/jeremy.smith/2006/08/18/email_users_storage_stats 2006-08-18T19:37:07Z 2006-08-18T19:57:13Z
Earlier, I broke down some stats on email usage broken down by role (e.g. student, staff, faculty). Since then, we've bumped up the email quota from 100MB to 200MB for faculty, students, and staff. We did that about a month ago. Now, with the start of the semsester coming, I thought I would generate a baseline histogram of where we stand. Here it is: members-mail-usage.gif At the end of the semester (and maybe once more in the middle of it), I plan on breaking down these stats again. <Update> In the future, I may want to do comparative analysis with this data. Rather than trust me to not lose it on my hard drive, I'll just link to it from here. (Gonna do this on the earlier entry, too.) member-mail-usage.csv </Update>
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith WWW Issuing 301s for www.cwru.edu http://blog.case.edu/jeremy.smith/2006/08/05/www_redirects 2006-08-05T20:53:53Z 2006-08-05T20:59:57Z

I've long lamented the fact that WWW wasn't able to do 301 redirects for HTTP requests from www. cwru.edu/ whatever to www. case.edu/ whatever. Quoting myself:

Heck, we're not even the first hit on a search on "case". We are the #2 hit listed as "http://www. cwru.edu" ← oh the irony of running a web server on WWW that can't do simple 301s.

You may think that I am just being nit-picky because I have to be the most demanding user in the world, but it's actually a pretty big deal. Search results and the ability to find information is a key ingredient of information architecture success.

Well, I have good news. I got an email last Friday from the Webmaster of WWW:

Jeremy,

Just wanted to let you know that I put in a redirect on the Case webserver. Any requests for *.cwru.edu result in a 301 redirect to *.case.edu.

Woohoo! Our search results will finally gain some sanity. Below, I've taken screenshots exemplifying some of the stupidity of our current search results. Over the coming week, the search bots that index our site will take into account the 301s, and a search over the www.cwru.edu domain will return the exact same hits as a search over the www.case.edu domain. In addition, the entire existence of a machine called www.cwru.edu will disappear and will never again appear as a result of a search.

 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith Reading http://blog.case.edu/jeremy.smith/2006/07/31/reading 2006-07-31T18:37:41Z 2006-07-31T18:45:25Z

Here's another selection of articles I've read and planned to blog about but couldn't muster up the gumption to actually write an entry. So instead, I'm just going to link to them with quotes.

The IT manager's guide to social computing:

Sounds like knowledge management doesn't it? Well, it's not. There's none of the coercive aspects of that particular discipline. And, before you ask, it's much more free-form and less centrally-directed than groupware. In fact, social computing is a curious mix of top-down initiation and bottom-up implementation... The main software elements are wikis, blogs, RSS and tags. Other, more traditional elements like forums, directories and discussion boards may form part of the mix. Instant messaging and email are more communication channels, still used but not inherently social.

Living out loud: Learning from Google's internal information management processes:

[H]ow Google uses a simple system that manages project information using relatively unstructured email as the interface. The system mails employees every week asking what they worked on the week prior and what they plan to work on during the current week. The response is parsed, fed and indexed into a searchable system that is open to the enterprise so that anyone else can track other employees projects that they are interested in. They call it "living out loud".

Strong Opinions, Weakly Held

What is the 1% rule?

It's an emerging rule of thumb that suggests that if you get a group of 100 people online then one will create content, 10 will "interact" with it (commenting or offering improvements) and the other 89 will just view it.

Does open source usage free your budget up for the best talent?

It's no secret these days (just look at the gazillions of studies) that it's not necessarily cheaper to run a business with open source software than it is to run "closed-source" commercial software. The actual costs just show up in different places. But what rarely gets explored are the trade-offs that are made when your fixed budget is spent in different places

...

What happens with open source is you actually spend the same amount of money, but you don't have lock-in and you pay for really good people to run it. And so you still end up paying. But you just pay in a different place. And I think it's a much more sustainable model...

 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith At the Bottom of Webmail http://blog.case.edu/jeremy.smith/2006/07/20/webmail_inbox_stats 2006-07-20T18:23:19Z 2006-07-20T18:22:31Z
If you login to Webmail and you scroll to the very bottom of the page (or in a fat client, right click and get "properties" or something of your Inbox), you should notice something has changed. If everything goes as planned, it should change again, too.
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith "Enterprise 2.0" *Should* be Better Than "Web 2.0" http://blog.case.edu/jeremy.smith/2006/07/06/enterprise_20_should_be_better_than_web_20 2006-07-06T19:05:01Z 2006-07-06T19:18:16Z
So, I'm back from vacation and have managed to catch up on all of my email. There's been some more interesting discussions happening about bring "Web 2.0" concepts into the " Enterprise" (previously blogged about in my entry Bringing "Web 2.0" Concepts to the "Enterprise"). Andrew McAfee, Associate Professor at the Harvard Business School, has an excellent post Raising the Least Common Denominator:
And one of the main themes of this blog is that this kind of productive collaboration should be easier within Intranets than across the Internet. Enterprise 2.0, in other words, should be at least as powerful as Web 2.0. The informal and formal leaders of a company have an arsenal of tools at their disposal to shape both the processes of collaboration and their outcomes. If the digital collaboration platform turns into a shouting match or a random collection of junk they really have no one to blame but themselves.
If we're indicative of many "Enterprises," the biggest problem is the notion of "collaboration." Most people relate collaboration to email, Word documents, and meetings. So, when thinking of ways to improve "collaboration," the natural thought is to just try and create email++, Word++, and meetings++. This is how you end up spending hundreds of thousands of dollars on Web 1.0-style, monolithic collaboration "suites" like Oracle Collaboration Suite instead of turning to disruptive technologies that the Internet has already shown scale to the thousands and facilitate collaboration instead of just wrapping things up in complicated workflows and humdrum, clunky interfaces. There's a reason Wikipedia doesn't run on Microsoft Dynamics or Oracle Collaboration Suite. To get Enterprises to move to "Enterprise 2.0" is a huge shift in thinking. It's not email++; it is something entirely different. It's not monolithic software suites that enhance collaboration; rather, it is systems like wiki farms and iTunes that enhance collaboration. Systems that get better and better the more people use them — emergent systems that enable the Read/Write web. JP Rangaswami has a good follow-up post to Andrew McAfee's piece in Does Social Software help Enterprises Dumb Down? where he describes "enterprise immune systems." I just thought the term was great in describing the avoidance of "Web 2.0" style collaboration tools in many enterprises. The battle to bring "Web 2.0" style, emergent Read/Write properties, user-centric tools/systems to the enterprise isn't just evangelizing their properties. What is needed is a cultural shift to stop thinking about collaboration in terms of email++ and meeting++.
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith Answering Comments about Mail Statistics http://blog.case.edu/jeremy.smith/2006/06/14/answering_comments_about_mail_statistics 2006-06-14T23:41:29Z 2006-06-14T23:43:00Z
Responding to the two comments in Email Box Storage Stats Broken Down by Role. Gregory Szorc asks:
Many universities actually use squirrelmail as their official web client. Why doesn't Case?
Soon after we had the new mail system up and running (I had joined ITS from Weatherhead just at that point – at the tail end of the big mail/LDAP/calendar project), I quickly became displeased with our webmail (this was even before GMail). I had demonstrated an installation of SquirrelMail and IMP running and working atop our IMAP server. But the idea didn't get traction at the time. The counter-argument most often heard involved having to bring the Helpdesk on board so that they could adequately troubleshoot yet-another-email-webclient, and that that would take too much time and wasn't worth it. Now, in this post-GMail-world, the displeasures of our webmail interface are more apparent. Especially when you look at the statistics: Average Active POP Connections: 300 Average Active IMAP Connections: 140 Average Active Webmail Connections: 180 No doubt, a majority of the webmail connections are students. To students, having grown up on Yahoo! and Hotmail, email is webmail. And, don't forget, this is the summer. The webmail connection rate is far higher during the fall and spring semesters. I do bring it up... a lot. Our webmail is below par. People agree with me. They nod their heads. But I can't get people to greenlight a project around setting up an IMP, Squirrelmail, or Roundcude; running it without helpdesk support as a Beta; and then gather feedback from our users and decide where to go from there. If I could get someone to greenlight it, I would do it. Aaron Shaffer remarks:
My interpretation of the low forwarding numbers is that students use Case webmail for receiving mail but not sending
For students and staff, I actually think those forwarding numbers are quite high. We've got over 10,000 "students." So, ~10% of that means that there are around 1000 students who have forwarded their email to gmail. And, remember, this is only gmail. I didn't count AOL, Hotmail, or Yahoo! (or anywhere else). I just wanted a representative slice.
Is there any chance you can get statistics on the ratio of messages sent to messages received at case.edu?
Not broken down like this.
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith Email Box Storage Stats Broken Down by Role http://blog.case.edu/jeremy.smith/2006/06/13/email_box_storage_stats_broken_down_by_role 2006-06-13T18:11:23Z 2006-08-18T20:01:17Z
I'm kinda of a statistics nut. I like breaking stuff down into cold, hard, unforgiving numbers. As a corollary to being a slight stats nut, I am also very wary of any and all statistics (I'm sure you've heard the quote before.... "lies, damned lies...") Just look at the ITS Dashboard. There's a lot of meaningless statistics in there that could be used to "justify" a lot of different perceptions of their "meanings" (i.e. incorrect trending). In addition to the meaningless stats, there are some in there that are downright misleading. But for all you people that like stats and for some reason like to look at pretty graphs, I recently took a little bit of time and poured over the mail server collecting some numbers. The numbers I was looking for are:
  • How much email storage (in megabytes) do our typical users use?
  • What about faculty — how much do they use?
  • What about students?
  • Staff?
Well, here are the numbers (sorry about the poor quality of the graphics (click through on the picture to see the larger images), I used a small perl script to gather the numbers but crunched them and produced the charts in Excel): students-mail-usage.gif staff-email-usage.gif faculty-email-usage.gif In addition to that numerical goodness, I created some fun ITS Dashboard stats tracking the number of persons (broken down by roles again) forwarding their Case email to GMail: There are a lot of different ways to interpret those GMail forwarding stats. My particular interpretation (as I wait and watch them grow) is that our Webmail sucks and we should offer more email storage space. Your interpretation may differ, and your comments are welcome. <Update> In the future, I may want to do comparative analysis with this data. Rather than trust me to not lose it on my hard drive, I'll just link to it from here. </Update>
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith Don't Limit Access of Your IT Information/Service http://blog.case.edu/jeremy.smith/2006/06/02/dont_limit_access_of_your_it_informationservice 2006-06-02T18:13:13Z 2006-06-02T18:12:52Z
Dear Fellow IT Persons on Campus, When you are developing your new service/system/what-have-you, try to refrain from limiting the ways in which users can access the service/system/information/what-have-you. The more open you are with your data ( small pieces, loosely joined), the better. Also, the downtime/lack-of-accessibility of your system won't be affected by the downtime of the system used to access it. Don't get it, yet? If you find yourself writing phrases like "available only through" or "available exclusively through" or "you'll have to use x to access the data," you've tripped up on this concept. Still not relating to what I am suggesting? Go read this thread on the forums – help.case.edu getting replaced?. Read this quote from the Student Accounts Receivable Weblog in their entry Billing Upgrade:
Students will access QuikPAY exclusively through the my.case.edu portal.
It's great that it will be available via the Portal. It's bad that that is the "only" way it will be available. Portals exist to aggregate information and services together. Portals are not for providing exclusivity for services.
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith Hiring Consulants to Do Your Project Does Not Remove Your Accountability for Its Failure http://blog.case.edu/jeremy.smith/2006/05/05/accountability 2006-05-05T19:11:23Z 2006-05-05T19:13:32Z

How consultants are cashing in on pure incompetence

Oh how I have witnessed this myself.

Pulling a quote from the article:

I'm not saying that all consultants are charlatans. Neither is it unreasonable for businesses to call in experts for projects which require specialist knowledge, such as the installation of a computer system. But when retailers start hiring consultants to do the retailing, you've got to wonder.

In a letter to the US business magazine, Fortune, an American executive, Charles Yarham, explained the remarkable boom in consultancy.

"If you initiate a project on your own and it succeeds, well, that's your job. If the programme fails, it's your neck. However, if you hire a consultant and the project succeeds, it's a feather in your cap. If the project fails, you have a consulting firm to blame. After all, they're the experts."

I think of this as symptomatic of the growing trend to consolidate power, decision-making, and discretionary budget use higher and higher up the chain of command. But what is not flowing along with it is the accountability. Because, as was quoted above, "if you hire a consultant and the project succeeds, it's a feather in your cap... if the project fails, you have a consulting firm to blame."

a) I think this is a terrible trend. b) If we have to go down this dark path, the accountability should flow upwards with everything else. If one hires a consulting firm to do something, and that consulting firm overprices, under-delivers, exceeds the time table, or otherwise fails in any way, the person who hired that consulting firm should be held directly accountable. If a manager is not knowledgeable enough to not be able to see through consultants' and marketers' BS, they shouldn't be working in management. Or if the manager relied on the evaluations of his in-house specialists to evaluate consultants and the in-house staff chose poorly, they should be held accountable, too.

Hiring consultants to do a job should not remove accountability.

The other great quote from the article which is just an application and retread of a Machiavelli quote:

[The executive] having abnegated so much responsibility, how could he possibly be confident that what the consultants were telling him made sense?

Or, as Machiavelli put it: "A prince who is not himself wise cannot be wisely advised… good advice depends on the shrewdness of the prince who seeks it."

 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith I Thought the "Software Stack Wars" Were Over http://blog.case.edu/jeremy.smith/2006/04/19/software_stack_wars 2006-04-19T18:37:23Z 2006-04-19T18:41:05Z
I thought this was over. I thought the industry had learned its lesson – installing vertically monolithic tiers from a single vendor that uses "standards" as a marketing term and not a core business principle does not a) reduce cost, b) put you in a leveraging position with that vendor, c) improve user experience, or d) reduce complexity. I guess we haven't learned our lesson – Software's "stack wars". Actually, I think this is a fluff piece meant to try and revive the thinking of this architectural style amongst the dinosaurs that still desperately cling to these notions. The first commenter points out the obvious.
 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith What I Read Over the Weekend: Bringing "Web 2.0" Concepts to the "Enterprise" http://blog.case.edu/jeremy.smith/2006/04/17/web_20_for_the_enterprise 2006-04-17T19:53:23Z 2006-04-17T19:59:37Z

Interested in what I read about over this past weekend? No? Well... go ahead and stop reading then. Here's something entirely more entertaining.

Yes? Well, the Internet was a-buzzin' with articles, comments, and opinions on bringing "Web 2.0" concepts "inside the firewall" i.e. using them in the "Enterprise" with emphasis on how it all relates to Knowledge Management Tools/Systems.

A lot of it was in reaction to Associate Professor at Harvard Business School Andrew McAfee's article "Enterprise 2.0: The Dawn of Emergent Collaboration", which the author summarized:

There is a new wave of business communication tools including blogs, wikis and group messaging software — ... Enterprise 2.0 — that allow for more spontaneous, knowledge-based collaboration. These new tools... may well supplant other communication and knowledge management systems with their superior ability to capture tacit knowledge, best practices and relevant experiences from throughout [an enterprise] and make them readily available to more users.

Nicholas Carr, former executive editor of the Harvard Business Review and author of Does IT Matter?, comments in Is Web 2.0 enterprise-ready?:

No matter how technologically elegant their design, knowledge management "platforms" and "repositories" tend to quickly collapse under the weight of their own complexity. Using them turns out to be more trouble than it's worth - particularly for those employees who have the most valuable knowledge - and the platforms and repositories fall into disuse and are eventually, and quietly, dismantled. People go back to using efficient, direct conversations - through meetings, or phone calls, or emails, or instant messages - to exchange useful knowledge...

He then explains what makes Web 2.0 technologies different. "The good news," he writes, is that the new technologies "focus not on capturing knowledge itself, but rather on the practices and output of knowledge workers."

Andrew McAfee comments on Nicholas's comments in Does Web 2.0 guarantee Enterprise 2.0?:

If you believe that this migration [of enterprises using so-called "Web 2.0" tools] won’t take place, you believe essentially that companies—interdependent groups of people with a common mission and a profit motive — are less able or less likely to engage in free-form collaboration than the mass of previously indepedent volunteer freelancers that have made Wikipedia, Flickr, MySpace, YouTube,  del.icio.us, Digg, etc. so powerful and successful.

Lots of knowledge workers spend lots of their time on two activities: keeping their colleagues appraised of what they’re doing, what progress has been made, what they’ve learned/concluded, etc. and trying to locate resources within their own organizations... Blogs (like the other Enterprise 2.0 tools) can help with the first of these tasks, and in doing so also help with the second. It’s not too farfetched to envision companies in which people use Enterprise 2.0 tools to report progress, collaborate, and share the outputs of these collaborations.

In another article, Taking Web Services To The Office, Fred Wilson compares how technologies used to emerge for "Enterprises" and consumers with how they emerge now:

Esther Dyson observed in a Release 1.0 issue in 2004 (well before web 2.0 was upon us) that it used to be that technology would start with the goverment (military or space), then move to the enterprise, and end up in the consumer's hands. But, she said, these days technology starts with the consumer and moves up to the enterprise.

Commenting on this thread that is spreading is the article Knowledge Management 2.0 which discusses the growth of current KM tools versus how "KM 2.0" will grow:

Many of the failed knowledge management projects at financial services and professional services firms were top-down initiatives staffed by technology and information professionals. They required complex technology infrastructures and very long implementation timelines. One challenge was getting employees to share information through use of the system; another challenge was proving an acceptable ROI, given a very high level of investment and a difficult to measure return. In many cases no amount of management evangelism could lead employees to share knowledge in a complex and often difficult to use platform.

These "top-down" initiatives usually involve someone (called "a consultant" or a "salesperson") who is master of spin i.e. a person who can BS with the best of them convincing those with decision making power that complex/convulated KM systems will enable their "Enterprise." The easiest way to cut through these persons' BS is to make them step away from the carefully constructed Powerpoint buzzword generating machine and ask them to actually demonstrate how this system they're trying to hock will help Jane in sales find information from Greg in Engineering better than email or a phone call. Make them demonstrate the entire system from creation of "knowledge" all the way to the point where Jane retrieves it. If after the demonstration, it is still incredibly obvious that Jane sending an email to Greg and getting a response back is easier than their "workflow enabled digital repository of knowledge," tell that consultant/salesperson to take their $600,000 contract, 7-9 month timeline, and ROI estimates elsewhere.

The final article I read was a month old one written by Ross Mayfield, CEO of Socialtext, entitled An Adoption Strategy for Social Software in the Enterprise. It's a long article and should be read in its entirety (like all of the other links), but I'll pull some quotes from it.

Experience has shown that simply installing a wiki or blog (referred to collectively as 'social software') and making it available to users is not enough to encourage widespread adoption. Instead, active steps need to be taken to both foster use amongst key members of the community and to provide easily accessible support.

There are two ways to go about encouraging adoption of social software: fostering grassroots behaviours which develop organically from the bottom-up; or via top-down instruction. In general, the former is more desirable, as it will become self-sustaining over time - people become convinced of the tools' usefulness, demonstrate that to colleagues, and help develop usage in an ad hoc, social way in line with their actual needs.

I can personally vouch for that in regards to the Case Blog, Case Wiki, and ITS internal wiki.

... consider how social software fits in to the context of their job, their daily working processes and the wider context of their group's goals.

  • What specific problems does social software solve?
  • What are the benefits for this person?
  • How can the software be simply integrated into their existing working processes?
  • How does social software lower their work load, or the cognitive load associated with doing specific tasks?

That harkens back to the earlier mini-rant I did in this post regarding KM contractors/consultants/salespersons. Make them show you, not in Powerpoint or whitepapers — in an actual demonstration, from beginning to end, from creation to retrieval, how this system will help and enable and empower and empassion the users whose job it will be to use the system. If email or a phone call trumps their system...

 Jeremy Smith jeremy.smith@case.edu http://blog.case.edu/jeremy.smith Service-Oriented Versus It-Does-It-All http://blog.case.edu/gps10/2006/04/12/serviceoriented_versus_itdoesitall 2006-04-12T18:05:40Z 2006-04-12T19:15:15Z
There is no doubt that applications are becoming more and more service oriented, that is, loosely coupled, highly interoperable services being joined together to form a unified collection of applications. Service-oriented architecture (SOA) directly contrasts with the old, established architecture of one-thing-does-it-all. Imagine the following scenario. You need to buy a DVD player and a VCR (to play all those old tapes your wife has). You have two basic options. You can either buy a DVD/VCR combo unit or buy separate components. If you have any experience with home theater, you will know that in most cases, the DVD/VCR combo unit lags far behind the separate components in terms of features and quality. However, the combo unit, because it is only one component, sells for far less. Lesson learned: if you don't have the money and don't care about features and performance, the combo unit is they way to go. However, if you want two high quality components and you have the money to spend, buy the separate components. (The same analogy holds true for home theater receivers and amplifiers, but since less people would have understood that analogy, I selected to go with the DVD and VCR comparison). Now, let's examine this same scenario for IT services. Your company is looking to deploy a suite of applications to foster collaboration. The suits immediately start knocking on your door, telling you all about their six figures, per-seat license, it-does-it-all collaboration suit. At the same time, you hear voices from your middleware group, urging you to ignore the suits and to deploy independently-developed applications that are built on standards and have a proved track record. The suits promise their product is better for your enterprise because all the products are developed under the same roof and they work well with each other. Little to no configuration is needed because the ties between applications already exist. The middleware group can just point to standards-compliance and easy interoperability. After much schmoozing, free dinners, and promises from the suit-wearing sales drones, you give in, opting to deploy the all-in-one product. A few months down the road, your collaboration suite is deployed, and all is working well. However, you really want to deploy a new service that isn't included in the collaboration suite. Because you have all your eggs in one basket, you need this new service to integrate with the collaboration suite. You assign the task of investigating the integration. Two weeks later, people get back to you and say that the new service can't integrate with the collaboration suite because the collaboration suite doesn't have a sufficient remote interface. You call up the vendor, asking if they will support your new service. They don't, and they aren't planning on it (they really say the service will be in a future version, but you don't buy that). You slam your first on your desk, irritated you went with the all-in-one solution. The two scenarios share many characteristics. You want something that does A and B. You can either buy one thing that does both A and B, or separate things to do A and B. The in-one-box solution is simpler and costs less. However, as time goes on and you need to add in support for C, the in-one-box solution doesn't measure up because it is only meant to do A and B. However, the separate components are designed to integrate with other independent components, and you can easily plug in C. There is one major factor that affects the anology: Open-source software (OSS). With OSS, you can get separate components without the extra cost. You also get the ability to modify the applications to get the functionality you desire. You also get the piece of mind that you know what you are getting. Since the software is free, you can test drive it before making any committments to the suits. I've diverged a bit from the goal of this entry, which is to explain the benefits of SOA over it-does-it-all. With SOA, you have individual components designed to do A. And A, they do very well. With it-does-it-all, you have products that do A, B, C, and D. However, in most cases, you will find the product originally was designed to do A, and later added support for B, C, and D. With SOA, one product is built specifically for A. The concentration is A, and nothing but A. You realize that many will want A to work with B, C, and D, so you provide a robust interface to A, so that B, C, and D can be made to work with A. It does require a little more effort to make A work with B if they are separate products. However, if one is the best at doing A and another is best at doing B, isn't that better than a combined product that does both A and B to a lesser degree? Sure, A and B come pre-configured, but by doing so, you are sacrificing features and future interoperability. What good is a service if you can't interface with it? The bottom line: service-oriented architecture features separate components that are loosely coupled and very interoperable. Since components are separate, you often have the opportunity to pick and choose components that perform functionality A, B, and C. That means you can pick something that does A very well, B very well, etc. It may take a little longer to configure these products for your environment, but once done, you will have a solution that can perform A, B, and C better than a all-in-one solution that claims to perform A, B, and C. And a more functional product is what you want to deliver to the end-users.
 Gregory Szorc gregory.szorc@case.edu http://blog.case.edu/gps10