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