« January 13, 2003 | Main | January 15, 2003 »
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.
05:01 PM | 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.
04:35 PM | 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.
04:17 PM | 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 | 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:
- FOSS has applications that have been intensively reviewed from a security and reliability perspective. .
- 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. "
- 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.
- 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 | 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.