Someones Got to Take Charge

It sure would be easier to keep corporate information assets secure if people didnt actually try to use them. Thats an ancient paradox, of course, but lately its taken on another dimension: It sure would be easier to keep a service-oriented architecture coherent if developers didnt keep creating and composing new services into innovative applications. Same game, just different pieces moving around the board.

Clumsy handling of enterprise data—and, in particular, invisible but crucial metadata—can prove costly, as pharmaceutical maker Merck & Co. will be forcibly reminded in the lawsuit whose retrial gets under way this week. The companys defense of the safety of its arthritis medication, Vioxx, was seriously compromised when document editing tags revealed that a table of data on heart-related complications had been deleted two days before a journal article was submitted to The New England Journal of Medicine.

Similarly, embedded document metadata led to unintended disclosure, late last year, of the process of developing White House statements concerning the war in Iraq—perhaps inspiring National Security Agency guidance on document redaction at the end of last month. Fine with me, I didnt really want to repeat the same Stupid Tech Trick topic in our year-end issue next December.

Im neither praising nor condemning either Merck or the White House for the positions they take or for the manner in which they support their positions: Im merely holding them up as cautionary examples that your own data, carelessly handled, can undercut your own efforts at crafting a competitive strategy—and Ive previously noted that client-level tools are available to assist individual users in noting and (one hopes) addressing the inclusion of metadata that shouldnt remain in documents as they head out to make their way in the world.

Workshares Trace, updated to Version 2 last June, makes it hard not to notice that your document is bearing unintended baggage. The company expands on its metadata protection offerings with this weeks announcement of its Workshare Protect Enterprise Suite, adding key components for network-level scrutiny and automated policy-based protection—because systems without automation are science projects, not enterprise solutions.

Meanwhile, developers face similar issues of channeling their creative energy in cooperative directions as they package a growing fraction of their work as services rather than as monolithic applications. The disclosed interfaces and exposed network links of services make it almost a mathematical certainty that services will create new security issues, although not necessarily a net increase in vulnerabilities. But there are people whove been drinking the services Kool-Aid for a while now without getting poisoned by the stuff, like Bob Prevenslik, director of Enabling Services at travel giant Sabre: "We see Web services as a key enabler; modifying applications allows us to shuffle content without changing interface," he told me in a conversation late last week.

"Were supporting up to five versions of a service right now," Prevenslik added, "with the same service able to go to a mainframe or to another platform." He had previously been using repository technology from Flashline to manage internal development efforts: Sabre staff worked with Flashline to extend that outward as a foundation for externally facing services, "and it worked," he told me, adding, "Flashline hadnt thought about doing it either, but they now promote that as a capability of their latest version. Its pretty cool."

What happens if services dont get a comprehensive management environment, one that puts them into the larger context of the enterprise application portfolio? You get "just another silo," said Flashline CEO Charles Stack during a conversation that we had last week, adding, "Companies wont be successful unless the SOA is tied to the enterprise architecture and the core business processes." The company offers further thoughts on the A of SOA in its white paper, Webcast and other forms.

The big picture here is that developers are becoming users of services, and users are becoming developers of content: Both need convenience to achieve productivity, both crave access to information assets, and both can do as much harm as good if given everything they want without the additional support of infrastructure that they may not realize they need.

Tell me about the infrastructure that youre building, or that you wish you could buy, at peter_coffee@ziffdavis.com.

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.