Phil Windley's Technometria

« November 2002 | Main | January 2003 »

December 31, 2002

Warflying

The January 2003 issue of Red Herring has an article on my warflying experience. I'm anxious to try it again now that I've built my own Pringles Can antenna.

5:26 PM | Comments () | Recommend This | Print This

Utah eGovernment Notes

Two items of interest regarding eGovernment in Utah. First, Utah has earned seventh place in the Center for Digital Government Sustained Leadership Award. This measures eGovernment performance over the last 5 years.

Second, Utah's enterprise IT planning process is the feature of a story in Governing Magazine. Ellen and I talked quite a few times about this story and I think she got it mostly right.

4:43 PM | Comments () | Recommend This | Print This

December 30, 2002

Blogging and Academic Research

Jon Udell references articles from Andrew Odlyzko and SŽbastien Paquet in an article about peer review, academic research, and blogging. Being a once and future (I hope) academic, I have given some thought to this question myself.

I think SŽbastien misses a very important point on why more academics don't blog as part of their research efforts: tenure and promotion. Tenure and promotion depend on one thing (protestations about teaching aside): published papers in established research journals. In this false economy, every other activity, including blogging, is in constant competition for the resources that could be applied to publishing in peer reviewed publications of note.

The problem that this poses, is that this system is not necessarily the best one for measuring the importance or impact of a scholar's work---its simply the one that is trusted the most. This is especially true in the field of information technology. By the time something makes it into a printed journal, the research is almost certainly 3-4 years old. So, right now you could expect the first papers based on research done in 1998. That simply isn't fast enough in the fast paced world of IT. When you want to find out what's innovative in computing, you don't turn to the Journal of the ACM, you open up InfoWeek or some similar trade magazine.

Will this change? I agree with Andrew that its changing already, albeit slowly. There are other indications of a researchers innovation and impact, like the number of readers of a blog or work with a company. The problem is that its hard to count and comes up against a measurement system that is trusted, for good or bad, by nearly everyone. Academics will take their own sweet time, but eventually come to grips with new modes of communication and how to measure it. Whether these other indications ever play a part in tenure and promotion decisions remains to be seen.

10:43 PM | Comments () | Recommend This | Print This

Your Medical Record: Technology is the Prescription

Two weeks ago, my mother-in-law had surgery on her wrist. Last night she was in some pain, so my sister-in-law called the doctor and he phoned in a perscription. They picked it up, got it home, and went to use it only to discover that it contained Ibuprofen. My mother-in-law is allergic to Ibuprofen.

This sort of thing must be very common. The Center for Drug Safety reports 2.1 million cases of adverse drug interactions each year with 100,000 deaths. Other sources report similar numbers. Many of these could be prevented by a simple technique that has nothing to do with medicine and everything to do with IT: unique records.

Its perfectly plausible that one's medical record could be kept in a single location and accessed and updated via the Internet by each doctor, hospital, emergency room, EMT, and pharmacy you use. Provisions of HIPPA even makes keeping such a record up to date relatively automatic--providing common codes for different procedures and standardized ways of processing payments. Its frustrating to me to see a technically sound solution to a problem that could save many lives and untold suffering and not see it implemented.

What would it take to make this a reality? I think a large insurer like Blue Cross could make it happen now, if they were of a mind to. They already get your information and could store it. They could make using the online medical record by the doctor a condition of payment or give some other incentive. Why don't they? I don't know. I think it probably has something to do with controversy over who owns and controls the data in the medical record: you, the insurer, or the doctor? (HIPPA says the patient does, I believe) There's probably also some concern for liability. But I'm just guessing. Anyone else care to hazard any guesses?

8:52 PM | Comments () | Recommend This | Print This

Another Entry in the Utah Blogroll

A friend of mine, Pete Kruckenberg, is a network engineer for UEN, the Utah Education Network. Pete's responsible for some very forward thinking there, including GigE lines to the Uintah Basin for connecting rural Utah schools to the net at high speeds and the use of local exchanges. Pete has recently started a blog and I'm anxious to read what he has to say.

7:46 AM | Comments () | Recommend This | Print This

December 28, 2002

One More Reason to Hate Direct Attached Disks

I've written before about the benefits of enterprise storage solutions. In short they promote better file management, backup, and security. Today the Salt Lake Tribune is reporting a story that is a perfect example of why this is true:

Thieves who broke into a government contractor's office snatched computer hard drives containing Social Security numbers, addresses and other records of about 500,000 service members and their families. The company, Phoenix-based TriWest Healthcare Alliance, provides managed health care to the military in 16 states, including Utah. It serves about 1.1 million active-duty personnel, their dependents and retirees. TriWest spokesman Jim Kassebaum said computer equipment stolen from a TriWest office in Phoenix on Dec. 14 contained names, addresses, phone numbers, medical claim histories, and Social Security numbers for beneficiaries in its central region, which covers the central United States. In a separate news release, the company also said a "few credit-card numbers were contained in the potentially compromised files."

I think any enterprise that allows sensative data to be stored on direct attached disks in unmanaged environments is negligent. Sure, someone could break into a data center as well, but chances are that the data center is monitored 24 hours a day. There's also likely to be better information security policies and those policies are more likely to be followed. If someone's going to store sensative data, they ought to use the best techniques available, not the same ones my Aunt uses to store her recipes.

12:51 AM | Comments () | Recommend This | Print This

December 27, 2002

ALIN - Application Layer Internetworking

I just discovered (via Sam Ruby) Rohit Khare's work on application layer internetworking, or ALIN. Rohit gave a talk at the O'Reilly Emerging Technologies conference last May and has a powerpoint presentation and some rough notes online. What I've been calling Layer-5 routing, Rohit calls Layer-7 or ALIN. I'll defer to him since he's got the powerpoint done (not to mention that he's probably thought it through more).

Reading Rohit's presentation, I realize I left out a very important feature in my thoughts on ALIN: message store and forward. I was thinking of transport as orthoganal to the idea of ALIN. I still think that maybe it is (at least for the feature set I envision), but Rohit argues that transport can't be ignored because latency is such a huge issue in web services. He's got a point.

Rohit calls out the following companies as being in the "Internet-scale" messaging business: KnowNow (which Rohit founded), Bang Networks, Kenamea, SonicXQ, and Grand Central. If you visit these sites and look at their customer lists, you'll notice that they all sell to a lot of financial institutions and brokerages. This doesn't surprise me. When we were building credit card gateways for First Data Corp. at Excite\@Home, we were using IBM MQ Series to route transaction records among geographically dispersed gateways. Financial institutions have been chasing this problem for years.

