May 2008 Archives

North Plains' announcement earlier this month that they their DAM solution, TeleScope, is now being offered as a service in the cloud.  Some market analysts are saying that running DAM in the cloud isn't for everyone (yet?), but I've heard that 10% of the market is ready now (10% * 1/2B= 50M).  North Plains isn't alone is providing DAM SaaS.  Widen is doing it too (as their VP of marketing describes in this video).  To relieve concerns about uploading assets to the cloud, they have created an appliance that runs within a customer's facility, allowing their assets to remain local, but is maintained by Widen remotely.  Besides these two DAM vendors, ClearStory just announced that they are getting into the SaaS market too with ActiveMedia

Cloud computing is quickly coming to the forefront even in a market that is full of paranoid companies, requires specialized hardware, and is characterized by extremely large media files. It's only a matter of time!

I found a company called CMS Watch the other day that offers a number of intriguing comparative analyst reports on DAM systems, Enterprise Content Management (ECM) suites, Web Content Management (WCM) products, and Enterprise Search. They also have an interesting blog that I would recommend subscribing to called CMS Watch. In one entry in this blog, the author, Joseph Bachana, discusses innovations in the digital asset management marketplace that he expects to see this year and next. I've summarized his predictions here:

  • Many DAM vendors will devote their development efforts to OEMing third-party products into their applications.
  • More and more vendors will expose Web services APIs in response to a market that is hungry to integrate DAM systems into other systems (e.g., Web Content Management systems, Customer Relationship Management systems, Workflow Management Systems, Resource Management Systems, etc.).
  • DAM offerings will increasingly adopt Adobe's XMP format which will allow customers to transfer an asset's metadata with its content as it's passed around different (possibly external) systems.
  • More DAM providers will be integrating with Adobe's Version Cue which will allow their creative customers to take part in workflows, collaborate with their peers, version their work, and check in/out content.
  • Many companies will be working to integrate their DAM system with SharePoint for its content management capabilities, workflow engine functionality, and to further integrate into the customer's back office IT infrastructure.
  • DAM vendors will invest in building Rich Internet Applications (RIAs) using Adobe Air, Adobe Flex, and Microsoft Silverlight, so that they can provide UIs for their systems that are accessible from various operating systems and connected via the Web.
  • DAM repositories will be viewed more and more as the single, authoritative source for all intellectual property. For this reason, DAM providers will be expected to be increasingly open and interoperable, so that the content they stored is accessible to other systems that don't hold the authoritative copy of the media.
  • Digital Asset Management providers will partner with or purchase suppliers of XML databases and text mining engines to facilitate the creation of these authoritative repositories that can store creative and textual content.

Will we ever see an open source DAM system that can go head to head with EMC, IBM, Oracle and the rest? Tony Byrne says in his blog that he thinks it will not happen soon if ever. Joseph Bachana disagrees and says that it "may take the harnessed fervor of the open source community to bring all these threads and more together in the marketplace." I think the CEO of MarkLogic would agree with Bachana. In his blog, Dave Kellogg conjectures that, in the future, the "high-end of the [Enterprise Content Management (ECM)] market will split between Documentum and Alfresco," an open source ECM system. Though it is an ECM and not a DAM solution, if Kellogg is correct that about half of the big ECM customers will use Alfresco, many will also require it to support some DAM-related features as their needs won't stop at information processing.  Many will also need a secure repository that facilitates the management and distribution of media files, thus crossing over into the realm of the digital asset management systems.  As a result, this OSS project may be augmented to include DAM-like capabilities proving Bachana right and giving us a free (as in beer) DAM alternative.

Ronald Schmelzer posted a fantastic article on ZapThink about the relevance of SOA to Independent Software Vendors (ISVs). In it he says that the reasons that ISVs should build their application in a service-oriented fashion are the same as for large enterprises instigating company-wide service-oriented initiatives. Specifically, he states that ISVs should design their applications using service-oriented practices, so that their customers can:

  • Reduce their integration expenses,
  • Achieve a faster time-to-market,
  • Lower their total cost of ownership (by reducing the need to hire system integrators and/or consultants), and
  • Increase business agility.

Some of these benefits are also experienced by the ISV themselves when they use this architectural paradigm. For instance, by reducing coupling within an application, an ISV can more easily alter its product to meet changing customer demands. Schmelzer warns that it isn't enough to slap some Web services around a monolithic application and plaster "SOA" all over the press release, however. I appreciated this admonishment because of the common misconception in our industry that Web services and SOA are the same thing.

Having read this article, however, I'm left wondering what aspects of an SOA should an ISV's offerings include? There are many facets to an SOA. Which ones should be included with a service-oriented product? Of course the answer is that it depends and that there isn't any hard and fast answer; however, it is helpful to enumerate the common characteristics on an SOA and think about:

  • Which traits are pertinent to service-oriented products built by ISVs,
  • Which qualities could be included, and
  • Which ones should be left solely to the end customer?

