Interesting things about ECM

2009/09/19

SWOT analysis on Oracle UCM by the University of Minnesota

Source: https://wiki.umn.edu/view/StellentWCM/UMContentSWOTAnalysis

Aug 24, 2007 – 08:39:55 – JeffreyAbuzzahab

UMContent (Oracle UCM) Pilot
Implementation SWOT Analysis

Strengths:

  • CSOM: The Core Services (SOA) architecture is outstanding.
  • CSOM: If you don’t have tons of autonomous units and are document centric, then you can’t go wrong with UCM as we have it installed today.
  • CSOM: Good separation of content from display.
  • CSOM: Metadata is available along with the document in most cases on the server side and SAO.
  • ASR: Content server is big and can handle large amounts of content.
  • ASR: Powerful, customizable, extensible from Content Server perspective.
  • ASR: Forces thoughtful organizing and structuring of content
  • ASR: Creates discipline in web page formatting
  • ASR: Document conversion engine (?dynamic converter?) does a pretty good job of transfering styles from basic word docs to the web
  • ASR: Document Management is the strength at the core
  • CEHD: Web interface to content manager is fast for a Web interface.
  • CEHD: Visual folder model in Site Studio great for organizing, naming URLs and naming navigation links.
  • CEHD: Dynamic Converter is surprisingly robust, and a fine solution for rigorously-structured Word docs.
  • CEHD: Dynamic navigation is efficient and stable.

Weaknesses:

  • CSOM: Can’t do full text search, let alone replace, and even ordinary content searches are tricky.
  • CSOM: Lots of server and OS – dependent configuration items make server setups difficult to maintain and clone.
  • CSOM: Many features are top level content server level features, mean the must be shared at the individual site levels. This forces us to rely on central administration of those features and any site specific customizations are less likely to happen if they then must be over ridden in every other site (we will have thousands of sites.) Examples: workflow, metadata, security.
  • CSOM: Site namespace issue: root level sites are not possible, requiring vast amounts of “bad links” link redirects or link rewrites.
  • CSOM: Direct linking to Contribution Data Files, no styles can be applied to these files. They just render very thing.
  • CSOM: Only one type of content can be set in the replaceable region on secondary layouts.
  • CSOM: Only one region on a secondary layout can be set as replaceable.
  • CSOM: Summary/Detail views are difficult to achieve (if not impossible)
  • CSOM: Forms based input is difficult to achieve (if not impossible)
  • CSOM: Experience programmers have difficult time locating information about services or iDoc syntax when faced with typical programming issues. (Documentation format issue)
  • CSOM: UCM is too native document centric, or may be just the documentation is to native document centric. We find that trying to use dynamic * CSOM: converter on forms submission, and static lists data file output is alluding us. We want to take the files and “work” with them and are finding it difficult to get dynamic converter to work with them.
  • CSOM: Site Studio is like web development from the 1990’s.
  • CSOM: Site Studio contributor content authoring interface is user unfriendly it is a hindrance to user adoption and acceptance (Site Studio user interface usability issue).
  • CSOM: Full CSS based layouts can cause site studio to behave oddly in both contributor mode and in site studio development mode, without lots of non-value added special handling.
  • CSOM: Inter-region HTML mark-up of element s appears to routinely disappear or be altered.
  • CSOM: Contributors will need extensive training compared to that needed for our current CMS or ‘many other CMSes’.
  • CSOM: Using the same Data File from a Static List in different regions on a primary layout and secondary layout might not work. If the replaceable content is supposed to use the Data File
  • CSOM: Centralized content server architecture makes it very difficult for Unit Areas to create components.
  • CSOM: Layout mark-up routinely disappears.
  • CSOM: Site Studio crashes fairly often.
  • CSOM: Fragment Edit mode is troublesome. Often I want to edit a fragment and I end up adding it to a layout. (Site studio usability issue)
  • CSOM: Excessive number of steps to edit web assets, five to seven click for each change.
  • CSOM: With the loss of some Admin features the navigation to support functions (like the link to dynamic converter disappearing.)
  • CSOM: Real Security Certificates are needed on the Dev/Staging/QA/Production instances.
  • CSOM: The product mix feels caballed together. Viable names, casing, formatting are all different depending on what part of the product you are in.
  • CSOM: We receive lots of “Unable to generate form” errors in site studio and contribution mode.
  • CSOM: Cannot preset Static list default values for each instance of a list on a layout, cannot even get rid of the useless Column 1, Column 2,… defaults.
  • CSOM: Lack of Debugging tools and functions
  • CSOM: Lack of log file views that are appropriate for Site Studio Developers and Contributors
  • CSOM: Thumbnails are not fuctioning on the Dev server
  • CSOM: Wysiwyg handles unordered lists and list items in unexpected ways
  • ASR: Slow to work with (multiple steps for simple concepts)
  • ASR: Complex, developer intensive, and doesn?t deliver a web site that warrants the front-end labor
  • ASR: I-doc scripting is proprietary and requires study
  • ASR: No pool of experienced developers around to learn from
  • ASR: No pool of experienced developers to hire
  • ASR: Kludgy – lots of work arounds
  • ASR: Doesn?t deliver on core RFP functionality
  • ASR: Can?t do full-text search and replace
  • ASR: No single sign-on (X.500 or LDAP)
  • ASR: Styling done within WYSIWYG editor is not accessible
  • ASR: Doesn?t provide semantic tagging with WYSIWYG editor
  • ASR: Inverse relationship between content provider flexibility and accessibility. One Stop will require both.
  • ASR: Cannot integrate outside data sources w/out JSP functionality
  • ASR: Access to some functionality is compromised by Admin vs. Sub admin roles
  • CEHD: Documentation for proprietary iDoc script is poor.
  • CEHD: Six pilots have overloaded the system, cannot exclude content from other Webs… goes over 255 character limit for naming exclusions.
  • CEHD: One poorly written query can bog down entire system.
  • CEHD: Expensive Web design client required for Site Studio to function properly, DreamWeaver? recommended.
  • CEHD: WYSIWYG editor is actually a form based editor.
  • CEHD: Form based editor does not support element-selector pairing in compliant CSS.
  • CEHD: WebDav? integration is odd, access to a folder requires access to all parent folders above in the hierarchy, this is just plain silly.
  • CEHD: System is completely dependent on Microsoft Windows OS to function, yet does not keep pace with progression of Microsoft developments.

