Ending the Tyranny of False Network Connectivity Assumptions

You can’t always connect to a network. Some have done better with that reality than others.

Microsoft desktop software assumes the user is connected to the network. I’ve been on a 100% travel schedule for years at a time, so the assumption of full-time network connection seems outlandishly wishful. I’ve found Outlook particularly offensive in this regard. After years of trying to get used to it, I still want to return to Lotus Notes Mail, which was designed with a traveler like me in mind.

Verizon’s VZAccess Manager and AT&T’s Communication Manager have provided good data network connections for the significant amounts of time between hotel rooms and offices. Airlines such as AirTran now offer connections while in flight. The only problem is that the assumptions about connectivity require more bandwidth than these services generally deliver.

I don’t hold it against developers who build assumptions into their software based on a future expectation of infrastructure. I understand that as much as I do travel, many others do most of their work from an office with a lot of reliable bandwidth. At the same time, there is a large and growing community of mobile people like me who have been forced to improvise and scramble to use software designed with us as an afterthought.

There is new hope that the tyranny of false network connectivity assumptions may come to an end. It comes from “desktop” and social networking applications accessed via mobile devices such as Blackberry and iPhone.

I wanted to see Matt Coblentz’s presentation of CenterStage Mobile Client at EMC World last week, but schedule conflicts prevented it. I saw Matt in the corridor later and he showed me something more convincing. He demonstrated on the spot that he is already using CenterStage Mobile Client with his Blackberry Bold. I am not a bleeding edge technology adapter. Relative to others in the industry, I am a laggard, but not this time. I’ve seen CenterStage Mobile Client in action. It’s a real productivity enhancer. It will work with my existing Blackberry, and I want it.

That answers one of the questions posed in last week’s post, and here are the others:

Q: Does CenterStage provide the end user functionality that users and businesses will readily adopt?
A: This is highly addictive functionality. Once users get their hands on it, they won’t want to let it go.

Q: Does CenterStage fully deliver the back end capabilities of Documentum Content Server?
A: In theory yes, CenterStage delivers the backend functionality. It’s a good bet that this theory will be proven in fact, because all CenterStage content is being stored in CenterStage.

Q: Does CenterStage have the flexibility to allow enterprises to centralize or decentralize administrative responsibilities? To the extent administrative responsibilities are decentralized, does CenterStage allow safeguards to keep departmental administrators within bounds of enterprise policies?
A: CenterStage is looking good in this regard. Initial deployments will prove it out, but this seems like another low risk bet.

Q: Does CenterStage have an advantage in accelerating mobile computing applications?
A: This is the real surprise behind CenterStage. I didn’t think this question was going to have the most exciting answer, but it does. If you’re a mobile professional you can see an end to the tyranny of false assumptions about connectivity.

The Dawn of New Age of Collaboration?

Ever since there have been departmental systems, Collaboration has been departmentally focused. eRoom, Lotus Notes, and SharePoint owe their success to end user functionality on the one hand, but also to departmental deployment and control models that support viral adoption across the enterprise on the other hand. Given the trends of enterprise consolidation and cloud computing, the time may have come for the pendulum to swing back to a centralized model for collaboration software. (Remember collaboration before Lotus Notes?)

The pendulum should not swing to complete centralization of responsibility and costs. Rather there should be a shift that lets responsibility and cost lie where it is most effective. In such a shift, enterprise policies would be controlled centrally. Work structures would be defined and implemented in decentralized fashion, for greatest responsiveness to the demands of work on the front lines. Each business would fine tune the balance of what is centralized and what is decentralized according to its own needs.

Consolidation within enterprises and cloud computing are driving the infrastructure for centralized computing, but what about application software for centrally deployed collaboration? EMC Documentum CenterStage targets this space. More will be revealed about CenterStage this week at EMC World 2009 and we’ll all be better able to gauge the alignment of the trends toward centralized infrastructure with the centralized control model of CenterStage.

Here are a few things to look for:

• Does CenterStage provide the end user functionality that users and businesses will readily adopt?
  
• Does CenterStage fully deliver the back end capabilities of Documentum Content Server?
  
• Does CenterStage have the flexibility to allow enterprises to centralize or decentralize administrative responsibilities?
  
• To the extent administrative responsibilities are decentralized, does CenterStage allow safeguards to keep departmental administrators within bounds of enterprise policies?
  
• Does CenterStage have an advantage in accelerating mobile computing applications?
  

A good portion of the 2009 EMC World content management agenda is allocated to CenterStage. The next few days will shed some light on whether CenterStage is a sign of the dawn of a new age of collaboration.

