Adobe Spins Up LiveCycle ES
The financial and government sectors drove plenty of the work performed in preparing LiveCycle ES for its debut in the enterprise market. The ES stands for Enterprise Suite, and until today the ColdFusion product was the only enterprise app available from Adobe. This release of LiveCycle ES will be significant for the company, as only a handful of firms will really compete with the product.
After talking with Adobe’s Brian Wick and Marc Eamon about LiveCycle ES, I’ve found it difficult to think of the product as just automation for processes, which is its essential function. I worked with EDI for a company over a decade ago, when the federal government was threatening its vendors to go paperless and switch to EDI or lose its business.
As anyone who has done business with the government knows, paper hasn’t gone anywhere in the past ten years. Had they been doing then what Adobe is doing now with LiveCycle ES, I think there would be a lot less paper in the federal RFP/RFQ processes now.
Adobe’s first task with LiveCycle ES involved taking what had been a multi-product line requiring multiple servers, and turning it into a single disc installation. From there, an enterprise can license the services it needs, provided on LiveCycle’s service-oriented architecture.
Then they had to make it more useful for the people who would interface with it the most: the users. Doing this required updates to the way developers build applications. Adobe built in features like its Form Guides for assembling interactive documents, and their LiveCycle Workbench is an Eclipse-based IDE, which customers demanded.
Once constructed, an application can make its output available electronically with persistent rights management in place. This security feature allows the output creator to restrict access to a document like a completed insurance form to the login of a valid policyholder.
That persistence extends beyond just login requirements. Developers can enable users to create time-expiring documents. The EDI situation I mentioned earlier could be one place to use it for RFPs; once the due date passes, the RFP expires and cannot be opened.
Policy creation is available to designate content for certain users and groups. Information on members can be pulled from a LDAP server, making it easier for administrators to control who can access what applications.
The essential idea behind LiveCycle ES should make enterprises using it much more likely to draw help-seekers to the online process, rather than picking up a phone to call for assistance. Paper-heavy sectors like finance and government can make themselves more efficient by giving people the ability to get what they want, when they need it.
Eamon called the barrier to this self-service concept "the engagement gap." While paper is still required, people cannot help themselves effectively. Closing the gap means providing engagement services to one’s customers.
Adobe already has the front end of their engagement in front of potential application-using clients. Flash and the Adobe Reader are on millions of desktops, and they cross platforms. That’s certain to be part of Adobe’s enterprise pitch: customers already have the tools they need to use the apps you create.
Developers should be intrigued by the output possibilities for their LiveCycle ES applications. HTML exists as one option, of course, but they can also create output in Accessible HTML for speech-reading browsers, or Compact HTML for mobile devices.
Those options open what government or financial industry developers can promise their managers in terms of the audience an application can reach. Accessible HTML should be especially pertinent to government designers, whose agencies have to be available to all citizens, not just those with good vision.
A lot exists for LiveCycle ES developers and their company or government managers to consider. I don’t think the paperless society has arrived, but any broadening of paperless efforts across government and financial creators has to be beneficial.