9:58 PM | Comments () | Recommend This | Print This

Using CUPS for DeskJet Printing with a Netgear Print Server

For some time, I've used a Netgear PS110 print server to connect printers with just a parallel port to my home network so that my printers can sit in a more convinient location. Now that I'm using OS X, I was a little worried that it might not work. Turns out it works just fine using CUPS. Here's what I did:

1. Connect the DeskJet to the PS110
2. Go to http://127.0.0.1:631 to access the built-in CUPS administration tool. Its already running---you don't need to start it.
3. Select "Add Printer"
4. Select a name, etc. This isn't critical.
5. The PS110 speaks LPD, so select LPD printing and enter the URL as lpd://192.168.1.10/P2 where 192.168.1.10 is replaced with the IP number or DNS name of the PS110 and P2 is the name of the queue on the PS110 that the DeskJet is connected to.
6. I was using a DeskJet 882C, so I selected New DeskJet when asked. You may need to select something else depending on your printer.
7. Print a test page. For some reason, I couldn't print the test page from CUPS, but I printed a test page from Mozilla just fine.

I like this solution because I don't have any other computer in the loop, just a simple appliance. The PS110 has two ports, so you could have two printers. I happen to have a Brother MFC4500 on the other one and, alas, there doesn't appear to be a driver for OS X, so its just faxing at this point.

This wasn't as easy to get going as many things on OS X have been. Over all, I'd say printing is the weakest thing I've seen so far in OS X administration. Everything else has been dirt simple. There are two different ways to configure printers: the Print Center and CUPS. I tried in vain to get the Print Center to work (driver issues). Finding CUPS took some work and searching. The good news is that CUPS is fairly substantial and has some great tools, so better intergration with CUPS (so that there's only one way to configure a printer) could solve this problem.

1:09 PM | Comments () | Recommend This | Print This

December 24, 2002

Ron Galloway

Those who read this blog regularly will know that I post frequently. I haven't written much since last Friday. I'm not taking the holidays off. My father-in-law, Ron Galloway, was killed in a snowmobile accident on Saturday afternoon and its been a whirlwind 3 or 4 days since then. Its a tough thing to go through but its just keeps coming at you, so you just keep sluggin away. I spoke at the funeral this afternoon and now its time to get ready for Christmas.

Goodbye Ron, we'll miss you.

7:49 PM | Comments () | Recommend This | Print This

December 22, 2002

CIO vs CTO Redux

Earlier, wrote about the differences between a CIO and a CTO. Doug Kaye offered another:

CIOs are primarily concerned with how their company consumes and applies technology. CTOs are primarily concerned with how their company creates and exports technology.

I think the producer/consumer contrast is quite appropriate. Of course, in the process of consuming, CIOs create new things and in the process of creating, CTOs consume technology, but coupled with the other statements in my earlier post, I think this has the right context and serves as a good summary.

5:46 PM | Comments () | Recommend This | Print This

December 20, 2002

Switched

With my resignation, I find myself, for the first time since 1988, in a position where I must buy a computer. With my own money on the line, I chose a Mac (actually, I chose OS X).

This week, my new 1GHz, 1Gb RAM, Gbe, Powerbook arrived. I've spent a few days moving all my data and work from the XP machine I used. I'm now pretty much completely switched over and the XP box has been relegated to a single purpose: Groupwise for the few remaining emails I'll get from the State. The week after next, I'll return it to the State and bid it good riddance.

Back in the old days (circa 1984) CMU was developing what they called a 3M machine: 1MHz processor, 1Mb RAM, and 1M pixels. IBM eventually created monitor they called the Megapel that had 1024x1024 (1M) resolution. It weighed about 150 lbs. We've, of course, passed the other two M's 1000 times over and now speak of G's. I've got a G4 and have managed to find three of the G's. I don't know where the fourth is. :-)

I've played with the iBook before and loved it, so this machine is just more of the same, but better: beautiful display and lightening fast. With 1Gb of RAM, you just keep opening applications and it just keeps going.

I'm not alone in absolutely loving this machine. Check out these articles in the November 15th, InfoWorld. This is truely a spectacular computer.

11:54 PM | Comments () | Recommend This | Print This

December 19, 2002

CIO Magazine Talks Blogs

CIO Magazine has a section called "Trendlines." The Januray 3rd issue contains a trendline on blogs that features my blog. They highlight the fact that I blogged the NASCIO conference in October. They say "Windley's log of dated posts covers life as a CIO, thoughts on technologies like instant messaging and Web services, and reports from events, like the St. Louis confab."

8:02 PM | Comments () | Recommend This | Print This

December 18, 2002

Conflicts of Interest

After I wrote my last post, I thought I'd better write a general statement on conflicts of interest.  When I was working for Utah (still am for a week or so) my interests were clearly defined.  As that changes, people may wonder about what personal stake I have in things I talk about here.  I do not want this site to become a series of advertisements or for people to have to question things I say.  So, my general policy is that I will disclose a conflict if it exists and say nothing if it does not.  So, you may assume, for example, that I have no personal stake in Vultus (see the previous post). 

BTW, if you're wondering why I just spewed forth with three posts in a row, its because I'm giving a final and I'm standing here with nothing to do.  :-)

7:13 PM | Comments () | Recommend This | Print This

Vultus

I spent 90 minutes this morning with a company in Utah County (Lindon, actually) called Vultus.  I was pretty impressed.  If they'd shown me that product three years ago when I was building consumer oriented eCommerce tools, I'd have written them a check on the spot.  Its that cool.  Here's what it does:

Vultus has created a Javascript library and professional IDE that allows you to create a think client experience without any client footprint.  Since the Javascript runs in the browser (IEv5 or later, Netscape v7 or later, or Mozilla) lots of interesting things can be done that just aren't possible on a server.  No plug-in is required.  The library is around 300K and is cachable, so its fairly low overhead.  The IDE creates professional looking GUIs with a drag and drop interface. 

One of the cool things they can do it interface to SOAP services.  They have a tool which automatically creates a GUI that runs in the browser from the WSDL. 

They've put together a demo site that shows some of the capabilities.  Be sure to look at the source. 

7:08 PM | Comments () | Recommend This | Print This

CIO vs. CTO

One of the questions I hear with some frequency is "what's the difference between a CIO and a CTO?"   Having been both, I think I have some insights that might be helpful.

First let me talk about what I think they have in common:

