Phil Windley's Technometria

« December 2002 | Main | February 2003 »

January 31, 2003

OS Backup Survey Results

Yesterday, I asked what people are using to backup OS X. All the advice I got said "Retrospect." This MacWorld article from July 2002 reviews them. There are some things that give me pause after reading it, but I guess I'll drop the money and see how it works. Here are a few other things I found:

• Mac OS X Management Software and Tips by Mike Bombich gives some advice on creating a bootable device in OS X and using ditto to create a mirror image.
• There is a project on Sourceforge called Psynx that I have no information on. I'm hesitant to try a back up program without other information.

12:05 PM | Comments () | Recommend This | Print This

January 30, 2003

And Now or Something Completely Different: Star Bridge Systems

I continue my tour of Utah high-tech firms. I see two to three people or companies per day on average and have been thoroughly enjoying it. Today I met with a company called Star Bridge Systems.. They make software for programming arrays of FPGAs into special purpose computers. Some of their claims would be completely unbelievable if they didn't have people like NASA and the NSA giving them credibility. They seem to be in pretty good shape, version technology, lean operations, and paying customers.

If you've read the article in Red Herring about the Tyranny of Moore's Law (not online yet), I think you'll see a corollary here. We mostly hear Moore's Law quoted as "speed doubles every 18 months." But speed is only one factor. Its equally true that the same speed CPU (or same sized memory) costs half as much. The world doesn't necessarily need faster computers, it needs ways to use the cheaper computers together. What Star Bridge (by the way---I hate that name) does is allow gangs of FPGAs to be used in place of supercomputers. The speed gains are phenomenal.

The heart of the Star Bridge technology is a iconic language called Viva that replaces VHDL and can be compiled to FPGA configuration files directly without the help of a designer who is a VHDL expert. You code your algorithm in Viva, compile it, and you've now got a special purpose computer that runs that algorithm and that algorithm only. Viva accepts description files for the target FPGA array so that it can be used with any FPGA array you happen to have (the Air Force, for example uses a two-FPGA array in a number of sub systems in various jets, missiles, etc.) I've done my share of VHDL coding and this seems like a dream to me. I'm hoping to go back soon and try my hand at it.

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

OS X Backup

I've had my powerbook for about a month now and am pretty comfortable with it. I don't have many complaints---its just an awesome machine. I'm starting to worry about things like backing up. Thats' my question for today: how do you back up OS X? I've found lots of commercial packages, and I don't mind spending money to get something, but I'd like to know its going to work. My most likely backup scenario is across a network to a SMB mounted drive.

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

January 29, 2003

On the Topic of Identity...

As long as we're on the topic of identity, I just read Andre Durand's paper on The Phases of Identity Infrastructure Adoption at Digital ID World. Andre's done a great job of laying out the problem and arguing for an adoption path that leads to acceptance of an individual's control of their own digital identity (an odd sounding phrase if you haven't read the paper).

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

NECCC Paper on Identity

NECCC is the National Electronic Commerce Coordinating Council. You may think, given the name, that its about business, but its really about eGovernment. It just sprung up before the term eGovernment was in vogue and back then, eGovernment was called eCommerce by folks. They have a comprehensive paper on the identity problem which lists current Federal laws as well as those of California (which is seen as a bell weather state). It also talks about options, and how governments could respond. They're more ecumenical than I was in my article in Digital ID World. As an aside, the paper says that its target audience is elected officials like Governors. If so, its 67 pages too long.

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

Global XML Web Services Architecture

Yesterday I wrote about the web services framework that Microsoft and IBM have pushed forward. That framework has taken for in the Global XML Web Services Architecture, or GXA. The architecture is apparently the product of a consortium headed by IBM and Microsoft with help from Verisign, BEA Systems, RSA Security and SAP. I frankly don't know how much of a consortium it is and how much is being driven by Microsoft, but I'm hopeful that the results won't be .NET specific. As I wrote yesterday, the goal of GXA is to fill the gaps that SOAP, WSDL, and UDDI leave in solving real business problems. GXA is being developed with the following general principals:

• Decentralization and Federation - GXA specifications are designed with "constrained agreement" in mind.
• Modularity - GXA is built using modular components rather than large, monolithic specifications that offer end-to-end functionality.
• XML-Based Data Model - GXA is SOAP-based.
• Transport Neutrality - GXA is specified entirely at the SOAP level and thus is not HTTP or message specific.
• Application Domain Neutrality - GXA specifications are general-purpose solutions to broad problems that span application domains.

These principals are important if GXA is to sit between vertical market-specific specifications and protocols and the base SOAP protocol that provides the foundation for web services. A number of draft specifications were released for comment in December 2002. A few comments:

• Not surprisingly, the security piece has had the most work done. Without security, there's not much hope that web services will be used for business transactions and security is a place where web services have taken a lot of lumps in the past year.
• Also not surprising is the fact that the list of policies isn't a one-to-one match up with the framework that was proposed over a year ago. I'd expect to see all of the categories covered eventually, but they'll morph and split in funny ways as people really start to solve the problems.

I plan to investigate and write about each of these policies over the coming days.

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

Conspiracy Theories Aplenty

I was contacted by three different people today about the fact that my name is still in the Utah Master Directory, even though I've left the State. Why its still in there, I don't know. I did request that it be left in a for a few days after the first of the year because I hadn't had a chance to send a thank-you email to the Cabinet and hadn't yet downloaded some of my old email due to my father-in-law's funeral over the holidays. This, of course, didn't stop the conspiracy theorists in the State (and there are plenty---that's what people with lots of free time do to keep from being bored) from concluding that I was the invisible hand and still involved somehow.

Well, rest assured, I'm neither involved, nor do I want to be. Even if I was involved, why would I need a State email address? Don't you think a conspiracy would be smart enough to not use the State email system? I stopped trusting it way back last September as "insecure" for anything I wanted to keep out of the prying eyes of the conspiracy buffs. Frankly, I'm happy to be a private citizen again, because I'm free to say things I couldn't have said as CIO. And there's plenty I want to say.

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

Government Computer News

My comments on web services are covered in a short article in the January 27, 2003 issue of Government Computer News under the title "Former Utah CIO Offers Pointers." I really like that they point to my blog. :-)

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

Hey Apple! A Feature I Want in iChat

I was just sitting here working and noticed on my AIM buddy list that someone had gone red. That is, they marked themselves as "being away" even though they're still logged in. This of course is perfect. One of the things i like most about IM is presence; that is, knowing when someone is around in my virtual world. The problem is that people don't usually do this. They let the machine mark them as idle (not bad) or log out (which means they could be there and just not logged in). What I want is for my computer to know when I'm there and when I've stepped away...even if I'm not using it. The great part is that I have all the pieces that would form a solution right now.

I use bluetooth on my powerbook and have a Sony T68i bluetooth equipped phone. I want iChat to mark me available (unless I override) whenever my powerbook can see my phone and mark me away when it can't. My phone becomes my "presence" token. I don't know if iChat has the right hooks to be able to script something like this or not, but it would be a neat feature.

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

January 28, 2003

Web Services Framework

Over the next little while, I'll be working my way through some web service stuff that I'll document here. If you're not very familiar with web services, join me in my study. If you're an expert, feel free to skip these.

At a W3C workshop on web services on the 11th and 12th of April, 2002 (forever ago in WS years), IBM and Microsoft presented a web services framework that addresses some specific issues directly related to interoperability of decentralized services. In some ways, the need here is the same as the void that PingID is trying to fill in the identity world. There's more to interoperability than some common protocols (although that's a start).

IBM and Microsoft presented a paper entitled Web Services Framework which listed the following functions as being key components in a working web services model. Where an existing protocol fits the need, its listed in parentheses to the side.

• Message envelop and controlled extensibility (XML Protocol) - I think of this as MIME for XML, maybe too simplistic, but it works for me.
• Binary attachments - Serialization may not be practical in all circumstances (i.e. converting the binary data XML may be too expensive). Passing by reference is a possibility.
• Message exchange or routing - Sending messages through intermediaries who may act on the message or modify it (e.g. wrap it in something to certify origin, etc.)
• Message correlation - Multiple message may be sent for one purpose and need to be reassembled or sorted.
• Guaranteed message exchange - Think JMS, but not language or vendor specific.
• Digital signature (XML Dsig) - Signed messages for all the usual reasons.
• Encryption (XML Encryption) - Encrypted messages for all the usual reasons.
• Transactions and activities - Multiple activities often need to be atomic (i.e. they all happen or none of them happen). Transactions accomplish this, but traditional models will not likely work in high latency scenarios.
• Service description (WSDL) - Describe (document) the service. My opinion is that WSDL is a good start, but doesn't go far enough. For example, it can adequately describe data resources made available in a RESTian way.
• Process flow contract description - Work flow for XML.
• Inspection (WSIL) - Metadata about services that would point to the service description and process flow description.
• Discovery (UDDI) - Automated discovery of services. I think we're still yet to see this become practical for a variety of reasons.

