Perhaps the only thing that changes more rapidly than technology in today's amped-up digital environment is the terminology used to describe that technology and its impact on consumers--and marketers. One recent example is the advent of the term "omnichannel" marketing, which many struggle to differentiate from another relatively recent term--"multichannel" marketing. Still, those who are most enmeshed in the field say there is a key distinction between the two, and it's one that will have an impact on marketers as they continue to seek ways of having a meaningful impact on the consumers they hope to engage. And, importantly, it's less about technology than it may seem.

Setting StandardsNew standards emerging in the portal market may spell relief for customers and vendors. In 2002, Sun and IBM led a joint effort to create a standard portlet API that would enable portlets to be shared across portal servers from different vendors. That standardized API, now known as JSR (Java Specification Request) 168, is a Java-based standard ratified by the Java Community Process in September 2003.

Abramski explains that JSR 168, "defines a standard way for a third-party application or an enterprise developer to take a piece of content—news feed, stock quotes, a content management system, whatever— and write one piece of code that allows them to plug that content into any portal server that has been written to the JSR 168 specification." This means that content providers should only have to write one set of portlets that could then be used across the portal software market.

This is understandably popular with the content vendors. Jeff Misenti, product manager at MarketWatch, says, "Standards make it easier for everybody involved. If a customer comes with a portal we haven't worked with and that portal is JSR 168 compliant, we have a starting point." Gerdy at Factiva agrees, "This will make life easier. We welcome standards."

More importantly, JSR 168 should provide a level of comfort for customers. Theoretically, choosing a portal software product that supports JSR 168 should mean that any portlets written to this spec will run on that portal. So any content provider that offers JSR 168-complaint portlets should be able to provide portlets that will work with a JSR 168-compliant portal product.

Standard Drawbacks "If all you're trying to do is get content onto a portal page," says Soffer at Plumtree, "the problem is solved with JSR 168-compliant portlets." This benefits customers as they can seek out vendors that support this standard and be guaranteed a baseline of the ability to integrate content out-of-the-box. Soffer says, "Many customers today are satisfied with a baseline of content." So for these customers, the specification may be a huge time-saver. But what about those customers who are looking for a more sophisticated integration of external content into their portal applications and workflows?

While JSR 168 can greatly simplify the process of integrating external content into portal servers, version 1.0 of the specification does little to address more complex requirements. Ramos at Forrester says, "JSR 168 can help you from the standpoint that you don't have to do custom integration to get portlets to run in the portal. But it doesn't solve issues like: Is the content relevant? How many customization options are there? The standards will save you a lot of work if you're willing to take the portlet exactly as it is delivered by the content provider." She also notes that as a Java standard, it is specific to portlets that run inside Java-compatible portal servers.

Sun's Abramski agrees that version 1.0 of the specification doesn't cover everything. Some private APIs for personalization and security will differ with each portal vendor. He says, "The customer will still have some work that needs to be done, but it will be a lot less."

Soffer thinks that the standards get everyone to a baseline of functionality, which will then free developers to create more sophisticated integrations. "Maybe [the standard] creates an incentive for a content provider to create portlets that are more powerful," he says.