• In both jobs, a key role is helping technologists understand what the business needs and helping the business understand what the technology can do for them.
• Both roles require a strong technologist with a strong grasp of business (kind of a corollary to the last point, but slightly different). 
• Both should be strategic thinkers.
• Both should be excellent leaders.

Now for their differences:

• I see a CTO as primarily focused on the top line while the CIO is primarily focused on the bottom line.  There's some cross over, but I think this is a valid distinction.
• A CTO is primarily concerned with external products and customers while a CIO is primarily concerned with running the business (internal products and customers).
• In an ideal world, the CTO runs the product development organization while the CIO runs the IT organization.
• If you have to choose, being a strong technologist is more important for the CTO, while being a good manager is more important for the CIO.
• A CIO has to be operational and understand how to build repeatable processes, reliable systems, and the organization to run them.  A CTO doesn't necessarily have to have these skill if backed up by a strong operational person in the role of CIO. 

A large technology oriented company (more than a few hundred employees) should have both.  There's too much to do for one person and the thinking can be very different.    One of the big problems at Excite\@Home was they never had someone  at the "C" level who was looking internally.  "IT" was a division (not even a VP slot) inside the larger technology organization.  There were four levesl between this director and the CEO.  The result was real chaos in the internal systems and operations areas.  The CTO was a brilliant technologist, but not very "operational" and consequently, repeatable processes were hard to find. 

Personally I've enjoyed both roles, but I found the challenges to be very different. 

6:53 PM | Comments () | Recommend This | Print This

December 17, 2002

Deseret News Quotes My Blog

David Politis wrote a fairly complimentary article about me in the Monday Business Section of the Deseret News.  Its interesting that he quoted from my blog extensively and linked to my resignation letter.  David finishes with this observation:

In my opinion, the big takeaway from this entire mess is that Leavitt will have his hands full in finding a tech- and politically-savvy CIO for the state.    In this time of financial shortfalls up on Capitol Hill, the risk is that continued advancement of technology services within state government will get a short shrift minus a strong CIO at the helm. And that would not be a good thing.

This will be an interesting task, indeed.  I've discussed my recomendations with the Governor and the Chief of Staff.  I think I have a pretty good idea who the replacement will be and I believe it will be an interesting choice. 

7:22 PM | Comments () | Recommend This | Print This

Craig Burton's Application Services Automation Layer

Interestingly enough, after writing about Level 5 Routing for Web Services this morning, I happened to have lunch with Craig Burton.  Craig has started a company called JanusLogix this is doing something along those lines.  Craig calls it the application services automation layer.  Lot's of protocol heavy stuff (which won't surprise anyone who knows Craig).  I'm hoping Craig will get some additional white papers and other information on the JanusLogix web site soon, because what he's up to sounds like interesting stuff. 

2:10 PM | Comments () | Recommend This | Print This

Level 5 Routing for Web Services

Last night I couldn't sleep, so I started to put together some thoughts I'd been having lately regarding web services and level 5 routing.  Some might want to quibble and call it level 4, but since the transport for SOAP is HTTP (a level four protocol), I'll call it level 5.  The idea is pretty simple: the advent of standards for application integration has brought us to the point where applications can be put together by scripting calls to existing services.  Because the APIs are exposed and documented and the calls happen "in the clear" instead of buried inside a monolithic application, one can conceive of a routing architecture for these service calls that performs the following functions (and more):

• Service Call Switching.  Think of this as load balancing for web services done at the interface level.  This could be done simply to balance load,  to shuttle potentially high load jobs to specific servers, or to move a new version of the service into production.  For example, imagine developing version 2.0 of your web service and instead of cutting over to it one evening or weekend, you just shunt 5% of the traffic to it for a while and then slowly crank up the volume to ensure its functioning properly and can handle the load.  When you're satisfied its working, you cut over to the new version and tear the old version down.
• Filtering Based on Context.  Probably the most obvious example of context sensitive filtering is in the area of authorization.  Suppose that the level 5 router has access to SAML messages about authentication and authorization information for users.  The router could be configured to filter messages (coming or going) based on that authentication information.  So, for example, someone requesting health care information about a patient could be denied access altogether, or the return message could be filtered to return only the right information. 
• Event Monitoring.  Suppose you'd like to put an alarm on certain kinds of calls.  The router could be configured to monitor traffic and send an alert (message) when it is triggered.  So, for example, a sales manager could be alerted to an order from a certain customer or over a certain amount and take some special action.  Or, the inventory management system could be alerted when a call is made to order an extraordinarily large number of some part, etc. 
• Logging.  Any event or call, including the content, could be monitored and logged for later analysis. 
• Service Facades.  The router could provide service facades to wrap a service in a more generic interface or one that the company supports internally.  As an example, suppose that your company has built a nice employee portal that uses a web service provided by your health insurer and then you change insurers.  The ability to easily map one service to another would provide a service facade that makes integrating the new service easier.  I think in many cases this could be done using a graphical tools based on the respective WSDL information. 
• Business Rules Repository.  Rather than scripting, such a router could contain (or access) a business rules repository and use it to provide aggregated services. 

Of course, all this would have to happen reliably and quickly.  One question that might come to mind is "Why would you want to do any of these things at the interface?  Why not build them into the application?"  That's a fair question and I'd answer in two parts:

1. Separation of concerns.  Do the security and logging outside the application rather than building it in.  Then its modular and can be easily changed out. 
2. Reliability.  A pre-built, widely used infrastructure component is likely more reliable and scalable than a homegrown solution. 
3. You may not have access.  You may want to filter or log access to services you don't control. 

I've got to run now.  I'll write more about this later. 

9:37 AM | Comments () | Recommend This | Print This

December 16, 2002

Web Services: Incrementally Exposing Your APIs

The December issue of the Web Services Journal has an article by Henry Bowers on "Building Business Rules in Web Services Applications."  What caught my attention was the ability to do something like this incrementally in the same way I advocate doing incremental transitions to web services for data in my paper on Enabling Web Services.  At one point, Henry says:

[Another] approach is to separate business rules from the business logic. Depending on the construction of the applications, this can be fairly easy. For example, the 400 pages of if/else statements mentioned earlier are located in a handful of functions. These routines can easily be wrapped up as a Web service. This service is sent the same parameters with which the original functions were called and returns the same values after executing the rules. ...

The first advantage is that other applications can now make use of the same rules. Suppose, for example, that a mortgage insurance company wants to establish what proportion of its loan portfolio is at risk. It might obtain updated information on its customers and run the data through the qualification engine to see who would be rejected or assigned a lower credit score. To do this analysis, the company needs to access the business rules without dealing with the other processing of a loan application. It is not interested in receiving text streams for loan documents; it wants only the results generated by pushing data through the qualification rules.