There are a number of specifications proposed to deal with these functions in the intervening year. It should be noted that other players like ebXML and ITEF are working on this same problem and likely have other classifications and other answers, but for now, I'll follow this path.

Web service discussion typically talk about three formats for protocols: wire-level, description, and discovery. Wire-level protocols are all those that represent or control what is sent during an exchange. So, when someone in the WS world talks about a wire-level protocol, they're not talking about the ISO network hierarchy. This confused me for a while. They're talking about message exchange and the things that control or augment it. From the list above, everything but a few are wire-level. Service description and process flow orchestration are both description formats and inspection and discovery are both discovery formats.

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

Wasatch Digital IQ

Wasatch Digital IQ is a magazine that covers the high-tech industry along the Wasatch Front. For those of you not familiar with Utah, the Wasatch Front is the range of mountains along which 80% of Utah's population lives in a 100 mile strip. WDIQ has recently upgraded their web site in a major way with articles online, and other, daily features. They've even added a blog section some guest "columnists" will blog about particular topics. Overall, I think they've done an outstanding job on the upgrade.

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

PingID and SourceID

Anyone who was at Digital ID World last year probably thought PingID was already launched, but today is actually their official birthday.

PingID provides a "network" for processing federated identity transactions in the same way that Visa or Mastercard provides a network for processing credit card transactions. Network in this sense doesn't mean wires and routers, but rather the protocols, agreements, and legal framework that makes transactions between two unacquainted parties possible. Like Visa and Mastercard, PingID is member-owned, meaning that the companies who use the network have an equity stake in it.

According to the PingID web site, the PingID services include

• Standardized business agreements for federated identity.
• Standardized processes for resolving disputes
• Access to enhanced interoperability services.

I think the last one probably need more fleshing out, but anyone who contemplated establishing a single-sign-on (SSO) relationship with a customer that requires more than one party provide the service will understand the first two. When I used to build e-commerce services, our business model included lots of partners providing services to the merchants (we sold that right for quite a bit of money). We were trying to do SSO with 20-30 entities for our customers and it was a lot of work to maintain those relationships, code up the various terms and conditions that each entailed, and figure out who was at fault when something went wrong. PingID would have been a welcome partner.

A related entity is the SourceID open source project for identity management. The first SourceID project is an open source implementation of the Liberty Alliance specification for SSO. PingID and SourceID aren't formally related, as far as I can tell, but they have the same founder Andre Durand of Jabber. My take on this from talking to Andre and Eric Nolin is that SourceID is the pointy end of the SSO stick and PingID is the business network that ties it all together.

Disclosure: I'm on the advisory board of PingID.

8:32 AM | Comments () | Recommend This | Print This

January 27, 2003

Representations and URIs

Jon Udell references a discussion that has been raging on what a URI represents. Jon quotes Tim Berner-Lee who summarizes it, succinctly, as follows:

What does "http://www.amazon.com/exec/obidos/ASIN/ 0679600108/qid=1027958807/sr=2-3/ref=sr_2_3/103-4363499-9407855" identify?

1. A whale
2. "Moby Dick or the Whale" by Herman Melville
3. A web page on Amazon offering a book for sale
4. A URI string
5. All the above

I find this question fascinating since it takes me back to my formal computer science roots. A long time ago, I was a formal methods researcher. Sherman, fire up the way-back machine:

In the late 80s there was a huge battle raging in some professional journals and letters to the editor in Communications of the ACM (CACM). (Remember, this was before blogs or even the web.) Demillo, Lipton, and Perlis had published a paper called Social Processes and Proofs of Theorems and Processes. It was followed by a paper in CACM by James Fetzer called "Program Verification: The Very Idea." Fetzer argued that proofs of correctness for programs was ridiculous from the start since the artifact had many properties that the proof could not consider. In 1989. Jon Barwise (who is now dead, unfortunately) wrote an eloquent paper in the Notices of the American Mathematical Society called "Mathematical Proofs of Computer System Correctness". Barwise argued that Demillo, Lipton, Perlis, and, especially, Fetzer had made a critical error by confusing the thing with the mathematical representation of the thing. Sound familiar?

The very essence of Applied Mathematics, and by extension, Computer Science is the notion of representation, naming, and abstraction. Confusion in these issues shows up quite frequently when students are learning about naming in a programming language theory course. (I always like to ask the question "What is '3'?") Confusion in these issues can lead to significant problems as the theory is developed later.

From a formal semantics viewpoint, a URI, like any other name, has to represent the thing that it is bound to and nothing else. That is, the URI represents whatever is returned when the URI is dereferenced. What is returned in the case of a URI is a string of bits. The resource that is returned may represent something else, but the URI is just a name for the resource. It carries no semantics beyond that. The resource is a model of something. The mathematics behind all of this is quite well developed and well thought out. This problem is a classic CS problem, not something that the web invented.

As an example, consider the URI for tracking a package at UPS. The URI is merely a name for the resource. That same resource could have millions of other names that all dereference to the same resource. The resource is a model for a package. That is, its an abstraction, based on properties, of a physical object. We must not confuse the model with its name and we must not ever confuse either of them with the artifact that the model represents.

For those who are interested in this kind of thing, Mike Gordon's The Denotational Description of Programming Languages: An Introduction is a great, readable introduction by one of the luminaries in the field.

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

Semantics for Web Service Description

David Booth, a W3C Fellow, has a picture which I've seen in several talks and wanted to document. The picture shows how a web services description (WSD) is referenced by the client and the server, but, more importantly, how it references semantics. XML semantics has been something of a pet peeve of mine in the past. Here's the picture:

The point that David makes is that the server and the client have to agree on semantics. If they don't, of course, the result is gibberish. The semantics might be in some formal langauge, although not very many people enjoy writing formal semantics of anything. I used to do this; its very time consuming. More likely, the semantics is just in written in English. David wants the semantics to be written and referenced by the WSD so that it can be found and used by the programmer. I think this is an excellent idea. Even a natural language semantics would be very helpful in understanding the WSD and applying it.

David suggests using the "targetNamespace" attribute in WSDL for the reference. I have no idea whether that's a good idea or not. I do know that other people have other ideas about what that attribute should be used for.

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

Superbowl.com

I just noticed a link on Technorati to superbowl.com. I used to own that domain (1994-1996) so it always sparks my interest. I did the Superbowl sites for Superbowl XXIX and XXX in conjunction with the host committees in Miami and Phoenix. In 1996 the NFL sent us a "cease and desist" order and said we'd be in court the next week. They had more lawyers than I knew, so we transfered the domain to them and got out of the Superbowl business.

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

Federal DRM and Web Services

If you're at all interested in what the Federal Government will do with web services, one thing to keep your eye on is the Data and Information Reference Model that's one layer in the Federal Enterprise Architecture. The DRM is important because its the key to transforming government. Application integration is only part of the problem. Fundamental data analysis and modeling is the foundation upon which collaborative applications can be built.

If you follow the link to the web site, you may be disappointed small amount of content there; the DRM is the least developed of the enterprise architecture layers. Still, if you dig around there's plenty of information available on what people are thinking. Here's some of it.

The DRM is:

• Business-focused data standardization.
• Cross-agency information exchanges.
• Federated Registries and Repositories organized according to the Business Reference Model.
• An agile framework for building new cross-agency applications and services.

The DRM will not be:

• A government-wide data model.
• A government-wide markup language.
• Complete!

The last bullet is particularly important. The goal isn't to build a complete data model, but to build the meta-model that data lives in. Probably the best example of collaborative data sharing and collection in government at present is the FedStats web site.

So, what does this have to do with XML and web services? At its core, the DRM is addressing that problem of data sharing and that's what XML is good for. The move seems to be to use XML repositories and registries to build these data models. There are a number of projects around the Federal Government that are being pointed to as "pilots" for DRM efforts. One example is the Global Justice Information Network effort with XML that I've referenced before.. Another example is an IRS Small Business Resource Guide project. It may look like HTML upfront, but underneath its all XML and can be easily repurposed with different views for different users.

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

Email Consolidation

I've heard that the email consolidation project that the Cabinet approved as part of Utah's IT plan will be axed. This doesn't surprise me. If I were still around, I'd have probably let it die as well. The project isn't failing for technology reasons. The project is failing because:

1. Agency IT personnel won't cooperate. It was a gamble from the start to take the very people who are running email in the agencies now and ask them to come up with a plan for changing it. They have little motivation to do so since they like the status quo. I didn't attend the meetings, but I understand that some of them were downright hostile.
2. ITS is not positioned to make it work. ITS has to be able to take this service over and run it flawlessly for this project to have the desired affect (see below). At one point, a few months ago, the current ITS-run email service was offline for dozens of hours over a period of time, completely unmonitored. No one's going to trust that. At the same time, you'd have a tough time convincing a lot of people in ITS that there's anything wrong. That's a problem.

Some will claim that the ROI just wasn't there, but that's a red herring. The ROI for email consolidation was never the point. The whole point of the exercise was to prove it could be done. Why? Because until you can consolidate email, you've got no hope of consolidating more complicated services like LAN administration and desktops. That's where the ROI is.

The State of Utah spends $10-20 million per year more on IT than it needs to. To see those gains though, IT would have to be organized very differently. The real kicker is that they could not only save the money, but get better service as part of the deal---if its done right. At this point, however, I think the email consolidation failure has shown its going to take a lot more than the Cabinet asking to have it done to make something like this work. My fear is that the legislature will try to force it through cuts without giving the CIO the authority to change the organization. That's what they did last year and it was a disaster.

8:08 AM | Comments () | Recommend This | Print This

January 24, 2003

New Technologys, Sensor Nets, and Tranparency

In a perfect example, of why I love blogs, Dave Flecher was pointing to this article from Technology Review about 10 Technologies that will Change the World. Look at the first one and then read my article from earlier this week on sensor grids. Imagine having real time data from large cooperative grids of sensors like these. I think places like DARPA and NSF ought to require web access to data in machine readable form (aka web services) for any research they fund.

These kinds of sensor nets bring to mind David Brin's thought provoking book, The Transparent Society. Brin argues that we won't get a choice between whether data is collected or not collected. We'll only get a choice about who has access. Think about sensor nets made of devices like those in the TR article in 10 years, when you can buy each sensor for 25 cents and could afford to blanket an area with them---any area. Cheap, disposable, and easily concealed, they would turn almost anyplace, on a whim, into a completely monitored fishtank.

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

January 23, 2003

Public Service Tip No. 4: Living with the Redbilled Oxpecker

This story is part of a ongoing series of tips for those who might be entering public service.

One of the interesting things about working in the Governor's Office is that any time you can't make it into work, you can catch up on the day by reading the paper. Even knowing this beforehand doesn't prepare you for the overpowering, suffocating nature of the press coverage. Even in a small state, the press hangs onto the political machine in a manner not unlike the symbiotic relationship that the redbilled oxpecker has with the rhino. The press depends on government and government is fashioned by the press.

The most important lesson to learn about the press is that they always get it wrong. I've been interviewed dozens of times by friendlies and non-friendlies alike and there have been errors of fact in every single case. I never see a single story in the newspaper or on TV anymore that I don't ask myself what the real story is. The errors are not necessarily made maliciously; the press simply doesn't usually spend enough time or have the right background to fully understand a story. This is doubly true when they're dealing with technology.

A large part of the problem is that, just like you and me, reporters have lives and they have jobs. Most of the time, their writing is just part of the job. They're assigned some story from their editor, which they don't know or care about. They have to write 1500 words before they can pick up their kid from day care and grab a pizza. So, they write 1500 words. They call a few people, get a few quotes from the old favorites and file the story. The story that's going to have significant impact on your program or even your life is, to them, just a task standing between them and Monday Night Football.

The problem is exacerbated by the fact that reporters do not live in the real world. They have little understanding of the kinds of things anyone in the private sector takes for granted. They work so closely with bureaucrats that their attitudes more closely reflect those of the government that they cover than they do the attitudes of their readers.

Much of what you see reported is gleaned from other papers. When you're on the inside looking out, its relatively easy to recognize where certain statements and information comes from. Often it comes from another story. Salt Lake has two major dailies, one in the morning and one in the afternoon. They often decide what to cover and even what angle they're going to take by reading the other one. They all quote each other's inaccuracies with regularity. Once something gets started, its impossible to correct. Work to get it right upfront.

I found reporters who I respected and liked to work with, even when they weren't writing good things about me. Invariably, these were the ones who worked hard to understand the story. There are others for whom I have little respect because the got the story wrong in spite of any effort to help them understand the facts (simple things like the org chart come to mind). I reached the conclusion that they didn't want to know the facts because that would make the writing that much more difficult or contradict with the paper's editorial position.

You may not like the press and they may not be very helpful to your agenda, but they are as much a part of the political ecosystem as the redbilled oxpecker is a part of the savannah. Learn to accept that fact, live with the mistakes and the occasional pecks, and you'll sleep better at night.

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

Wireless Broadband

I live in Lindon Utah, a small community too small to attract capital from companies like ATT or Qwest. Consequently, my broadband choices have been pretty limited. When I worked for the State, I had an ISDN connection to the State network that was good enough. Being reasonably fast and always on, it did the job. Leaving the State forced me to get another solution and given my available options, fixed wireless was the most obvious choice.

I've shied away from wireless broadband in the past because, frankly, most of the companies are small and calling up customer support and getting a response like "I'll have Joel call you at 3:30 when he gets out of class" wasn't my idea of fun. But I used dial-up for a week and decided that anything was better than that.

I signed up with a company called ConnectBBS and got my install this morning. ConnectBBS is going around the Wasatch Front buying small wireless broadband companies and rolling them up. Probably not a bad play. The service is fair and the price reasonable. I'm getting around 220 kbs according to Bandwidth Place. They didn't get my router installed on the net correctly, but it didn't take too long when I got home to figure out and get it working.

Being interested in this sort of thing, I probably made the installer nervous by following him around and asking lots of questions. This is not a business with huge barriers to entry. After 30 minutes with this guy, I think I could set a wireless broadband network up in my neighborhood without too much trouble. Its just dirt simple. The second hardest part is knowing where to buy the equipment. The hardest part, and one which will probably make or break most of these companies, is customer service and having an infrastructure that will allow the network to be monitored, fixed, and tweaked without a lot of truck rolls. I was impressed that the customer support tech who answered my call was knowledgeable and could see what was happening on my end (like when my router finally chimed with their DHCP server and picked up an IP address).

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

January 22, 2003

Earthviewer as the GIS GUI

I got an email from Dave Lorenzini of Earthviewer today. He'd seen my articles on the open GIS consortium and grid sensors. In my Open GIS article, I'd said:

I think its interesting to compare this with Earthviewer. In my opinion, Earthviewer has one real advantage vis a vis other GIS tools: their user interface.

David confirmed that the goal of Earthviewer is to work with all of this GIS data and sensor information and provide the user interface to the data. They shine there and I haven't seen any other tool that does what Earthviewer can. Earthviewer has recently upgraded their data set to include 1m resolution data over the US and some very high resolution data for major US cities.

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

January 21, 2003

Wi-Fi TCO

Ever since I wrote the piece on wireless workplace wisdom for Matt Jones, I've been thinking over the whole Wi-Fi ROI issue. One side of that equation is total cost of ownership, or TCO. Here's what I've been thinking so far.

TCO is an attempt by IT professionals to consider the true cost for a given technology. Its pretty easy to ignore some pretty significant costs when you get emotional about a new technology and can't wait to deployit. Take, for example, desktop machines. The cost of the machines is only a small portion (about 10%) of the total cost of owning and operating one in a commercial environment. There's software, administration, maintenance, support, training, etc. We can contemplate some of those issues for a Wi-Fi network as well. Here are some of them.