Opportunities:

  • CSOM: We still see that having a central content repository as being a large value. But the limitations of what are top level shared services threaten this opportunity.
  • CSOM: Content objects are very sharable and movable; however the primary/secondary pages and their limitations seem to threaten this opportunity.
  • CSOM: Certain aspects of the SOA lend themselves well to CSS based implementations; however site studios in place contribution mode implementation and the default fragments are a threat to this opportunity.
  • CSOM: Being to use workflow to capture business processes, and efficiently queue content related tasks.
  • CSOM: Leverage the information in the Active Directory system (assuming OIT makes this one of their priorities too.)
  • CSOM: Change in Oracle handling of licensing is seem as a positive development. UMContent can now take advange of a more complete technology solution.
  • ASR: Shared content management across the institution will lead to a more consistent and effective institution-wide web presence
  • ASR: Metadata model is a good mechanism for content sharing
  • ASR: Distributed web content management is a model we will implement. We are looking for opportunities within that model to maximize the value of our content expertise without making overwhelming demands on our web developers. Web CMS should save IT time, not add.
  • ASR: Digital Asset Management and Document Management components have uses for ASR, and could be combined with Web CMS as a comprehensive communications tool.
  • ASR: Oracle may invest heavily in this product segment and integrate this product with other products we own (PeopleSoft?, UMCal, etc.) UMContent may end up providing us with an intergrated and flexible solution.
  • ASR: Working with units and OIT on deploying this product effectively requires a new level of IT cooperation- a level that we have not yet reached. That cooperation can be leveraged for other projects and products, and build trust between central and unit-based IT units.
  • CEHD: Hire developers centrally to clean up system
  • CEHD: Develop semantic fragments… then EVERYONE can use the same well-written fragments while retaining unique visual design.

Threats:

  • CSOM: Upgrades / enhancements may affect our current “workaround” development
  • CSOM: Components seem to have global effects. Each component could over-ride the next. The many add-ons in the server architecture will make for an unstable development environment.
  • CSOM: The Dev Content Server upgrade from 7.x to 10gR3 seems to have failed and we haven’t been told much. This makes us lose confidence. When we then asked about the customizations that Mariah did to the server while her, we found out that some of them where done without OITs involvement and that we are not sure if they were reapplied and functioning after the reversion back to 7.x. Images (?and assets?) didn’t work after the upgrade. UM Relations fragment templates had to be reapplied after the upgrade. (why?) No timeline after the attempt about when the upgrade might be reattempted, and no communication of the “all clear”. Therefor we must assume that somethings still aren’t working.
  • CSOM: Contributor mode continually asks for username and password.
  • CSOM: Wysiwyg – getting to the HTML Source view to be able to paste in Dreamweaver code is very combersome.
  • CSOM: Content Server searches are case sensitive (and appears to not be changable)
  • CSOM: Lacks the motion of “Modules” present in most Web Content Management Systems. 1 2 3 4 5 6 and the ones it does provide we have plenty of already. (wikis, discussions and blogs)
  • CSOM: Lack Forms management tools that are easily used by contributors.
  • CSOM: Lacks out-of –the-box the ability allow contributors to add content to layouts in ways they prioritizes.
  • CSOM: Lack of a OIT priorities list, users priority list, issues submitted to Oracle list with priorities, resources, costs and timeframe.
  • ASR: Number of pilots who now have sites up and live in production (0) is not a promising sign.
  • ASR: If pilots are not successful, adoption rate will be slow, thus sharing will be much less effective (less of an opportunity.)
  • ASR: Unclear how /not easy to share fragments, layouts, etc effectively
  • ASR: Metadata integrity is fundamental to large-scale deployment with content sharing. Not clear if units will commit to maintaining metadata effectively. Metadata may drive content inappropriately if not monitored for quality.
  • ASR: Spend big money on consultants / professinoal services to get the functionality and results we are unable to get on our own, and then still not be happy with the output.
  • ASR: Upgrades / enhancements may affect our current ?workaround? development
  • ASR: Upgrades / enhancements slow (The elusive 8.0 we said we would purchase.) When? Timelines are guesstimates. Many in the RFP group room said, “Yes, if it’s 8.0,” when the questions was to buy or not to buy.
  • ASR: Complicated and unwieldy for future support. Units need dedicated staff to be fluent in Stellent / i-doc skills to update/program changes for OCM and One Stop.
  • ASR: There is an inherent conflict between the desire to have a centralized WCMS for the University and our decentralized institutional structure and vested interests. It is possible that this product will never allow us the “atomization” of delegation that they claimed in the “response to RFP”, and therefore, will only be effective if seperate instances are used.
  • CEHD: No clean/easy migration path out of system.
Advertisements

Create a free website or blog at WordPress.com.