Web services provide a unique opportunity to implement this kind of reusability by carving out sets of rules into callable services. In addition, they encourage the conversion of many standalone data formats into XML, which has the benefit of simplifying overall application integration (at the cost of performance, which in high-volume settings is far from negligible).

Sites that choose this path are often surprised at how quickly benefits become apparent. The separation of rules processing as Web services can be implemented progressively. Complete conversions of applications are unnecessary. Also, once rules are segregated as Web services, new opportunities for their use appear quickly. For example, business analysts can much more easily perform what-if scenarios by rolling hypothetical data through the rules.

This is exactly the right approach.  As you can, incrementally expose web APIs (internally or externally, as appropriate).    The marginal cost isn't that great and the more APIs you expose the greater the potential interoperability.  Small, scripted aggregations lead to serendipidous applications:   Jon Udell's LibraryLocator bookmarklet is a perfect example of the kind of interesting things that can happen with just a few scripts when APIs are exposed, documented, and reachable.   

2:19 PM | Comments () | Recommend This | Print This

IM TCO

Jeremy reacted to my post on the enterprise wide IM:

I'm wondering what the costs really are. Given that the software (Jabber) is free on both the client and server, what's left? Deployment? That's a one-time cost that's no higher than deploying any other software. Training? IM software isn't terribly complex (compared to Word or Excel). Many already use IM at home thanks to AOL, Microsoft, or Yahoo. The less technically inclined can always ask their kids for help. :-)

What Jeremy says is mostly true.  This really comes down to total cost of ownership.  The one gotcha is that software cost is almost always a small part of the overall cost of doing anything across an organization with 22,000 employees.  its also usually the easiest part to figure out.  Jeremy's statement presupposes a few things:

• Sufficient priority to get the engineering time necessary to create a solution.  Jabber is a great tool.  I've played with it some and got some people using it to see what it could do.  Still, rolling it out in a reliable way for 22,000 people involves some planning, capital expenditure, etc.  There are lots of fires being fought and that keeps us from working on new, interesting things.   One of the things that people frequently don't factor in when they look at organizational dysfunction is the opportunity cost.  Its huge. 
• A desktop support structure that isn't extremely fragmented.  A fragmented organization makes rolling something like this out difficult because you've got to convince 30 separate kingdoms to do it and then you've got to make sure it happens right, that the training is occurring, etc.  Utah just isn't organized in a way that makes something like this a simple task.

The fact that it will be integrated into an existing product means that it will just happen and be prioritized along with email upgrades.  Sometimes, this kind of upgrade is the only hope for moving in a new and interesting direction.

As an aside, I noticed on some of the comments on Jeremy's site that people were asking why not just use AIM?  A number of us do use AIM everyday to get work done, but the consumer version has a few holes that need to be filled in an enterprise IM solution:

• An enterprise IM solution should tie into the corporate directory so that its easy to find people and create workgroups automatically (for presence, if nothing else).
• An enterprise IM solution should be secure.  I want encryption from me to the recipient (not just the server) and I want positive feedback that its there. 
• An enterprise IM solution should be as ubiquitous as you can make it across the enterprise so that its a tool people can count on for collaboration. 

1:46 PM | Comments () | Recommend This | Print This

December 14, 2002

Applying IT to IT

Marc Andreessen has an interesting article on applying IT to IT.  I think its fascinating that IT professionals are the most vociferous in stating why automation can't possibly be applied to what they do.  The emergence of ubiquitous networks and great software for managing desktops has turned that into an eminently automatable task.  IBM reports that they can deliver superior service with a tech to supported PC ratio as high as 350.  With a ratio of 1 to 175, we figured Utah would save $7 million per year.  Yet many IT professionals are reluctant to embrace these tools and change the way they work.   Why?  One reason is the same reason the longshoremen struck the West Coast ports: they're afraid they'll lose their jobs.  What a waste. 

5:38 PM | Comments () | Recommend This | Print This

Office 11, Forms, and Unstructured Data

I've been trying to get a hold of a beta version of Office 11, the new version of Office from Microsoft.  As I wrote before, I believe it is the first version of Office worth upgrading for since Office 97.  Indeed many people still run Office 97 and do just fine.  I think that's about to change.

Two areas of considerable attention in the enterprise today are workflow for internal processes (think forms) and unstructured data.  Office 11 could play a role in both of those areas.  As far as I know, there's no workflow engine for Office 11...yet.  Still, Office 11's ability to handle form data and create structured documents is a boon.  I've looked at workflow and form processing tools for a few years now because they are the infrastructure for building automated business processes.  Imagine how much a large organization spends processing travel forms, for example.  In Utah, its still a department by department activity with lots of hands touching lots of forms until a check finally gets cut.  A workflow engine with a good form tool can turn that into a paperless, uniform process across the entire organization, making employees happier and freeing everyone from the hassle of travel forms.  The problem is that you have a tough time finding the ROI in a single project, but once you've got the tool, there are hundreds of uses.  Office 11 will be part of the desktop anyway, reducing the need for a separate ROI.

Unstructured data is another area where large organizations have a great amount to gain, but the ROI is difficult to find in any single project.  With the right planning Office 11 can manipulate XML to create structure in many of the documents we currently handle as just text.  Jon Udell. quoting my blog, writes in InfoWorld:

"Got a question?" writes Phil Windley, CIO of the State of Utah, on his Weblog. "Somewhere, on some government computer, the information you need is probably available. Information you paid for and the government would gladly share with you -- if only they could find it." Upgrading the word processors and spreadsheets on those government computers to versions that not only can read and write XML, but, more crucially, can enforce rules about datatypes and structures, is part of the solution. Assuming, of course, that such rules can be written, deployed, and unobtrusively applied and maintained over time. "Therein," observes Windley, "lies the rub."

That, indeed, is the issue at hand.  Can the enterprise adapt so that the power of XML documents is used effectively.  Not only does it require that people creating documents take the time to structure their data, but it also requires that everyone use compatible software and store documents in a reasonable place and in a reasonable way (i.e. not on direct attached disks).  This requires some discipline and a plan. 

11:57 AM | Comments () | Recommend This | Print This

December 13, 2002

Presence in the Enterprise

