Stand Alone vs Invisible ECM
By billy.cripe on Aug 31, 2007
One of the differences between ECM aps and ECM sdks or tool kits is the exposure to the end users. While each of the main players in the ECM space have end user oriented front ends, we each also tout our abilities to integrate with and surface content to / through other enterprise infrastructure systems, be they portals, user management systems, static web sites, BI tools, or Line Of Business applications.
The question I have is when to go which direction? When do you rely on the ECM system as an application and, say, rebrand the OOTB UI to say "My Company". When do you leave the system as is and keep it behind the scenes, leveraging the ecm services and capabilities through integrations (custom or otherwise)? Needless to say, this is definitely not a strict "either / or" question. But I still think the question obtains.
Customers don't really want to buy a tool kit and raw materials - even if they really want a tool kit and raw materials. They want to know their investment works out of the box and they can start using it as soon as the install is done.
So we create better and better front ends and user experiences etc. We build in swoopy web 2.0 interfaces and leverage ajaxy widgets to improve everything from page refresh rates and screen flickers to proofing of user-entered information.
Yet in many implementations we find that the customer has a vanilla instance of the software sitting behind their applications/websites/portals/analytics. When I was working as a Stellent consultant the vast majority of gigs we did was integration work where the ECM services were doing their thing (conversion, revisioning, renditioning, workflow, filtering, securing etc) but they were doing it behind another system. Our SOA came in handy to be sure.
So the question to the field is what makes you decide to implement stand alone solutions (and have the users learn another system/UI/process) vs an unified / integrated solution (and have the users wait while the integration project is devised, implemented,completed)? Is it cost? (stand alone track is inexpensive - install and go). Is it user adoption? (Integration projects may have better user adoption due to the decreased need to learn a new system/process). Is it the number and kind of resources you already have in house? (if you have a crack staff of chop-shop engineers, leveraging a nice pre-configured set of services is easy).