• Wireless access points, or WAPs (including antenna) Understanding how many you'll need may be simple in a straightforward installation or require the help of RF engineers in more complicated environments. Certainly anyone contemplating the installation of more than a half a dozen or so ought to do some engineering to ensure adequate coverage at the least cost.
• Wireless cards. You'll need cards for each device that will be connect to the Wi-Fi net. No fair ignoring this one, even if the price is coming from a different part of the organization's budget. If someone other than the organization will bear the cost (like students in a campus setting) you ought to at least recognize the resource commitment required even if you don't add it into your calculation.
• Router and switch ports. Depending on your installation, particularly your security solution, you may need to route the wireless network differently which will mean using ports on your router. At the very least, you'll be burning switch ports. They're not free. Figure out what a port costs you (on a TCO basis).
• Installation and engineering costs. Unless you're putting in a small network, your engineering and installation costs will be significant.
• Security. I prefer using unrouted 10. or 192. nets with a VPN providing connectivity for a few reason that I won't go into right now. You probably already have a VPN solution, in which case this will be a marginal cost for additional users or licenses, or you may need to set up something brand new.
• Administration. Some may wonder why I don't like MAC address filtering for the security aspect. This bullet is the answer. What is the administration cost of the wireless network? If you're doing something like managing MAC addresses, it could be fairly high. In any event, you'll need to purchase and track new assets, manage WAPs, and add processes for detecting intruders on the new net, etc. Figure out what these might cost you. Be generous. Administering hardware always costs more than we think.
• Support. I like to treat this separately from administration. Users with new gear and new connectivity options will call your help desk. What are you going to tell them? Are you going to build support self-service features like FAQs or help videos? How many more calls per user per month will Wi-Fi generate?
• Training. This is one that geeks always miss because we're used to pulling stuff out of the box, throwing the instructions away and playing with the gear until it works. Others not only need, but really appreciate, training. You may think a Wi-Fi network is dirt simple, but its got some gotchas, depending on your OS. If you're using XP, things work a lot better than other MS varieties. Even so, having more than one network connection will throw some people for a loop. If you don't put anything in for training, double your support costs.

If a wireless LAN is to affect your competitive advantage positively, you need more than the wireless LAN itself. You may find that there's little value in a wireless LAN without significant investment in other pieces of your technical infrastructure. The following are examples of the kinds of infrastructure issues you should look for.

• Unless you are contemplating a special purpose LAN such as one in a manufacturing environment, the standard office won't have much use for a Wi-Fi LAN unless there are mobile devices to take advantage of it. Mobile devices such as laptops, PDAs, or tablet PCs are the most likely devices to use a Wi-Fi LAN. If they aren't widely available in your organization, you may be building a Wi-Fi LAN that will only lead to a slew of requests for laptops in the next budget cycle.
• Applications and data must be available and usable. CRM, ERP, and corporate resources such as file and print servers should be just as usable from the Wi-Fi LAN as they are from the wired LAN. Ensuring that this will happen may require that these systems be upgraded or changed out.

I wish I had pointers to some nice studies that outline typical costs for some of these. I don't. If Gartner or Burton have some, I'm not aware of them. So, you'll have to guess. But even a guess is better than just ignoring a cost completely. Some of these are one-time costs and some are on-going. Which are which is fairly obvious. Obviously, they need to be treated differently. In some future article, I'll talk about benefits and then we can put it all together for an ROI.

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

January 20, 2003

GCN Article

Government Computer News published a short piece about my talk in DC last week.

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

More on Grid Sensors

Dave Fletcher picks up on my riff about grid sensors or sensor nets and mentions a couple of sites that give real time data for seismic data (both for Utah---Dave's ever loyal). As far as I can see, neither of them make this data available in a way that something other than a human can use it. I'd really like to see more of these sites following correct principals for putting data online. It would be so easy to do and cost almost nothing at the margin.

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

Digital ID and Government

Digital ID World has published an article I wrote on Digital ID and eGovernment. The conclusion of the article is that governments need to be the foundational players in digital ID, just as they are in the physical world.

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

Grid Sensors

Last week, I wrote about using the temperature sensors installed in cars in a cooperative way to monitor weather conditions in over a large area. It strikes me as I've thought about it over the week end, that there are sensors everywhere and society would be better off if they were widely available. Let me give some examples.

One obvious example is the huge number of sensors that are installed on highways all over the country. These range from traffic cameras on freeways to strain gages on bridges. There are traffic counters installed at most stoplights, many of them remotely accessible. Freeways in major metropolitan areas also have flow sensors in the freeway.

Other examples include seismographs, federal weather monitoring installations, air quality monitoring stations, and the like. Add to that the tons of data that could be made available in real time if organizations wanted to. For example, what's the water flow rate at various points around Salt Lake City right now?

So, what would we do with all this data? I've got no idea. I do know, however, that when you make interesting data available in a way that people can use it, they come up with cool ideas that benefit us all. It would be relatively inexpensive to put a web services front end on a lot of the real time data that gets collected all over the country and let people have access to it. You might want a harder ROI, but I'm not convinced one is needed. Our government is based on the idea of open access to public information. No one did an ROI on that. We're paying to collect the data, let's make it available to people.

8:44 AM | Comments () | Recommend This | Print This

January 16, 2003

OnStar as an Open Platform

OnStar is a mobile data service that GM has developed and currently deploys in many of its passenger vehicles. They also sell it to other automakers for use in their vehicles. It currently serves 2 million customers and adds another 4500 subscribers every day. GM processes 200,000 calls per month for route information, another 14,000 for roadside assistance, and 15,000 for more for remote door unlocking. Add to that the 375 stolen vehicles that are recovered using OnStar each month. This would be a great jumping off point for a piece on identity or privacy, but that's not what's interesting me.

The other day, a friend and I were driving down a cold road in Provo Canyon and looked at the thermometer installed in the car to see if we should be worried about ice on the road. I remarked that it would interesting to be able to read the temperature sensors for the cars around me, particularly those ahead of me on the road. Then it hit me: OnStar could do this today. They have the GPS devices in the cars, temperature sensors, and a mobile network that links the cars to a central data facility. What would be even better is if OnStar were an open system that would allow me to write and deploy applications that made use of their fantastic resource. Think of it as "Wi-Fi meets grid computing." Alas, such is not the case, so I'll just have to wait for Tony Scott (GM's CTO) to put this on his "to do" list.

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

Sleeping with the Enemy

An article in the December 2002 issue of Baseline magazine talks about securing your network from insiders. Its based on a rather fascinating story of a programmer named Chris Harn who worked for the world's largest betting software vendor, Autotote, and rigged the system to pay-off $3 million to one of his co-conspirators. The article gives the following advice:

• Limit Access - Set strict limits on who has access to production servers, where data is most sensitive, and enforce them.
• Create Activity Logs - Activate auditing mechanisms and review such logs randomly and religiously.
• Monitor the Network - Establish a separate authentication server that stores monitored data in a secure location that programmers cannot access.
• Hire Carefully - Do background checks on all staffers who have access to critical data.
• Regulate Hours - Deny employees access to the network during off-hours.

I'm not sure how, in reality, you do the last one. I bought a high bandwidth connection for each developer and encouraged them to use it because I found it was the cheapest way to get programmers to work more hours. Besides, I'm not sure its strictly necessary if you've got sufficient separation between development and production servers. Having a bright line between development and production servers is a great idea, not only for security, but reliability as well. My paper on tiered support gives much more detail about this.

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

January 15, 2003

BlueOxide Collaborator Registry

I wrote about BlueOxide's XML Collaborator tool yesterday. I missed part of it. The tool's core functionality is an XML registry. The XML editing tools are support structures for the registry itself.

One of the things Kevin (BlueOxide CTO) just said is that there are collaboration features built into the tool. In general, that's a good thing, but I hear more and more people talking about their tool having collaboration features (@Task was another one. I'd rather they use something like Groove's web service API to get this functionality. Of course there are a lot of tools, and integrating to all of them is difficult, but I hate to see the collaboration be liked to a tool. An enterprise needs general collaboration tools that work with multiple products, not multiple, product specific collaboration tools.

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

DLA Logistics Metadata Registry

This afternoon I'm attending a meeting of the XML registry project team. The first speaker is Jim Keppler, talking about an integrated repository for logistics metadata. The work was done for the Defense Logistics Agency. The system is a registry for DLA data elements. In addition to allowing these data element schemas to be registered, the system also supplies tools for creating and managing the metadata. Some features:

• Core data element administration
• Metadata management support
• SOAP inteface to core data element metadata
• JDBC interface to data source metadata
• Web browser interface

The motivation behind the registry is fairly simple: DLA had created lots of XML documents and schemas. They were using these internally and with external customers. As the number of XML documents and schemas grew, it became difficult to know what the current version of the document was, where it was located, etc. This system allows applications on both sides of the transaction to ensure they have the latest copy of the XML.

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

PDF and eGovernment

Adobe is presenting. So far, its been the standard "PDF is great and the government should use it" kind of sales talk, but they're starting to talk about the document server. Sounds remarkably like Cocoon, but with only a PDF output capability. He refered to this as "document and bill presentment."

Next topic is form entry. They apparently can do two things that are interesting: The first is pulling data out of the completed form. I've always thought of PDF forms as static things that people filled out by hand and sent in by snail mail. The second is archival storage. This, of course, raises the question of what represents the official record. There is a version of PDF called PDF/A that is specifically for archives. For example, the archival version doesn't contain executable javascripts.

XML is used in a variety of ways inside PDF:

• PDF's form syntax is based on XML in Acrobat 5.
• Data objects, based on XML, can be inserted into the PDF and retrieved later (using Javascript, for example).
• PDF metadata is XML based (and maybe RDF).
• Tagged content, based on XML, in Acrobat 5 provides document structure. This allows reflowing, for example.

Form features are turned on in Reader when the form is served from Adobe's Document Server. This means that form users aren't required to have a special reader, just the normal free reader they already have.

As of now, there is no way to integrate PDF into workflows nicely, but XML workflow support is, apparently, coming. It takes the form of XML on the outside of the PDF with the PDF file base64 encoded inside the XML. Adobe sells a workflow server right now. I wonder how it, plus PDF, compare to eWork (Metastorm) or Savvion.

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

Federal XML Working Group

This morning, I'm attending the monthly meeting of the federal XML working group. Unfortunately, there's no Wi-Fi (or any other net connections I can see) so this will be posted later.

First up is John Dodd talking about connecting XML with the Federal Enterprise Architecture. John is with Computer Sciences Corp. and working with the IAC (Industry Advisory Council). The focus is" cross government information sharing." Gee, where have I heard that before? Interestingly, one of the first things that John brings up is that the introduction of web services to government will cause people's roles to change and that is going to cause angst.

One of the suggestions John has is that technology working groups (like the one I'm attending) ought to spend some time each year creating a roadmap to serve as guides for others looking at deploying the technology. The second half of this suggestion is that this roadmap needs to be effectively communicated. I think NASCIO, for example, could play an important role in this area for the states. Frequently you go to a NASCIo conference and almost every state is working on the same technology vision, but the group, with its authority and trustworthiness, doesn't communicate that vision to others in state government.

John thinks the most important business case to be made for using web services is interoperability. He mentioned Governor Leavitt specifically saying he'd read some quotes from him over the weekend where he used the word "interoperability." John was surprised (and scared) to hear a Governor use the work. I'm not.

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

January 14, 2003

Open GIS Consortium

I've written about a GIS tool called Earthviewer. Jeff Harrison is giving a talk about a group called the Open GIS Consortium, or OGC. OGC is trying to do something similar, but more general and more extensible. They have markup languages for lots of things including geographic data, sensor data, mobile data collection devices, mapping data, and so on. They did a demo last month where they pulled in data from dozens of different data sources all over the world using web services for emergency response. During the project, they actually flew a plane over the area they were interested in and brought in the data live. Pretty cool.

This effort is all being used by the Geospatial One Stop initiative. This kind of capability is vital to first responders like police, fire, and EMTs. In particular, see the Geospatial One Stop Portal Initiative.

I think its interesting to compare this with Earthviewer. In my opinion, Earthviewer has one real advantage vis a vis other GIS tools: their user interface. Is a user interface a competitive advantage? In theory, I'd say "no" since its pretty easy to replicate. In the real world, however, companies do compete on the basis of their user interfaces and others seem to have a tough time getting them right.

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

XML Collaborator

Kevin Williams from Blue Oxide is giving a demo of their XML collaborator. This is a tool that views and edits XML Schemas and other XML metadata. Bascially a GUI for XML metadata. I wrote about an XML editting tool called Xopos earlier. I'm glad to see some of these tools that don't require Visual .NET Studio to work.

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

My Talk on Web Services

I spoke from 1:30 to 2:45. When I started, I wasn't sure I had enough material, but we ran out of time. A common problem. The were a lot of questions and a good discussion. The audience was clearly made up of some people who had a good grasp on the concepts and were ready to discuss as well as some who were learning. I think the talk served both groups well, based on feedback I got after the talk. Here are the slide for my talk.

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

Leveraging Collaboration and Co-Sourcing

Michael Kochanick, from CollabNet is speaking on leveraging collaboration. Some points:

• About 75% of software is written for a specific purpose and never see the light of day.
• IT flexibility and agility is the main driver for business agility in information driven businesses.
• Component-based software development hasn't worked well.
• Component-based software development is analog to supply chain integration initiatives.
• Open source is the biggest library of reusable software in the world.
• FOSS shifts flexibility and power towards the end user/developer.
• FOSS is a "rising tide" of commoditized infrastructure.
• Collaboration makes sense for non-differentiating modules. This is called "co-sourcing."
• An ability to view the source and modify it is much more important to the collaboration process that having a zero cost.
• One of the great features of FOSS development is that its based on a meritocracy where developers gain increasing prestige and hence impact on the product as they produce useful enhancements and bug fixes.

CollabNet provides software development shops with tools and techniques that increase their collaborative capabilities. Mostly they sell FOSS development ideas and techniques to commercial software shops. Michael calls it the "secret sauce." One of the case studies that Michael gave is about HP. By integrating external partners and customers into the development process they cut the number of steps for a bug fix for the printer code from five to two.

I'm not very familiar with GUMP but it seems to have similar objectives as an organization to CollabNet.

Update - I talk to Micahel after his talk and learned a little mor about CollabNet. They are a service provider that supports muti-developer, geographically dispersed projects like the ones open source is likely to engender. CollabNet, for example, provides the infrastructure for the Apache project, including the bug tracking, versioning, etc. Given that, I don't think they're like GUMP.

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

Free and Open Source Software

Terry Bollinger, from Mitre, is discussing the report that was recently released on "Use fo Free and Open Source Software (FOSS) in the U.S. Department of Defense." The report is based on a study (survey) done by Mitre in 2002 for DISA. The survey found 115 FOSS applications with 251 typical examples. Apache, PERL, and Linux, not surpirsingly were the most popular. The report is over 162 pages long (Mitre knows well what the government wants from a contractor) and represents an exhaustive look at FOSS and its use in the DOD.

The report found that security of FOSS was noted by users as a feature. Most DOD intranets wouldn't work without it, software development was clearly tied to its use, and cost is seldom the reason for choosing to use FOSS.

The report found that for security:

1. FOSS has applications that have been intensively reviewed from a security and reliability perspective.
.
2. FOSS includes much of the most advanced work and tools for analyzing networking system weakness. This reminds me of when I showed up at Utah and questioned why were spending money on intrusion tetection software while the best one, Snort, was free. They said "can we do that? I tought that was prohibited. "
3. FOSS concept of user autonomy enable rapid responses to novel types of infrastrcutre attacks. The issue is bascially that security attacks reported as bugs to a commercial company involve unreliable communication channels and the reponse by commercial companies, as they struggle to protect their IP, is done through ineffective channels.
4. FOSS provides "auto-escrow" for software, thus protecting users from the concerns that they might otherwise have with respect to a small company.

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

Federal Enterprise Architecture

I'm at Susan Turnbull's Universal Collaboration workshop. Interestingly enough, the NSF has been kind enough to provide a wireless network, so I'm connected. Right now, Bob Haycock of the federal Enterprise Architecture Program Management Office is speaking right at present.

This model describes the process or steps for creating the architecture. Notice that the technical reference model is the last thing created and the business reference model is at the top, right after performance metrics have been created (i.e create desired outcomes).

Bob is talking about the service delivery wedding cake which I think nicely captures the foundational elements that must be in place to support services to citizens. This wedding cake is a pictorial representation of the business reference model.

In the performance reference model, each business line owner is responsible for applying the performance metrics to their line of business. For example, HHS might be the business line owner for "public health." Public health is a line of business that might cross agency boundaries. Each participant in the business line would look for common business processes and use common metrics to measure outcomes.

In the line of business, for "regulation," regulatory management is governed by the business reference model, rule publications is governed by the service component reference model, and content management would be governed by the technical reference model. The idea being that most agencies do regulation, and they ought to have common models.

The data reference model is not an attempt to create a big, monolithic data model for the federal government, but rather to create standards for meta data, particularly where it relates to interoperability. The federal XML work is likely to be part of this effort (although I'm not sure it is now).

The technical reference model is not well developed at present, but will use standards such as J2EE and .NET (not even Utah was small enough to settle on one or the other---there's not chance the feds will). The goal, obviously is to build enough standards in the services and data reference models to support sharing of components in the technical reference model layer. Right now Bob is talking about multi-tiered application development as one way to drive reuse. The goal is rapid component-based assembly of applications to deliver functionality quickly as opposed to the traditional waterfall model. This is a big shift for the feds. This afternoon, I'll be saying that we can go beyond that with web services by incrementally exposing interfaces and using ALIN to separate concerns.

The feds are looking for "solutions architects." These are folks with good technical and business skills who can create specific architectures for specific applications. Solutions architects are the ying to the product manager's yang. I'm not sure how the feds handle product management. Utah has a eGovernment product management council. I think the book, Software Architecture in Practice probably describes what they're after in terms of skills.

Bob just mentioned, in response to a question, that OMB fully intends to use the federal budget process to drive transformation and change. I think that this is an important point that any Governor, new or old, needs to understand. The budget process is, by far, the most powerful tool in the belt for driving compliance with change mandates by the Governor.

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

January 13, 2003

Archie-Like Indexing for the Web

Dan Bricklin, from whom I first heard about weblogs in February of 2001, has begun a project that is similar to WSIL, but aimed at small and medium sized businesses called SMBmeta. This (and WSIL) are strikingly similar in design to ALIWEB, or Archie-Like Indexing for the Web which was designed to provide the same functionality for the web that Archie provided for anonymous FTP. This, of course was all well ahead of Google or even Excite and Yahoo!. In 2002, when Excite shut down the eCommerce services that they'd bought when they purchased iMALL (my company), there was still a module called "aliweb" running on the systems.

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

More on NOC Blogs

In response to my recent article on NOC blogs, Gordon Weakliem asked about the security aspects. In particular, it seems that there can be (and perhaps is) information that you might want a NOC blog, but not want public. In light of that and some other thoughts, a few comments:

1. A NOC blog should probably be built using a system that allows multiple authors. Manilla, Movable Type, and Slashcode would all seem to meet this requirement. It would be unusual for single person to be familiar with all aspects of the NOC. It would be more convinient for everyone to post as necessary.
2. The NOC blog should have public and private parts. Each should have its own RSS feed. The private area should be used for more sensative information like suspected hacks, network configuration posts, and the like. If possible, the system should be configured so that the public feed is a filtered view of the private feed so that people with access don't need to subscribe to both. In some cases, it might work to just keep the private area behind the firewall. In others authentication might be necessary.
3. Depending on how sophisticated the network and systems are, I think that the more categorization that the NOC personnel can do the better. For example, I might want to only receive a feed of status information for just a single system.
4. In an ideal world, all of this is driven in some way from the trouble ticket system to avoid double entry by the NOC personnel.

All in all, I think a blog and especially any associated RSS feeds is a great addition to a NOC. If you've read my paper on Tiered Support you'll see right where this can fit in. Given the organization in that paper, I think that the product operations engineers ought to be running one for each product that they manage as well.

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

eGovernment Maturity

Alan Mather writes frequently about eGovernment in general and particularly in the UK. Today he points to an article on eGovernment in the online section of the Guardian. The article also mentions Alan's blog. Alan has a pretty chart on eGovernment evolution that is analogous to the chart I use for talking about eGovernment maturity. The conclusion that I always make from the chart is that cross agency applications are the thing that governments have to start working on now to reach the next stage. This is the foundation of the message on web services that I'll be taking to the Universal Collaboration workshop tomorrow in DC (traveling today).

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

January 11, 2003

Hallelulah! A NOC Blog in Utah

Almost six months ago, I wrote about using using blogs as network status tools. Troy Jessup at UEN has done it. Its been active for three days. This is awesome! If you're interested in status of the UEN network (which connects schools and universities over the entire state) just subscribe to the RSS. I wanted ITS to do this for the state network, but they couldn't wrap their heads around the concept.

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

January 10, 2003

Virtual Networks of Demand

I was talking to another Utah start-up called The Virtua Group today. The CEO is a fellow named Duy Beck. While we were talking, he used a phrase which really got me thinking: "virtual networks of demand."

Anytime you get an organization of more than a few people, you start hiring people with particular functional specialties to perform specific tasks. Therefore, getting anything accomplished, requires that you have a workflow (formal or informal) for getting things from one person to another in the right order, at the right time, etc.

Another way to think of this is as every person representing a little bit of production capacity with their own supply chain and demand chain. All of these internal supply and demand chains represent a "virtual network of demand." The goal of an organization is to find ways to efficiently and effectively service this network and keep it flowing.

From an IT perspective, when we install CRM systems, ERP systems, employee portals, workflow systems, personal computers, office suites, and the like, we're trying to service and automate this demand network. The problem is that we can't, yet, approach it from the standpoint of viewing each employee as a custom unit that has specific needs because of their role, their style of work, the way they learn, the way that they're most comfortable communicating, etc. We more or less give everyone a standard set of tools and require them to do their own customization. We just build a machine and expect people to be cogs in it, instead of viewing them as a big distributed P2P network. I think we'll see a trend in the future toward more and more fine grained approaches to this problem.

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

January 9, 2003

Four Questions Every Start-up Ought To Answer

As I go around and visit companies, I usually ask them four questions:

1. What's your product?
2. Who's your customer?
3. Why do they buy your product?
4. What's your competitive advantage?

You'd be surprised (maybe you wouldn't) to find that there are companies who can't answer these questions. They might think they're answering them, but usually they're waving their hands a lot while their talking. I want to know the answers to these questions before I ever hear word one about the technology. Sometimes people think the first question is answered by talking about their technology--its not.

Questions 3 and 4 may seem similar, but their not. Question 3 could alternately read: "what problem are you solving for your customer?" and question 4 could alternately read: "why can't any other bozo with a wheelbarrow full of money do the same thing?" Contrary to popular belief, access to capital is not a competitive advantage.

I'm also usually pretty blunt about asking about gross revenues, burn rate, and their funding situation, but only after a substantive talk on the first four. I'm having a lot of fun. I need to find a way to get paid for it. :-)

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

Aradyme

Today I got to spend some time with another of Utah's high-tech start-ups: Aradyme. Aradyme is a database company run by a couple of folks who have been around the Utah high-tech community a while: Jim Spencer and Kirk Tanner. At first I thought that they might be doing something crazy like trying to go head to head with Oracle or Microsoft, but I should have had more faith in these guys.

According to Gartner, 75% of the database market (some $60 billion) is in the small and medium sized business area. Oracle and MS SQL Server aren't in that market. Gartner says that the market is largely served by off-the-shelf vertical apps (like specialized solutions for a doctor's office or an inventory management system). Very little custom development is done in this space due to the cost. What development there is is usually done on MS Access by users themselves. Access is the putty that fills the voids.