This morning, I was talking to some people about X windows and it struck me that running applications remotely (which X could do from the start, of course) doesn't seem as germane to my life as it did back when I was in graduate school (late 80's).   I started to ask myself why I wanted to log into 10 different computers back then and it really came down to one thing: presence.  The main reason we'd all log into every workstation in the group was so that we could tell who else was there and communicate with them using "write."  We have a VAX8600 and there'd be lots of other students logged in so you could ask someone about an assignment or see who else wanted to go to "The Silo" for a bagel.  Nowadays, that need is fulfilled by IM. 

Today Novell released a preview of Groupwise 6.5 which contains an IM tool called "Conversation."  In its initial release, it won't be able to talk to other IM systems, but I don't see that as too much of an impediment.  In fact, I see it as a feature.  I don't mix my personal and work email and I don't want to mix my personal and work IM conversations either.  Its probably a bigger problem for a smaller organization or one that has lots of outside partners.  I've been wanting an enterprise IM tool for some time, but couldn't justify the cost.  Now, its part of Groupwise, so that helps the ROI considerably.   I'm excited that Utah will finally be able to deploy an enterprise wide, secure IM tool that runs off of our master directory.   I think it will have a large, but subtle effect on how people collaborate electronically. 

11:47 AM | Comments () | Recommend This | Print This

December 12, 2002

Professional Licensing at Utah.gov

In a little over 9 months, professional licensing has become one of the most popular services on utah.gov.  Over 30% of all professional licenses renewed during that period were done online.  Kudos to the Dept. of Commerce which has really taken eGovernment seriously.  Read more on Digital IQ. 

9:21 PM | Comments () | Recommend This | Print This

Using the DTO Design Pattern with EJBs to Produce XML

In reference to my earlier experiments with SOAP and EJBs, Randy Gordon pointed out an article to me on using the Data Transfer Object design pattern to return XML from your EJBs.  This isn't (directly) a way of exposing a SOAP interface, but it does offer a fairly convenient method for returning XML data from an EJB method call.   

For those of you not familiar with DTOs, the pattern creates a single object (usually a regular Java Bean) as a container or aggregator for data being returned from a remote method call.  This avoids lot of fine grained network traffic from individual getter and setter calls to the bean.  DTOs have the usual getters and setters you'd expect in a bean, but can have other methods as well.  This technique makes use of the the JOX (Java Objects in XML) library to create a toXML() method for the bean.  The EJB session bean creates the DTO and populates it with the required data and then returns it as the result of the remote method call.  The calling object can then get XML by calling toXML() on the DTO. 

9:06 PM | Comments () | Recommend This | Print This

Public Service Tip No. 2: Beware the Jabberwocky

As part of my series of tips for those entering public service, I offer a chapter on the Jabberwocky of state government: the legislature.  One of the hardest things to figure out for a private sector mind in public sector life is the legislature.  This was, probably, my largest failing and one thing I'd put a lot more effort into if I were to do it again. 

One of the great wonders of democracy is that every year we turn the budgeting and operation of a $7 billion organization over to a large, unwieldy group of poorly compensated small businesspeople, ranchers, teachers, and housewives.  Then we tell them they better look like heros if they want to win the respect of their friends and neighbors so they can come back and do it again.  The first time I sat through a legislative subcommittee meeting, I was physically ill.  There's almost no hope of doing "the right thing."  You have just hope there's not too much damage when the smoke clears.  The problem isn't that these aren't good intentioned, bright people---they are.  They're just caught in an interesting situation. 

Now, let's face it, if you've been selected to be a state CIO the problem you have is you're a geek.  Any good CIO is likely more geeky than the general population.   I've worked hard to overcome my geekiness and for the most part, I clean up pretty well; but I'm still not very comfortable meeting and building a relationship with 100 people who are hard to get a hold of, don't care about IT, and have their own agenda.  Some people are great at it.  They make a nice living as lobbyists.  I'd just as soon put a nail through my hand.  I'm happier writing white papers, talking to the Enterprise Development Group, or trying to optimize desktop management. 

There is no vorpal sword that will slay this Jabberwocky.  You must work carefully and continually on talking to individual legislators, understanding how the process works, knowing who can influence this thought or that, and educating as many as will listen on how IT can solve their problems.  This will probably consume a large part of your time.  Its worth it.

One of the best pieces of advice I ever got on this topic, although it came too late, is this: whenever you talk to a legislator, make sure you're answering the question that is foremost in their minds: "what's in it for me?".   Sometimes with IT, that's a hard thing to do.  Particularly if they see IT as being a key part of the Governor's agenda.  They might see any IT success as a loss for themselves.  I think that's been a large factor in what's happened with IT in Utah over the past year.  I've tried to prod the IT Commission into taking a stand and setting an agenda.  They cannot or will not.  In any event, they haven't and the citizens of Utah are worse off for it. 

2:25 PM | Comments () | Recommend This | Print This

December 11, 2002

Finding Books at the SLC Public Library

Let's say, you're on Amazon looking at a book and you'd really like to read it, but you're not sure its worth buying.  Then you hit on a great idea: you'll try something really old fashioned and check it out from the local library!  Now, you could schlep down to the library and look it up or maybe even go to Google and see if they have a web site; but, Jon Udell has provided a much convenient way: a bookmarlet (no pun intended).  Just drag the following link to the Personal Toolbar in Mozilla or the  "Links" toolbar in IE and then when you're looking at a book at Amazon, Borders, etc. just click the link in the toolbar.  You'll find out if its available at the Salt Lake City Public Library. 

Salt Lake City Public Library

This is really too cool for words.   Try it out.  Jon has a list of other libraries and some notes on how it works, once again demonstrating that the power of the Internet can be had in bits and pieces, a few scripts at a time. 

Update: This works just fine in Mozilla as well. 

8:35 PM | Comments () | Recommend This | Print This

Tablet PCs: A Frist Look

This afternoon I got to spend about 15 minutes playing with a tablet PC from Acer  (TravelMate 100) and one from Compaq (TC1000C).  I hefted them wrote on them, and played with some of the apps.  My first impressions:

• I think I'd like one of these.  They have a very nice form factor that is more usable than a notebook in a meeting, airplane, etc. 
• I liked that COMPAQ keyboard detached.  It wasn't a lot lighter, but it was much thinner. 
• The Acer was VERY hot on the bottom.  It would cook your legs if you had to sit with it on your lap.  The COMPAQ was nice and cool (they'd been on for about the same length of time)
• They're pretty expensive for something which I don't see replacing my laptop.  I'd like one, but not as my only notebook.  I'd give up my iPAQ for one though. 

4:18 PM | Comments () | Recommend This | Print This

Web Services Ecosystem Meeting

This morning I spoke at a meeting of the Utah Technology Alliance on web services.  I posted a copy of my slides yesterday.  Rod Linton, who heads UTA, was the host of the meeting and there were probably about 30 people there from Utah companies with an interest in web services. 

After my talk, Henrique DiAguantini, Utah's International Office spoke on the upcoming trade missions that the Governor's office and DCED are putting together.  Henrique is specifically interested in central america, but there will be trade missions to a number of places around the world.  I was really looking forward to going back to Asia, but I won't be doing that now. 

Evelyn Rodriquez, who, among other things runs the Chasm Bridge conference, has set up a Yahoo! Groups email list for utah companies and individuals interested in web services at utah-ws{at}yahoogroups.com. 

The group broke into two subgroups to discuss standards development and marketing/education.  The standards group has been and will continue to monitor various XML standards and find volunteers from Utah companies to work in standards area.  The Marketing/Education group is putting together case studies of what others have done, why it worked, what the ROI was, etc.  They're also putting together templates and toolkits for Utah companies to build these case studies.  The ultimate goal is a web site with case studies from Utah companies that can be publicized and marketed.

A few upcoming events: UITA is sponsoring a Web Services summit in the spring.  Evelyn is running a ChasmBridge conference on web services in March in San Jose. 

A few people I ran into: 

• Al Byers from the Web Automation Group has an open source XSLT debugger.   I haven't tried the tool out yet, but I've written before about what a bear XSL can be to debug, so I'm anxious to take a look.   I know that there are tools like that in Visual Studio .NET (and I have a copy I've been meaning to play with). 
• I also ran into Scott Lemon who has a blog called the.Inevitable.Org/anism.  Scott's name was immediately familiar to me because I've been to his blog before.  Scott has been kicking around the Utah high tech community for some time (worked for for Novell four times).  Right now he's serving as Chief Scientist for a company called Vultus.  Vultus builds javascript apps that run inside the browser. They used to be called iBASE and I've talked to them before.  Pretty cool technology for the presentation layer.  I wonder how something like this meshes with thick clients that some people think might be making a come back. 

At the end, Evelyn Rodriguez ran a workshop on making contacts.  It was an interesting format.  Each person introduced themselves, what they do, and who their most wanted client is.  The group then volunteers contact information that they have to help get them in the door with a warm lead.  It worked surprisingly well. 

9:00 AM | Comments () | Recommend This | Print This

December 10, 2002

Web Services for Payment Portal

Speaking of web services, one of Utah's Enterprise eGovernment projects is a common payment portal.  Lloyd Johnson is the project executive.  Back when we were building payment gateways for First Data Corp., one of the biggest parts of the job was creating SDKs in all the languages that people wanted to interface to it with.  As I found out over the weekend, SOAP can solve that problem with a lot more finesse.  I don't know that Axis is the right tool, but putting a SOAP front end on the payment portal would be a very slick way of allowing language independence. 

7:52 PM | Comments () | Recommend This | Print This

Utah Tech Alliance Web Services Meeting

I'm speaking at the Utah Tech Alliance's Web Services Meeting tomorrow morning.  Here's a copy of the slides I'm going to use.  The talk is based on my "Enabling Web Services" white paper with a few slide thrown in about why government should care.   I'll be blogging the meeting as I can---maybe I'll feel better about missing Supernova. 

 

7:06 PM | Comments () | Recommend This | Print This

Information Week Article

My blog gets an mention in this Information Week article on Radio allowing you to do more with less. 

3:59 PM | Comments () | Recommend This | Print This

Grid Computing for Content Delivery

This article in InfoWorld discusses Kontiki's grid based content delivery system.  The basic concept is Napster with an eye to what enterprises need.  They've taken it one step further and removed the user from having to decide which peer to download from (remember the traffic lights on Napster?) so that downloading from the system is transparent.  Just point and click.  When people talk about "grid computing" the analogy is usually something about computing utilities, but this is a real world example of a grid solving a real world problem: file downloads.  So, next time you hear grid, think content delivery. 

2:51 PM | Comments () | Recommend This | Print This

One of the Things I'll Miss

One of the great things about being a CIO is that you can get technology questions answered quite quickly most of the time.  Yesterday I was having lunch with a friend of mine at the David Chase Cafe (great place, btw) and he complained that his T68i phone didn't get very good reception at his house near there.  Sure enough, I pulled out my phone and I had no bars.  Today ATTWS was in the office for another meeting and so I asked about it.  My question was whether they'd built out all their cell sites with GSM/GPRS or were still making capital investments.  The answer is that all current cell sites are GSM/GPRS capable, but that the wavelength used for GSM doesn't travel as far as the frequency they use for TDMA.  ATTWS still needs to fill in some of the gaps and has a capital plan for 2003 to do so.  So, Bill, there's your answer. 

2:24 PM | Comments () | Recommend This | Print This

Good Enough is Best

I've received some comments on some of my recent posts of Google and WSIL.  Here are a few:

Umm..Google is hardly comprehensive. It misses about 90% of what goes on and, for that matter of fact, the ability to "text mine" is far different from the ability to comprehend what you extract.

Oy.  Where do I start? WS-Inspection (WSIL) is a way of querying a server for what Web Services it provides. It has some primitive linking capabilities, but basically, it is complementary to UDDI, not competitive. More importantly, you could not replace UDDI with it.

While I don't disagree with either of these points, I think they kind of miss a key fact: Good Enough is Best.  A realtively well-known essay called Lisp: Good News/Bad News/How to Win Big by Richard P. Gabriel has a section called  The Rise of Worse is Better which describes how a school of thinking - worse is better - leads to market winning products.   I like to think of it as "good enough is best." 