To aid in this discussion, I'll use Thomson Erl's fantastic book Service-Oriented Architecture, Concepts Technology, and Design as a reference for what characteristics SOAs commonly have. The following table shows the characteristics sited in Erl's book and which ones must, may, and must not be exhibited by service-oriented products sold by ISVs.

Common Characteristics of an SOA

Must

May

Must Not

Based on Web services

X

QoS-capable

X

Autonomous

X

Open

X

Vendor-neutral

X

Discoverable

X

Interoperable

X

Federated

X

Composible

X

Reusable

X

Extensible

X

Encapsulate business logic

X

Abstract

X

Cohesive

X

Promotes organizational agility

X

Elemental

X

Evolvable

X


Some of these terms may be unclear and others deserve special note, so I'll elaborate. For a more thorough explanation, please refer to Erl's book.

Based on Web Services

Any product that an ISV creates cannot be integrated into an end customer's larger SOA directly unless it is built using Web services. This implementation technology will allow an ISV's product to be incorporated and controlled by outside forces within the end customer's service-oriented enterprise (SOE). This will lower their TCO as mentioned above, thus winning ISVs deals that their competitors will lose due to higher integration costs.

QoS-capable

In order for the offerings of ISVs to be incorporated successfully into a larger service-oriented solution, they must insure that:

  • Tasks are carried out in a secure manner, information is exchanged and stored in a protected form, and service access is limited to authenticated and authorized callers;
  • Operations are executed in a consistent fashion, messages are delivered reliably, and reports of failures are guaranteed; and
  • Operations are transactional and can be rolled back in case of errors.

Open, Vendor-neutral, and Interoperable

Services within an SOA should be compatible with open specifications that are governed by international standards bodies; however, this requirement isn't always necessary, pragmatic, or performant. In my opinion, the level of openness required of a service is directly related to its proximity to others that are built on a different platform. A service that is used in a homogenous environment, need not concern itself (as much) with interoperability. In such scenarios, services can use proprietary extensions and other optimization. If the services sold by an ISV will not be exposed by their customers but will be used as building blocks in their larger SOA, they may use non-standard protocols where it makes a difference in terms of performance, reliability, and security. Similarly, an ISV's system need not be vendor-neutral if the target market accepts the bias. When purchasing a vendor-specific, service-oriented product from an ISV, the end customer should encapsulate the proprietary aspects of the underlying services. By doing so, the final SOA will be vendor-agnostic. If a customer doesn't do this, their service-oriented initiative will likely degrade into a "wild west SOA frontier". To avoid this, companies that purchase service-oriented systems from ISVs should police them with SOA governance products like those from SOA Software and AmberPoint.

Discoverable

This characteristic is an important one that most ISV-produced offerings probably don't exhibit. To be discoverable, a service must publish its endpoint in a way that allows service consumers to find them dynamically at runtime without human intervention. This publication process is typically done in an SOA by pushing information into a central registry using UDDI. When discovering services that have been published into a UDDI registry, consumers must specify search terms that describe the capabilities or characteristics of the services that can fulfill their task. These descriptive terms are associated with services when they are published into the UDDI registry. Obviously, the terms/metadata must be shared by services published to the UDDI registry and customers needing their functionality. What this means is that:

  1. ISVs will have to create their own metadata taxonomies to describe their services or
  2. Use existing taxonomies (e.g., Dublin core).

If an ISV doesn't use a standard nomenclature or go through the trouble of creating one, their customers won't be able find and dynamically bind to their services at runtime. The creation of these taxonomies is a costly and time consuming task that is difficult to do in a way that will fit the ISV's eventual customer's needs. If this difficulty, however, prevents such a classification from being created, integration will be inhibited, decreasing the value of the ISV's product.

Federated

Erl says that an SOA should promote federation by unifying environments that were previously disconnected due to the architectural limitations of those systems. This characteristic is not one that ISVs should try to provide (on a sweeping, enterprise-wide scale at least). You can't buy SOA in a box as Schmelzer points out in the blog entry sited above. That said, by being service-oriented, an ISV's offering will be more easily federated into the consumer's SOA, which is the entire point.

Composible

The services that make up an ISV's product should be composible. If an ISV wants to provide their customers with increased business agility, they will need to compose the ISV's services together in ways unoriginally expected. This can be inhibited by a lack of interoperability, nonconformance to standards, and vendor-bias. If composition is precluded by these qualities, then the service implementation should be reevaluated or else an ISV's offering will be overlooked for others that are composible.

Encapsulates Business Logic

Service-oriented systems built by ISVs should be autonomous. This means that the services that comprise them should all be independently versioned, deployed, operated, and secured. This tenet of SOA insures that the end result is agile and able to move with changing business demands.

MarkLogic will be conducting a Webinar this week on May 13th about using their native XML database to manage information in an increasingly markup-laden world. To attend the lecture, surf over to their Web site.