Aradyme believes that they can attack this market by selling customized Aradyme-based, off-the-shelf apps in specific vertical markets. Their believe is that their database engine and integrated RAD tool make this kind of customization possible where it wasn't before and thus give them an advantage against competitors. This is not just a pipe dream, they've done it for a number of clients already.

I wasn't in any position today to evaluate the technology. I'll come back another day and try to do a deep dive on the technology. What I did see, however was a good business plan and some very well thought out marketing. Even though their target market isn't the enterprise-scale database applications, I think they need to think about how they connect to them (they might have and we just didn't get to it today) because large enterprises build plenty of small and medium scale database applications. I used to get sick thinking about all the Access databases sitting on direct attached disks that the State depended on for mission critical applications.

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

January 8, 2003

Government XML

The feds have a web site that documents their efforts in XML. There's also one for federal efforts on the web services front. The site has an agenda for the meeting that I'll be speaking at.

As long as we're on the subject, Wisconsin's Office of eGovernment has created a standard for their XML and SOAP initiative. I wonder what's going to happen to that with the incoming Governor saying he plans to abolish the office. Its been under attack for some time. Rebecca Heidepriem, the CIO, resigned effective yesterday. I may soon need to link to the Google cache since I'd bet abolishing the office also means taking down the server, dispersing the employees, and sowing the fields with salt.

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

UETA and Digital Signatures

Many people have never heard of the Uniform Electronic Transactions Act, or UETA. Even so, if you engage in any kind of transaction on the Internet, even non-commercial ones like downloading open source software, it has affected you.

UETA itself is not a law, but rather a model law that the National Conference of Commissioners on Uniform State Laws developed for states to use. As of December 2002, 41 states have adopted UETA, some with changes.

So, what is UETA? A uniform statute relating to the use of electronic communications and records in contractual transactions. Here are some important definitions from the statute:

• Electronic Signature: "Means an electronic sound, symbol. or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record."
• Effect of Electronic Signature: A "signature may not be denied legal effect or enforceability solely because it is in electronic form."
  "If a law requires a signature, an electronic signature satisfies the law."
• Electronic Record: "Means a record created, generated, sent, communicated, received, or stored by electronic means."
• Effect of Electronic Record: A record "may not be denied legal effect or enforceability solely because it is in electronic form."
  "If a law requires a record to be in writing, an electronic record satisfies the law."
  "A contract may not be denied legal effect or enforceability solely because an electronic record was used in its formation."

The result is that everytime you click on an "agree" button on a web site, that act is deemed to have the same effect and be as enforcable as you signing your name at the bottom of a contract.