As techies, we're often too concerned with building the perfect solution instead of the solution that works good enough.  The fact is that google works very well and does so much right now that most people are continually amazed at it.  Does that mean that there won't be (or isn't) anything better?  Of course not.  But getting mind share for that better thing will be difficult because google already solves most of the search problems people have right now. 

As for UDDI, where do I begin?  UDDI, in trying to be all things, is nothing.  Show me the masses rushing to adopt it.  My point about WSIL and google is not that its equivalent to UDDI, but that it would solve most of the problems people have right now and do it in a way that is simple, easy to deploy, and doesn't require huge investments in infrastructure.  If UDDI comes along later, great.  But I'm not holding my breath. 

9:11 AM | Comments () | Recommend This | Print This

December 9, 2002

We're All Supersleuths

MSNBC has a pretty good little article by Steven Levy about Google.  What struck me was this quote about how Google has made supersleuths of all of us:

By empowering the masses to make use of the multi-terabit glory of the Web, Google has made supersleuths of us all. Privacy advocates are going crazy at the Pentagon’s plan to track citizens’ purchases, Web-site visits and phone calls. But as my search for the eBay seller indicates, with Google everybody is Big Brother.

This is exactly the point that David Brin makes in The Transparent Society.  Technology has the power to give us all clarity with respect to what's going on in the world.  Anything we want to know about we can.  The danger is not that technology gives us that ability, but when we try to restrict the information flows.  Its a lot less worrisome, to me, if the Pentagon can do all those things as long as I can do them too.    If we're all the watchers then the question of who watches the watchers is moot.  We all do. 

11:15 AM | Comments () | Recommend This | Print This

Connecting Perl to EJBs

As I mentioned on Saturday, I was paying with Axis, the Apache SOAP engine, and found (via Google, naturally) a good little tutorial.  Part III of the tutorial shows how to get Axis working with jBOSS (a good open source J2EE application server).   I didn't go through the whole tutorial (which shows how to use a Struts like tool to create a connection to the EJB once its had a SOAP interface exposed.  Rather, I deployed my class's gateway simulation bean as a SOAP service (took all of 5 minutes).  Then, I fired up SOAP::Lite and wrote a little Perl script to hit the gateway and do an authorization (another 5 minutes).  All in all, pretty slick---in about 10-15 minutes, I had a Perl interface to my EJB. 

11:05 AM | Comments () | Recommend This | Print This

December 7, 2002

Eclipse

While I was playing with AXIS today, the tutorial mentioned Eclipse.  Eclipse is an open extensible IDE developed by IBM.  The project is open source.  There's even a OS X version (latest release) available.  I downloaded it, but haven't had time to play with it yet.  I'll discuss it more later, if its worthwhile.  IN the meantime, there's a white paper available that gives and overview. 

One thing I am aware of is that Eclipse will perform some of the same functions as Xdoclet in preparing EJBs.  Xdoclet is for those of us who like command lines, emacs, and build tools like ant.  IDEs are for GUI types.  Take your pick. 

5:13 PM | Comments () | Recommend This | Print This

Using SOAP with EJBs

I spent a few hours today playing around with Axis, the Apache Software Foundation web services tool.  One of the things I wanted to do was to get a SOAP interface to some EJBs running on jBOSS.  There's a half done tutorial at the jBOSS site, but there are no examples in it yet.  Google led me to a great little tutorial on Axis and, in part III, jBOSS.  I recommend starting with part I and working your way through it.  It says, BTW, that you need Java 1.4, but I found that 1.3 worked just fine.  One of the things you get from using SOAP with EJBs is a workable .NET interface to your J2EE apps. 

One of the things I did get from the jBOSS tutorial was a great little definition of web services.  Web services are self-contained pieces of code that have three distinguishing properties:

1. They communicate in an interoperable XML protocol, such as SOAP.
2. They describe themselves in an interoperable XML meta-format, such as WSDL.
3. They are able to federate globally through XML based registry services, such as UDDI.

I like that its not defined in terms of SOAP, WSDL, and UDDI, but rather in terms of the overall functionality, with those three things given as examples.  For example, I think you could substitute Google and WSIL for UDDI and still have an XML based registry service that allows services to federate. 

5:02 PM | Comments () | Recommend This | Print This

December 6, 2002

Public Service Tip No. 1: Process Is More Important Than Results

With the rash of new Governors, there's bound to be a new crop of state CIOs as well.  Given that, and my recent resignation, I will, from time to time, offer a tip or two on things I learned in the public sector in hopes of sharing my experience with those contemplating such a move.  Public service tip no.1 is "Process Is More Important Than Results."

I had lunch with Rich North, who works in the Legislative Research and General Counsel's office right before Thanksgiving.  At one point during the lunch, he said something to me that left me incredulous: "remember, process is more important than results."  Maybe I misunderstood him, but nevertheless his words were full of wisdom.  The bad news is that even as late as the final week of my career in state government, I found that statement to be ludicrous.  The good news is that even as late as the final week of my career in state government, I found that statement to be ludicrous.  When you start to believe that, the borg has won.

Now, I'm all for process.  I preach it all the time.  Moreover, I've never knowingly violated an established process.  Still, the thought that process is paramount would strike any private sector mind as folly.   After all, even a nuclear submarine has a "battle short" switch.  Nevertheless, if you're going to have a successful career in government, you have to learn to accept the fact that results don't matter. 

Here's the deal: to achieve results, you've got to do something.  If you do something, you'll make mistakes.  Mistakes are, by definition, a process violation.  So the only way to reverence process at all costs is to do nothing or, at the very least, proceed with the utmost caution.  You've probably wondered why government service is so slow.  This is the reason why: people are being very careful.  They have to be, because any misstep can be deadly. 

Now, they don't start out that way.  Most people enter government service ready to change the world.   State employees are, for the most part, caring people who want to do right by the citizen.   The problem is that the longer you are in public service, the more you have of what a friend of mine refers to as "end of leash experiences."  You have enough of those and you quickly realize that to avoid them, you'd better stop running and look over your shoulder all the time.   I had a few end of leash experiences and it quickly got to me.  One of the reasons I decided it was time to step down is that I was no longer willing to jump into the fray.  I was watching my back and wondering how the borg would react to nearly everything I did.   I was more worried about making mistakes than getting something done. 

So, if you're going to have a long, successful career in public service, remember: don't worry about getting results; worry about the process.  You'll go home every night happy and retire after you've put in your 20 years with nary a scratch. People will congratulate you on being a good "administrator."   Personally, I can't feel good about cashing my paycheck unless I'm getting results and I'm proud to say that hasn't changed. 

5:52 PM | Comments () | Recommend This | Print This

December 5, 2002

The Tide is Going Out

This week alone five state CIO's have left the service of their states: myself, Richard Varn of Iowa, Larry Singer of Georgia, Judy Teller of New Jersey, and Rebecca Heidepriem of Wisconsin.  I think that three of those are due to Governor changes.  I expect more in the coming weeks.  These changes are likely to bring some changes to the complexion of eGovernment across the states.  Tom Davies writes about this in the latest issue of Governing Magazine. 

9:48 PM | Comments () | Recommend This | Print This

SmartUtah Tech Expo

This morning I spoke at the SmartUtah Foundation's Tech Expo in Box Elder county.  Here's a copy of my slides.  The talk was very well received and I had a number of people express their regrets at my resignation.  I also received a nice award from SmartUtah for "outstanding leadership in the promotion of electonic communities in Utah." 

9:29 PM | Comments () | Recommend This | Print This

The Real Time Enterprise

These two articles from CIO Insight, one a case study on GE and one by Cap Gemini's Christopher Meyer speak about the benefits of real time enterprise.  There's a follow-up interview with GE's CIO, Gary Reiner as well.  GE plans to save $10 billion with their real-time management systems.  Of course, that remains to be seen, but its clearly a trend that cannot be ignored.  Meyer says its "unavoidable."  My paper on the "Road to the Future" discusses the tactical steps that an enterprise must take to even be in a position to use real-time management systems to drive business decisions.  Among them:

• Infrastructure (network, data center, server, and desktop) consolidation and normalization
• Security
• Enterprise storage
• Reducing the number of databases and normalizing schemas
• Reducing applications and creating multi-use applications that share data

Any enterprise wishing to emulate GE, Siebel, and Cisco's real-time management initiatives needs to take stock of these other issues first and solve them or they're just wasting their money. 

2:03 PM | Comments () | Recommend This | Print This

December 4, 2002

Resignation

I submitted my resignation as CIO for the State of Utah this morning.  It is effective December 31, 2002.  I have many mixed emotions: anger, sadness, excitement, and relief, among others.  In my letter, I said:

With recent events, I have come to realize that I have become an impediment to implementing our vision for eGovernment and an efficient and effective information technology infrastructure. The conversation has increasingly become about me instead of the important work that needs to be done to benefit the citizens of Utah. Because of that, I have decided to step aside.

I also went on to outline some key roadblocks I see facing IT in Utah.  I'll have significantly more to say about the events that led up to this and what I see as the root causes in the coming weeks.  Suffice it to say, for now, that I take a very different view of this that my critics and I am now free to speak my mind. 

One of the questions that always comes up in these situations is whether the resignation was "forced" and the answer to that is a clear "no."   I've always had, and continue to have, the full support of the Governor.  The truth is I've been thinking of this for some time (as far back as last summer) and am excited about the possibilities in web services and related technologies and see some clear opportunities as the economy begins to recover.  I'm happy to be reentering the private sector---older, but hopefully wiser. 

10:55 AM | Comments () | Recommend This | Print This

December 3, 2002

Utah's Christmas Tree

Mrs. Leavitt lit the 2002 Christmas tree at noon today.  Each year we get a big tree and set it up in the rotunda.  I put together a photo album showing the tree arriving and being set up in the Capitol Rotunda.  

5:10 PM | Comments () | Recommend This | Print This

Scalability and Complexity

Sean McGrath asks in a recent article whether the complexity of frameworks like J2EE and .NET is necessary and uses, as a counter example, the web itself as an example of something that is elegant and simple, yet very scalable.  This question is at the heart, I think, of the arguments made by the RESTians.  The question caught my eye because I was having a conversation with a few of my student yesterday after class about a very similar topic. 

Each year, when I teach my class on building large scale distributed systems there is, of course, much more to cover.  If I'd taught the class in 1994, we'd have had lectures on HTTP, CGI-BIN, transaction monitors, and CORBA.  Now that isn't even one-tenth of the material that could be covered.  I've struggled in past years as to how to get messaging worked in and this year I did force an XML assignment into the mix. I would love to have had time to dive into SOAP, WSIL, etc.  No such luck.  It seems that the body of knowledge that a person building web-based transactional systems needs to know is exploding and the pace is not abating. 

Even so, I think I'd have to disagree with Sean's basic premise: "If you look after simplicity, then with the aid of some analysis and precise intervention, scalability will look after itself."  I disagree because scalability in almost all cases involves distributed programming.  My experience with distributed programming (which began with the SR programming language in 1987) is that it is complex and difficult to do in a way that delivers performance under high load.  Threads and transactions are inherently complicated.  You can't abstract away resource contention and deadlock.  The basic web has none of these problems because it was (and still is for the most part) a read only system.  The mutating parts are still localized which is where you see things getting complicated.  REST or not, mutation and scalability lead to complexity. 

Having been involved in the development of large transaction based system using CORBA and a prayer and then doing similarly sized systems in J2EE, I contend that these frameworks are lifesavers.  They do about as good a job of abstracting away some of the hard parts as you could expect.  Where I would have had 5 or 6 engineers chasing down failover, distributed transactions, etc.  and failing, I can have 1 or 2 and succeeding.   

7:22 AM | Comments () | Recommend This | Print This

December 2, 2002

XML and SOAP in Wisconson

I ran into this XML and SOAP standards project on the Wisconson eGovernment web site.  Its good to see a statewide effort in this area.  They've even got approved standards.  A little touch of irony, the categorization number they chose for this standard is 403.   

2:36 PM | Comments () | Recommend This | Print This

eGovernment and Pollution

Utah has a convenient, online system for renewing vehicle registration, but  I still hate it.  Why?  Emissions inspections.  I live in one of the counties in Utah where emissions testing is required before I can register my car and so even though I can register my car online, I still have to schlep down to the emissions inspection station and wait in line there and pay $25 to have them tell me all is well.   Registering a vehicle won't be convenient until I no longer have to do that.  I think that eGovernment can help.

Now, I'm all for clean air and doing my part, but the problem is that every year I get three vehicles inspected and every year all three pass.  In fact, my 2000 Silverado pick-up had the following readings:

	Hydrocarbons (ppm)	CO (%)
Allowed	800	3.50
Reading	7	0.00

What you'll undoubtedly notice is that I was so far under the specification as to be ludicrous.  All my cars are like that.  Every time.  So, the conclusion I have to make is that I spend $75 and 3-4 hours of my time every year for nothing.  It makes me even angrier when I'm following some car that I know is polluting because I can smell or see it.  They're going to go on spewing junk into the air for the next 6 months (on average). 

So, how can eGovernment help with this problem?  I broadly define eGovernment as the application of IT to the business of government.  In this case, the business is keeping polluting cars off the road.  I have a friend in Utah County who developed a van with all kinds of sophisticated monitoring gear that they park along the roadside and as cars drive past, they monitor their emissions and, if they're over limits, take a picture of their license plate and send them a warning.   Why not tale the money the government already charges me (the $75 I pay to get inspected each year) and every other car owner in Utah and spend that on infrastructure to deploy this solution more widely.   Make people get an inspection only when there is reasonable cause to believe they are polluting.  At least I'd save the time. 

9:57 AM | Comments () | Recommend This | Print This