On a recent phone call with a Gilbane Group client, we were asked about the defining differences between WCM applications and portal applications. This question has two answers – a theoretical one and a practical one. In theory, portals provide a doorway (portal < Latin porta, gate) that, when opened, allows content consumers to view a particular set of content. The exact set of content to which consumers are exposed is (a) dynamic, and (b) controllable either by the application administrator or by the consumers themselves. Because the function of the portal essentially rests in this “doorway” or “frame” function, some customers see portal software as an empty shell or framework, with a set of underlying services, to which content-connected portlets can be added. WCM applications, on the other hand, theoretically provide all of the features and functions required to create, manage, expire, and archive content. This feature set typically includes authoring and editing tools for multiple content types, automated workflow, versioning, audit control, channel management, metadata management, library services, templating, access controls, personalization etc.
In practice, however, the feature sets of WCM and portal applications often overlap. One vendor’s portal product might provide the same feature as another vendor’s WCM application. Because portals are composite applications that expose component applications, this phenomenon also extends to products or modules such as ERP, CRM, search, collaboration, campaign management, etc. For this reason, depending on how vendors group features and functions in their product offerings, any given set of WCM or portal requirements may be satisfied by a variety of product combinations. One vendor’s WCM application may suffice. Another vendor’s portal product may also be a good fit. And a third vendor’s solution may include WCM, portal, and collaboration modules.
Because of this variation in vendors’ grouping and naming conventions, Gilbane clients should, during the technology selection process, seek solutions to their set of content management problems without becoming distracted by the exact names or number of modules or products required to provide the solution. Let vendors include whatever products they wish in their RFP responses, but hold them responsible for (a) satisfying every requirement, (b) identifying the modules that satisfy each requirement, and (c) giving a total price for all of the modules included in the response. In the end, “WCM and portal” by any other name is still “WCM and portal.”
Author: Tony White (Page 2 of 3)
While WCM needs-analysis and generation of a master requirements document (MRD) usually prove to be quite in-depth undertakings for most clients, the RFP submitted to vendors should aim to be as simple and concise as possible. Here’s why.
When vendors receive a very long, nuanced description of a functional requirement, it becomes easier for them to craft a response that technically satisfies the requirement and simultaneously to withhold other relevant and more meaningful detail. On the other hand, when vendors receive a brief description of a functional requirement or category, along with specific instructions to provide as much detail as possible (at risk of not receiving credit if enough detail is not provided), they often feel compelled to write as much they can. The abundance of information found in such responses usually allows the customer to discern just how well a vendor’s products or solutions match line items in the MRD.
Recommendation to Gilbane clients: After detailed needs analysis and creation of an MRD, pare the language for each functional criterion in the RFP to a somewhat general level. For example, rather than inquiring specifically about content locking models (along with the other 20-30 minute components within library services) ask instead for a complete description of what the vendor’s solution provides in the library services category. It is essential to state that more detail in the response is better than less, and that if a vendor omits relevant information, they may not receive full marks for that category. Following this suggestion, you will be surprised at how much more insight you gain from vendors RFP responses.
Over the next few months, I will post a series of 6-8 best practices for ensuring a high degree of usability in WCM implementations. This first entry in the series focuses on the ability for users to author content in the context of actual web pages.
While many vendors claim to support in-context editing, there is a lot of variation in how this feature is presented to users. In some cases, content authors fill in HTML forms and then click a preview button, which renders a virtualized copy of the web page. In other cases, authors double click on a staged version of a web page, which launches a WYSIWYG editor. Upon saving content in this editor, the author refreshes the web page and sees the updates. In the best cases, authors can simply edit content directly on web pages without having to fill in separate web forms or to launch an external editor. Content on web pages can be edited just as though it were in MS Word.
These differences may at first seem trivial, but it quickly becomes apparent to those who spend much time authoring content or creating web pages that eliminating unnecessary steps and reducing the number of applications in these highly iterative processes produces dramatic time savings throughout the organization. For example, if an enterprise has 25 content authors who each maintain 10 web pages daily, and each page update takes just 10 extra minutes because of redundancies, the time wasted over one year totals more than 10,000 hours. This represents about $500,000 of unnecessary labor costs.
Recommendation to enterprises: Be sure to analyze carefully during vendor demonstrations exactly how content can be edited directly from a web page. The most highly usable WCM systems will allow you to treat the web page like word processor.
This is just a quick reminder to our Analyst on Demand subscribers that the results of our survey on the usability of commercially available content management solutions will be available in early September. The data will come directly from the feedback of the solution providers’ customers. Vendors covered will include Interwoven, Tridion, Vignette, FatWire, Percussion, RedDot, EMC/Documentum, CrownPeak, Mediasurface, PaperThin, Oracle, Day, Hot Banana, Clickability, Acumium, and others.
In recent conversations with several of Gilbane’s Analyst On Demand and Technology Acquisition Advisory clients, I have observed two careless practices that have prevented enterprises from being able to assess both the feature-functionality of their existing WCM applications and their requirements for selecting solutions to replace those applications. Both relate to a lack of documentation.
In the first case, it’s the absence of a master list of the WCM-related applications that have been developed in-house over the years. One company has “about 50” such applications, and geographically-dispersed individuals throughout the enterprise can tell me what some of them are, but no one can refer me to anyone or any system that has the complete listing. Discrete ongoing development projects exist for many of these applications, a few of which live buried deep in departmental silos. Needless to say, the functionality of applications within these silos is known only to a few people, is never re-used in other initiatives, and in fact often gets duplicated by newer siloed projects.
The second shortcoming is the non-documentation of feature-functions within the applications themselves. Even when applications are well known throughout the organization, their complete functionality sets are known to no one. This results in duplicate development, redundant purchases, and negative ROI — although no one knows just how negative.
At a minimum, enterprises should maintain master lists of both their WCM-related applications and the functionality within each one. To make effective use of such documentation, companies should establish effective dissemination processes. Examples range from the inclusion of key individuals in change control board meetings (for companies with predictive-style development methods) to informal cross-functional communication, especially between disparate technology groups, but also between IT and the business units whose requirements drive application development.
Business managers serving on WCM product-selection teams or attending technology conferences sometimes ask for definitions of “Web services” and “service-oriented architecture (SOA).” They say they are confused by their IT teams’ usage of the terms as though they were synonymous, and that when the managers themselves use the terms interchangeably, they get corrected. Why does this happen?
Web services, a technology standard, and SOA, an architectural design methodology, are highly complementary. Yet they are distinct. “Web services” refers to technologies that allow enterprise applications of all kinds (WCM, CRM ERP, BI, etc.) to communicate with each other. Common forms of Web services include application programming interfaces (APIs), which are connectors written by software vendors that allow for a standard way of communicating with their applications. Vendors often publish or sell these APIs as a straightforward means of connecting. Another common – and more generic – example of a Web service is any message, often in XML format, exchanged between a client (a Web browser, for example) and a server (your bank’s database) using the SOAP protocol. There are variations on these two themes, but the important concept to remember about Web services is that, simply put, they allow for a standard means of communication between software applications which may or may not rely upon transmission over the Web. Web services very frequently communicate only over corporate networks.
SOA, on the other hand, is not a technology. Rather, it is a way of designing connections between objects (application code components), applications, and other technology infrastructure. Like the frame of a building with respect to its windows and floors, SOA only defines the relationships between technology components, not their composition. SOA’s goals are to achieve self-sufficiency for each component – i.e. that each component will perform one complete task or “service” – and for each component to offer its “service” to all of the others. It stands to reason then, that Web services and SOA often fit together well because SOA provides a framework within which discrete components can interact with each other, and Web services provide a standard way of building the components.
As the consumption of Web content becomes more highly scrutinized by business managers measuring the effectiveness of corporate information portals and online retailers analyzing conversion rates for their marketing campaigns, the importance of rich media as a fundamental enabler of the ideal user experience has reached the critical point both for enterprises choosing WCM solutions and vendors selling them. Over the past year, companies have begun prioritizing in their selection criteria the ease with which business users can create highly-usable Web sites containing multiple rich content types. Because design agencies are repositories of expertise in site usability, it is not surprising that the market has seen a dramatic rise in their influence on enterprise selection processes. Web design firms now influence 15-20% of all enterprise-wide WCM solution purchases in the U.S. and 25-30% in Europe (including systems integrators with usability domain expertise).
What does this mean for enterprises? First, it means that they can use design agencies as leverage points to ensure that vendors with the most usable solutions win their business. Secondly, it means that WCM solutions themselves are improving rapidly in terms of usability. Software vendors know that no longer can corporate IT departments prioritize low-level feature-functionality over interface design, and therefore enhancements to user interfaces are far outstripping those to extended feature-function lists. Lastly, the increased use of analytics packages to measure the performance of WCM systems against pre-defined goals means that the ROI for these systems is becoming both more quantifiable and – very likely – more positive.
“Web 2.0” is a term that gets bandied about far too often with far too little associated meaning. Essentially, Web 2.0 refers to multi-directional interactivity between one or more humans and one or more Web applications (with their associated back-ends) — period. The term often pops up in descriptions of any of the following: social computing, blogs, wikis, folksonomies, Web services, RSS feeds, online applications, collaboration, mash-ups and the Web as a platform. Don’t let the diversity of topics given as examples of Web 2.0 distract you from the fact that the key operative term is multi-directional communication. What does this mean for WCM?
For the end user, it means that Web applications such as online banking, which now rely heavily on technologies like Flash and AJAX, provide better customer service by building-in higher levels of interactivity between the user and the data within a browser session and by encouraging more efficient communication between the browser and the host. Whereas before, every user request meant a round-trip to the server, now far more data is sent at once to the browser, often in the form of an object with which the browser can interact. The user then manipulates the data multiple times – transferring funds between accounts, paying a bill, and updating an address, for example – and upon logging out, transactions are sent to the server all at once for processing. Because technologies like Flash and AJAX provide for easier inclusion of rich media in the user interface, the combined effect of these Web 2.0 technologies is reduced development time for programmers, a more satisfying user experience for consumers, server processing efficiency for the host, and bandwidth savings for everyone. Another significant advantage of Web 2.0 technologies for WCM is the tendency to be so highly based on well-defined standards that functional components of Web applications are often interchangeable. When built on Web 2.0 technologies, the “address update” function in the Web banking example above would likely be usable by the bank’s credit card Web application as well. This component swapability is the underlying principle behind enterprise mash-ups, a developer-oriented topic for an upcoming blog entry.