Most of us take our signature quite seriously. At some point in your life you probably practiced writing it so that it looked the way you wanted it to. We hold digital signatures produced by digital certificates in a similar light. Validated certificates are difficult to get and so we feel some kind of weightiness in their use. We probably don't feel the same about clicking a button on a web form or checking a box. It just doesn't seem weighty enough and yet it has the same effect. In essence UETA has moved the signature from a unique artifact to any event (in the GUI sense) in a specific context.

I think this has significant ramifications in the world of digital identity. I think most geeks have always assumed (or at least hoped) that digital signatures would be somehow tied to some safe, secure repository of properties forming a digital identity. This law says that such is not the case.

This is a perfect example, I think, of state legislatures not waiting around for us to get the technology right or for some grand solution. They're going to go ahead and make laws affecting identity and we will be forced to follow along. If we want something different to happen, we need to do a better job of lobbying the 4800 or so people who make these decisions. Its not an easy task, but the alternative is not pleasant.

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

Product Management Council

Dave has laid out his goals for Utah's product management council, the organization that is responsible for the business side of eGovernment. I'm excited to see that Dave isn't sitting around waiting for something to happen. Rather he's driving the change. I know there are some that are waiting to see what the new CIO will do; I think Val is more likely to be impressed by someone doing something than someone waiting for instructions. I like, in particular, that many of Dave's goals are quantifiable (e.g. create 75 new eGovernment services). Alas, he doesn't have the authority to tie rewards to people's performance.

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

Public Service Tip No. 3: Remember that You're Expendable

This is part three in an ongoing series of tips for those entering public service.

Sometime after my resignation I was talking to someone who had considerable experience working with government at various levels. Before I'd said much at all about the circumstances that led to my resignation, he looked at me and said "Usually its the Chief of Staff." I asked what he was talking about and he replied that usually when the Governor needs to take an unpopular stand that he can't afford to take the heat on, the chief of staff takes the fall. The chief of staff is expendable, but the Governor is not.

I think this is good advice for anyone from the private sector contemplating public service. If you're on the Governor's staff there may be times when you're called on to take the heat for something and you need to understand that doing so is part of the job. A Governor's office is usually juggling hundreds of competing issues and priorities at any given time. The Governor usually doesn't have the luxury of ignoring any of them. Managing these issues, making good and proper decisions, and then finding a strategy to bring them about almost always involves tradeoffs and compromises. At times, you may have to fall on your sword to make these tradeoffs happen and that's part of the job as well.

One of the most important lessons to be learned by anyone contemplating a stint in public service is that everything is political. Coming from an academic background, I was not unfamiliar with petty politics; someone once said, politics is worst where it matters least and that certainly applies to university politics. Public service, however, is a whole new ballgame.

You may fall on your sword for something that has nothing to do with your program or priorities; this is call "collateral damage." Collateral damage often occurs when two politicians or groups of politicians start to battle for public opinion in the press. In this situation, you can easily find yourself caught in the political crossfire and used by one side or the other as a pawn or hostage in the battle.

In Utah, for example, the Legislature and the Governor have been having a year long battle over the budget, water, education, and just about everything else. Governor Leavitt, wisely, has refused to tell anyone whether or not he'll run for a fourth term in 2004. There are more than a few legislators who would like to be Governor and don't feel like waiting until 2008. Since they're all Repulicans, if the Governor runs again they're going to have to challenge a very popular incumbent (71% approval rating) in the primary. They figure they've got two years to soften him up and weaken his approval rating. Consequently, they challenge him at every turn and on almost any issue. Leavitt is smart and skillfully weilds the advantage of the Governor's office, however, and thus usually ends up riding in on a white horse, leaving the Legislature to a hobsons choice that frequently involves cutting a popular program or raising taxes.

As a result of this game of one upmanship, the Utah Legislature has started to poke the Governor in the eye anywhere else they can---regardless of the consequences. One of Leavitt's judicial nominee's was recently mauled by the Senate over nothing more than the fact that they were feeling frisky and wanted to show the Governor they were boss. In ten years, they've never done anything but pro forma approve judicial nominees. I've heard what happened this time described as "obscene" by some pretty seasoned politicos. This man, who has wanted to be a judge all his life, now will never be. Collateral damage.

I have no doubt that the currect "uproar" in the legislature over hiring in IT and the audits that resulted from it were part of this game. The legislature has no IT agenda and they really didn't care to understand what was going on (I tried to talk to them on dozens of occasions). Understanding the facts would have only made the job of taking jabs at the Governor more difficult. They had an agenda that had nothing to do with IT or hiring and they carried out. I was a convenient target. Collateral damage.

As CIO, I understood fully that I was expendable. This isn't a lesson I had to learn. I always considered myself part of the Governor's staff and was happy to serve him in whatever way I could. I believe that Mike Leavitt is perhaps the most capable public executive in the US today, at any level. I was and still am very loyal to the man and if my actions helped advance his program, in or out of IT, then I'm satisfied I did what was required of me and I happy to have done it.

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

I Want Tabs