They are both Right about Web 2.0. Now Get a Backbone in Place.

“Web 2.0 is the business revolution in the computer industry caused by the move to the Internet as a platform, and an attempt to understand the rules for success on that new platform”, says Tim O’Reilly. “I think Web 2.0 is of course a piece of jargon, nobody even knows what it means.”, says Tim Berners-Lee, “It’s dookie.” They are both right, but it doesn’t matter.

Whether you agree with O’Reilly or Berners-Lee, information technology organizations must deal with the adoption of social-networking, video-sharing, wikis, blogs, and user tagging. Because people use them and businesses demand them, the infrastructure has to control and support Web 2.0 applications.

Public Web 2.0 facilities can achieve inter-company benefits, but those public facilities don’t meet the large organization’s need for control or support in the areas of retention, access, security, availability, and cost. In those large organizations, rogue Web 2.0 islands have likely sprung up internally and increasing adoption has caused unplanned cost and risk. Public facilities and rogue islands were fine when Web 2.0 applications were an experiment, but for many companies, enterprise-caliber infrastructure is now required.

Enterprise Content Management (ECM) technology is a promising backbone for Web 2.0 applications. The appeal of ECM is first in the fit and maturity of the technology. ECM is designed to manage unstructured information such as addressed by Web 2.0 applications and has been proven at enterprise scale for over a decade. The appeal of ECM is also in the potential to leverage existing investments. Most large companies have existing ECM platform investments that can provide needed support and control to Web 2.0 applications.

EMC Documentum Content Server (Documentum) is playing the role of backbone for Web 2.0 applications via two different approaches. First, Documentum has traditionally played a repository role for custom-built or niche front-end applications. Documentum plays a similar back end role when used in conjunction with Web 2.0 solutions built using Crown SiteBuilder and Crown Web Gear products. In the second approach, EMC has built on it’s eRoom heritage of providing application front-ends, and EMC is now extending eRoom solidly into the Web 2.0 era with its CenterStage product.

If you have enterprise-scale Web 2.0 needs, Crown can help you evaluate your options and put the appropriate infrastructure in place. Ask us about our SiteBuilder and Web Gear products and about our experience with EMC CenterStage.

Heterogeneous ETL Platform Capability as a Content Consolidation Enabler

Extract Transform and Load (ETL) operations can be homogeneous or heterogeneous. Homogeneous operations involve extract from a repository and load into a repository of the same technology. As an example, one can synchronize the content in a North American Documentum repository with the content in a European Documentum repository via a homogeneous extract and load (i.e., from Documentum and to Documentum). Two or more technologies are involved in a heterogeneous operation. As an example, one can migrate from FileNet to Documentum, by extracting from FileNet and loading into Documentum.

The challenge with content consolidation is that there are several, if not numerous, repository technologies to be addressed. For example, if content in SharePoint, FileNet, Lotus Notes, and ApplicationXtender are content sources to be consolidated into a Documentum target infrastructure, then extract must be performed on four different technologies and load into one technology. Each of the technologies involved implies a need for knowledge of the technology, technical infrastructure (e.g., test environment), and existing functionality to connect to each repository technology. A heterogeneous ETL platform capability addresses each of these needs:

• Knowledge of each technology is required to inform consolidation strategy from an enterprise taxonomy point of view. Knowing each source technology is required to understand how the content in each source will map to a taxonomy for the enterprise. Knowledge of each source technology is also important for consolidation efficiency. Consolidation efficiency can be improved by best leveraging technical capabilities in the source, such as indexes and application programming interfaces.
  
• Technical infrastructure (for the several or numerous technologies involved) to test and execute consolidations can be costly and time consuming to establish, but is required for an effective consolidation program. In most consolidation programs, the technical infrastructure is required for a finite period of time, and obtaining required infrastructure via outsourcing is an economically attractive idea. Aside from traditional outsourcing or hosting, large consolidation programs can also leverage infrastructure of solution providers or software vendors.
  
• Constructing extract connections to each source repository technology is the most technically risky portion of a consolidation effort. Using pre-existing extract connections for the source repositories or proven models for constructing them greatly reduces the risk.
  

If you are like 69% of companies in a recent Gartner survey (see my April 19, 2009 post), you have more than 6 content repository technologies in use. Crown’s Professional Services and Crown’s Buldoser Center Product represent a heterogeneous ELT platform that reduces the risk and cost of consolidations. Cost and risk are the two main obstacles to consolidation, and with those obstacles addressed, what’s stopping you from consolidating?