Time traces

Open Health Tools, the open source project launched this spring by Eclipse founder Skip McGaughey, has gotten its first big code donation.

It’s called Open HIE, or Open Health Information Exchange. It consists of modules to link a master record to personal information, and to retrieve records from known locations.

The donor is the California Healthcare Foundation, and the donation was midwifed by two important open source companies, CollabNet and Palamida.

CollabNet provided its development platform to the project, and Palamida has already done a code review on the donated code base.

The software itself is descended from code used to create the failed Santa Barbara County Care Data Exchange in 2006. The idea of Regional Health Information Organizations (RHIOs) has since spread nationwide.

Ostensibly, the first computer “bug” was a moth that got trapped in a relay inside of Harvard’s Mark II computer in 1945. It took technicians five and a half hours to track down the source of the problem. Assuming that a university computer technician may have been making $1.50 an hour at that time, it can be assumed that the bug cost about $8.00 to fix.

Things are a little more costly these days, of course, and IDC appears to be saying that SOA is really adding to the cost of fixing software bugs.

According to a “forthcoming” report from IDC, cited in SC Magazine, a typical organization now spends between $5 and $22 million a year fixing software defects. IDC bases it’s estimate on a recent survey of 139 organizations.

SOA gets a share of the blame for the escalating costs. The report cites “increased software complexity from multicore, Web 2.0 and SOA” that not only make bugs more prevalent, but also more complicated to fix. As IDC put it: “The increased complexity of software development environments and the cost of fixing defects in the field (rather than early in the software cycle) combine in exorbitant ways to drain income and to hamstring businesses as a result of critical software downtime.”

Hmmm. The purpose of SOA — and Web 2.0 for that matter — is to simplify things. Theoretically, it means containing problems more to interfaces, versus having to go into the guts of enterprise systems to rewrite or upgrade code. A bug should in theory only have to be fixed once by the entity managing the target system; versus fixing it 100 times in 100 different instances across the enterprise. At least in theory.

Of course, with multiple islands of SOA and Web services, there is additional complexity arising. Just keep the moths away.

I recently had the honor of emceeing the launch of a new book called An Implementor’s Guide to SOA: Getting It Right. (The Webcast can be accessed here at the Composite Software site.)

The beauty of the book is that it’s a quick read, and drills right down to the essentials of getting moving with SOA. As author and editor Jim Green, CEO of Composite Software, explained, he purposely kept the length of the book to about 100 pages. “We wanted to write something that could be absorbed over the course of a coast-to-coast airplane ride,” he said.

That wasn’t an easy task, since he was also incorporating chapters from six other well-known SOA experts– including Paul Butterworth, Luc Clement, Hemant Ramachandra, Jeff Schneider, Hub Vandervoort, and David Besemer.

The theme of the book?  I can boil it down to three words (to quote Nike): “Just Do It.” It doesn’t matter what kind of SOA budget you have, or even if you have a budget at all — there are still practical steps you can take today to get started.

In fact, one of the most powerful messages coming out of the book is that SOA is not a luxury reserved for the corporations with the deepest pockets. SOA is something everyone can take advantage of and benefit from. You don’t need to get caught up in trying to boil the ocean. Transformation starts with small steps, and SOA success will happen in increments.

Service-orienting large-scale systems cannot be fully thought through in the early stages, Jim Green said. One of SOA’s greatest failures is that it often is subjected to paralysis by analysis. “The longer that you ponder the imponderables as you plan, the lower the probability of your success.”

Some snippets of the key recommendations coming out of the book:

• Getting Started: “Don’t let anyone overwhelm you by trying to reach you everything at once.”
• Designing Services: “Base your services on vendor independent industry standards to ensure the best reuse and interoperability.”
• Registries and Repositories: “Recognize the importance of documenting and maintaining a formal system of record of your services, their revisions, and their service level agreements.”
• Enterprise Service Buses: “Analyze your interoperability issues and determine whether you will need an ESB to reconcile incompatibilities.”
• Runtime Management: “Understand and control your service network — detect, diagnose, and ultimately prevent problems that arise during the operation of the service network.”
• Preparing the Organization: “Set up and empower centralized groups to enforce governance and evolve them as needed.”
• Assessing SOA Skills: “Develop a training roadmap that integrates with your SOA strategy.”

This just in from the Black Hat security confab currently taking place in Las Vegas: Dan Kaminsky, a well-known IT security researcher, disclosed his findings around the Domain Name Server flaw, (or DNS cache poisoning vulnerability), and where it can bite. Tim Wilson of Dark Reading reported on Kaminsky’s presentation, who said the flaw enables attackers “to exploit the DNS design to quickly guess the transaction ID of an address query and potentially re-route the user to an unexpected domain.”

(For more details, ZDNet colleague Ryan Nariane provides an interesting behind-the-scenes look at the politics and posturing that took place behind the vulnerability, and ensuing July 8th patch release to help mitigate the threat.)

As Kaminsky put it, there are apparently implications for companies SOA-enabling their applications. As relayed by Tim Wilson, Kaminsky said the problem extends far and wide across the enterprise:

“While most early discussions focused on Web surfing and the potential hijacking of users’ browser sessions, Kaminsky today pointed out that DNS address queries are embedded in a wide variety of applications and services that had not entered the conversation previously.

“The Internet is more than just the Web,” Kaminsky said. “HTTP is used in more than just the browser.”

Most email systems, for example, contain DNS lookup capabilities and even their own name servers, Kaminsky observed. “Email servers are awesome at doing DNS lookups,” he said. “They will do a DNS lookup for any reason at all. And your spam filter will not stop this problem.”

Many enterprises also believe that their internal DNS environments will not be vulnerable, Kaminsky observed. But many internal environments also work with external DNS servers, and even if they didn’t, most internal environments are also connected to DNS servers used by customers or suppliers, he noted.

The DNS flaw can affect any system that uses the Internet, including older applications such as FTP that are still widely used, Kaminsky noted. Back-end IT systems such as Telnet, SNMP, authentication servers (such as Radius), backup and restoral systems, and even service-oriented architecture (SOA) environments all use DNS, and could be subject to attack via the newly discovered flaw.”

Interesting stuff, and a reminder that SOA means security needs to be a holistic enterprise commitment. Especially since organizations will be relying more on services that not only come from other parts of the organization, but from outside the firewall, too. Be sure to practice “Safe SOA…”