I downloaded Safari, Apple's new borwser last night. Its fast and well integrated. I think its kind of gutsy for Apple to launch a browser, but MS has one and I think there's a good case to be made that tight integration with the OS is a nice feature for a browser (even though I'm a Mozilla user). I used it for a while and it seemed to work fine, even though its beta. I have just one complaint that, for now, is a show stopper.

I want tabs. If you're a an IE user, you don't know what I'm talking about. Mozilla (and Netscape, I presume) allows you to open new URLs as tabs inside a single frame. This is a great way to manage desktop clutter. I frequently get 10-15 windows of various sorts open and tabs help me keep my workspace tidy.

I like tabs so much, that I started using a teminal application called iTerm because it supports tabs. When I'm writing code, I usually want three or four terminal windows open to different directories and iTerm lets me tab them inside a single frame. Nice.

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

A Must Have for OS X

The first thing anyone who is a heavy Emacs user does when they get a new computer is figure out how to map CapsLock to Control. The alternative is severe pain in the hand from constantly having your pinky bent under your palm trying to reach the Control key. Just thinking about C-q makes my hand hurt. I'd hadn't been able to find an acceptable mapper for OS X until today.

I found out about a little tool called uControl this morning and loaded it up. The installation is easy and the integration with the OS X preference system is seamless. It just shows up in the System Preferences and works. Make sure you remember to "Add" your mapping after clicking the check boxes to create it. I couldn't get it to work for a minute and that was the problem. The little CapsLock light still toggles, but I fired up Emacs and the mapping worked like a charm. I tried it with an external USB keyboard as well as the bult-in keyboard and it worked just fine.

This is another example of OS X being a Unix that just about anyone could use. If you've done keymapping in X, you know what a joy it can be--I have to dig into the manual page every time and relearn it. This morning's exercise couldn't have been simpler.

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

January 7, 2003

Learning to Love EJBs

Marc Fleury, the founder of jBOSS is writing a "technology trilogy" called "Red, White, and Blue" (maybe they're going to get rid of the green and yellow on their web site). The first paper, entitled Blue: Why I Love EJBs is available. Its a little difficult to read in spots but worth the effort.

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

January 6, 2003

Another Entry in the Utah Blogroll

Jim Stewart, who is the technical service director (meaning he builds and operates the network) at UEN, has started a weblog. If he and Peter haven't bought their licenses yet, I know the CIO's office still has a few.

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

Fatpot: A Silly Name for a Good Tool

I had a meeting with a company named Fatpot today. Their forte is connecting disparate systems and they've concentrated in the area of public safety. The system they've built is called "Public Safety Inquiry" or PSI and it serves as a front end for UCJIS (the Utah Criminal Justice Information System), NCIC (the National Criminal Information Center) and things as mundane as the Yellow Pages. Its a great little client that runs on a laptop in the crusier. The user interface design is very well done and much more mature than I'd have expected from such a young company.

The problem that they're solving is this: first responders from different agencies often can't talk to each other. Even more concerning is that since each agency uses different computer assisted dispatching (CAD) devices, they can't tell what other first reponders are at the scene or enroute. With Fatpot's solution, not only do police and other first reponders get a single place to make inquiries against criminal justice databases, but they also get interagency text chat capabilites (based on a single user directory) and interoperability for CAD. This is a big deal, because its now possible to create a single , geographic display that shows the location of every first reponder (including fire and EMTs) in that region and coordinate and dispatch them in the event of an emergency. Many of Utah's police agencies already use Fatpot, so the State is well on the way to this dream being a reality.

Interestingly, they didn't use web services, although web services would be an excellent solution for this problem. They wanted to get the job done and so they just connected at the socket level and they custom parse messages into and out of the various systems. This is quick and dirty, but I worry that it doesn't force the interface to go public and doesn't drive interoperability for the next app. Consequently, the next application is just as difficult to write, unless you let Fatpot do it (I'm sure they'd be happy to). :-) Nevertheless, they've solved an important problem and enabled some very cool applications.

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

New Utah CIO Named

The Governor's Office issued a press release today announcing the new CIO. There's also a story in the Deseret News. The choice is Val Oveson.

I've known that Val was going to get the nod for some time. Val's not as technical as some of the possible contenders, but he brings with him a wealth of government service, as you can tell from reading the press release. The Governor has told me several times that he's not after a course correction, but someone to push the existing program forward and follow-up on my recommendations. Given that, I think Val is a great choice because he knows well how to navigate the dark maze of government. He'll have a great chance at implementing the plan and making it work. One of the biggest agenda items in the next few months is legislative changes to the CIO statute.

I have known Val for over a year and he's been involved in a few projects, including credit card and electronic payment issues. He's been very helpful and easy to work with. I had a long meeting with him last week and plan to meet with him again in the future as he gets up to speed. I'm anxious that he succeed because I think the Governor's vision of breaking down silos is the right one for eGovernment and homeland security.

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

Universal Access Collaboration Expedition

Susan Turnbull, of the GSA has invited me to speak at the Universal Access Collaboration Expedition workshop #21 on January 14th in Washington DC. I've been trying to make it out to one of Susan's workshops for some time now. I'll be speaking on web services in eGovernment. I'll probably post a few ideas for my talk here later in the week.

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

Wireless Workplace Wisdom

Matt (BlackBelt) Jones asked me and some others some questions about ROI for wireless in the workplace. I sent him a direct reply, but thought I'd make the answer public here.

I'm afraid that I don't have any hard ROI numbers, but maybe some of my own analysis will be worthwhile. I offer it to you for what its worth:

1. I don't see wireless as a replacement for wired networks in most instances, at least in the US. Many buildings are fairly new and either already wired or easily wired after the fact. When I moved into a building a few years ago, I was able to put in wires for about $200/drop which included 2 Cat-5s and a phone. As a one-time build out expense, its too cheap NOT to do. Until I'm running phones wirelessly too, I've got to drop lines anyway.
2. I think wireless becomes compelling when one considers places like campuses or even conference rooms. There, wireless is the only logical solution. My plan at Utah was to build out conference rooms, cafeterias and the like and let user demand drive it into other parts of the building. Maybe that will still happen.
3. Wireless is even more compelling in any environment where most workers move around or where laptops have become the standard option. If it were up to me, I'd issue every employee a laptop (instead of a desktop) just to see what happens. I think its changes how people work. When a company is mostly buying desktops, however, its hard to justify wireless vs wired on a cost basis (at least for fairly new buildings).
4. I think the only reasonable security solution at present is to put wireless hubs on unrouted 10. or 192. nets and force everyone on the wireless net to authenticate using a VPN. This has two big advantages: (1) its pretty secure and (2) we already rely on VPNs to secure us in lots of cases, so its massing our security efforts. The fewer total security solutions an organization has to deploy, the better it can make them. I think including security in the wireless standard was a big mistake. Security ought to be a layer on top of the carrier and it ought to be flexible.
5. A large organization is foolish to not get out ahead of its users on something like wireless: (a) lots of people want it; (b) its cheap---cheap enough to put on a corporate AMEX; and (c) its a security nightmare. This is a recipe for disaster. The only way to fight it is to install wireless networks correctly ahead of user demand. If you don't, they'll all go out to Best Buy and be plugging them into the corporate network without any security turned on at all. Ouch!

I've always believed that wireless is a companion to and not a replacement for wires in a fixed environment. Maybe I'll be proven wrong. That said, I think that I'd be inclined to provide wireless access everywhere I could because I think it changes interactions. It allows me to take my laptop to my colleague's offices and sit with them and collaborate easily. I'm much more likely to do it if I don't have to jack in and out all the time. Its difficult to put an ROI figure on that, but it can't be discounted. Good organizations pay attention to fostering interaction.

Does anyone know of ROI studies on wireless in the workplace?

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

January 4, 2003

Wi-Fi on Campus II

Pete Kruckenberg sent me a reference to a Wired story on Wi-Fi on campus after reading my recent article. Pete says "Just like any other technology, Wi-Fi requires that the classroom dynamics and methods be changed to incorporate and use it. " One of the points that the article makes, and with which I agree wholeheartedly, is that there's no telling what will happen on campus when you give everyone access to ubiquitous wireless networking. College students are incredibly innovative and, contrary to what they commonly believe, have a lot of time on their hands to play around with the technology. Just one small example: last week when I was at the BYU CS department, there was a robot running around the third floor. It was using the building Wi-Fi for access, not some special connection. Its just part of the infrastructure that researchers count on now.

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

January 3, 2003

\@Task

I had a meeting with a company called \@Task today. Nate Bowler, who was one of our many stars at iMALL, is their CTO. \@Task provides thin-client project management and workflow software to customers like Novell and other large companies that you've heard of (since they don't mention them on their website, I won't mention them here).

\@Task combines workflow, collaboration, and project management to actually drive the project or process from the tool rather than using it as simply a static document that records progress. Because it assigns tasks to group members based on the workflow and tracks completion, a manager can see at a glance where the project is, who's got unfinished deliverables, and so can everyone else. Consequently, the tool functions as a dashboard and uses tranparency to enforce good behavior. They're using SOAP to interface with traditional CRM and ERP systems like PeopleSoft so that hours, for example, can be entered into the accounting system from the project tracking tool automatically.

All in all, I think it sounds like a great improvement over other project tools I've seen. One of the things I was thinking is that it would be a great tool to build a lot of software development processes. Most of these are enforced by culture and training with little tool support to help foster the correct process.

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

Wi-Fi in the Classroom

The New York Times has an article today about the increasing use of Wi-Fi in the classroom. BYU has deployed Wi-Fi in many areas, but it wasn't available in the classroom I was in last semester. The article quotes a few professors who are miffed that students are off surfing the web instead of paying attention. I'm not very concerned about that. My philosophy about class has always been that students can come get something out of it if they want or not---their choice. It would be interesting to run EtherPEG in class though and capture some of the traffic to display at the end of class. Do that a few times and people would probably be more careful in their surfing.

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

January 2, 2003

Outsourcing to the Small and Medium Business Market

Today I met with two very different companies that are alike in one important way: they provide outsourced services to small and medium sized business. I've always had a soft spot in my heart for small businesses---my Dad owned a small grocery store when I was growing up and I spent my formative years working there doing everything from pulling weeds to running the cash register. Consequently, I always enjoy seeing services aimed at making business better for the small business.

The first is a company called Nexpedite. Nexpedite provides "after click" services for eCommerce. That is, the provide warehousing and shipping services. What makes them stand out is their use of IT to provide differentiated services. A customer can place their goods in the Nexpedite warehouse and send order electronically, follow the shipping process, process returns, and track inventory. They do this via thin client web apps, downloads to Quickbooks, or even plain old Excel spreadsheets. Its another important piece of the B2B or B2C service line. They're cash flow positive right now, but small and having a tough time growing. What they need most is a way to do some marketing, beef up the technology infrastructure that sets them apart, and build out.

The second company I visited today is called DirectPointe. DirectPointe is smack dab in the middle of a market I've thought for a year or more has some real potential: IT services management for small and medium sized businesses. If you've read my Modular IT Organization paper, you'll know that I think IT organizations perform three core functions: value innovation, application development, and basic IT utility services. DirectPointe is aimed squarely at the last function. They provide fully managed file, print, and messaging services to organizations that have between 10 and 150 PCs. From all accounts they do an excellent job of providing reliable service for less than the organization was doing it themselves. I think they've got a pretty neat business model, especially the financial services aspect. They're another company operating in the black in tough times. They're also part of the Lindon Utah high tech community.

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

EX-IT?

A recent article on eWeek talk about IT workers who, when faced with a career change, got out of IT and into something else. I can't see it. I still get excited when I think of building something new or start tinkering with SOAP or whatever. When I taught at BYU, there were 700 undergraduate CS majors (still are). I talked to many of them who hated to program and were in CS because it was a good way to get a job. I used to advise them to go into sales. :-) I guess those types are probably wondering whether to tough it out or not. I think hard core techies will always be looking for the thrill you get from building the next, new thing. I'm proud to count myself among that group.

12:55 PM | Comments () | Recommend This | Print This