Interesting things about ECM


Should Oracle be on your Web CMS shortlist?

Filed under: Oracle UCM, Performance, Security, Stellent, WCM — Tags: , — Anthony Fast @ 1:58 pm

August 31st, 2009 by Janus Boye

Oracle is among the largest global enterprise software vendors and like IBM and Microsoft, Oracle entered the CMS marketplace via an acquisition (Stellent in 2007). Oracle Universal Content Management (UCM) is based on the original Stellent product now fully rebranded, much improved and leading the market according to IT analyst Gartner. Does this make Oracle an obvious and safe candidate on your Web CMS shortlist?

We find that Oracle UCM does not come up often in standalone Web CMS selections, which is why it did not appear on our 2009 CMS Shortlist. According to Oracle sales pitches, the product has experienced increased adoption in recent years. As the Oracle customer list is very long and Oracle is known for upselling to the install base and for including UCM in larger deals, this sounds plausible.

Depending on your specific requirements, there are several reasons which might make Oracle a meaningful inclusion on your shortlist.

  • Oracle has continued to invest engineering resources in the product and made several recent improvements to the WCM part of UCM including usability, personalisation and accessibility.
  • As a large software vendor, you may already have a strong existing relationship with Oracle. If this the case, your stakeholders will probably appreciate getting a proposal from Oracle.
  • If you have a strong requirement to manage non-web content, eg. documents, this will play well with the product’s strengths.

Before you go ahead and add Oracle UCM to the shortlist here’s a few bullets for your consideration:

  • License and implementation cost will require a serious budget. The starting price is either US $115k  per-CPU or $2,300 per system user. Moreover, Oracle implementation partners are not known for attractive hourly rates.
  • Usability might have been improved, but still existing customers on the newest version of the product are so frustrated with poor usability that they publish commentaries like Oracle, can you improve your poor usability please? by Mark Morrell at BT.
  • You will need to learn the proprietary “Idoc Script” language for Site Studio until 11g release comes out.
  • UCM is a complex product and will be overkill for many scenarios.

Oracle is planning to release the much-anticipated 11g version of Oracle UCM later this year, which we look forward to studying closer. In the mean time, consider talking to Oracle on getting more information about what’s coming.

Comment on this article by Kas Thomas August 31st, 2009 21:49, Source:

I would add another precautionary bullet point, having to do with the rights model. Study the UCM roles and rights model carefully and compare it against your requirements; that’s my advice. Maybe @bex or someone with deep UCM experience can educate me here, but I find the UCM rights model a tad unconventional. It defines a security group as a collection of files (not users). It maps rights to roles, then users to roles. Each security group is accessible to appropriately privileged roles.

If you create more than 50 security groups, system performance (initially at the admin level, but eventually at the user level) begins to take a hit, at which point Oracle suggests you turn on a feature called Accounts, which is a more granular, hierarchical permissions model. But if you choose to enable “Accounts,” you can’t go back to a non-accounts-enabled model without losing data (according to Oracle’s own documentation).

The whole thing seems a bit scary to me, but maybe that’s because I don’t understand it, which is not infrequently the case with things that scare me.


A Letter to EMC About Federations

Filed under: Documentum, Performance, Security — Tags: , — Anthony Fast @ 10:23 pm


Dear EMC,

Hey there.  How are you doing? It was nice running into you at the AIIM Seminar last week.  I’ve been trying to tell people that CenterStage is not intended to take SharePoint out as we discussed.  People are listening, but only time will tell if it will matter.

I want to talk to you about an issue that I’ve been encountering.  I’ve talked to you about this before, but I’m not sure that you were paying attention.  I just wanted to mention it again to let you know that this is actually important.

I just spent 11 hours of my weekend creating a Federation in a production environment.  It wasn’t the only thing being done to the environment this weekend, but it was a big-old dependency for many other tasks.  We were creating a new repository and don’t want to manage our users (15K), or the corresponding ACLs, in multiple locations. Since a single repository was out of the question, we went the federated route.

Here is the creation process…I create a Federation in the global repository.  It then creates a Federation object in the member repositories and then exports the users, groups, and roles into a file.  That file is then ingested into the member repositories.  The issue is, problems are always encountered during the process.  You’ve told me that there is no recovery or “fix”.  The answer, according to your tech support, is to delete the Federation and repeat the process.  The deletion doesn’t always work and I have to confirm that the data in the database for all repositories reflect the deletion.  There are a few service restarts in there to make sure that caches are clear as well.

This is repeated until it works.  It isn’t helped that if a user is renamed in LDAP that the change doesn’t get reflected in the groups.  This causes the group to fail when it is moved to another repository because it can’t find the user.  Why the rename doesn’t work, or why you still use user names and not your unique object ids to do this linking, is for another day.

I finally got it all to work and my team is wrapping the deployment up, after many had to wait around for the Federation to complete.  Someone brought in Krispy Kreme, so we aren’t starving (though we probably all lost a few days from our life span).  I’m even coming to terms with missing the Tennessee-Florida game and the upset of Southern Cal by Washington yesterday.

Assuming that the process worked the first time, it should have been over and done in an hour or less.  My client is paying for the time. The problem is, I can’t get that 10 hours back with my wife or kids.  Half of my weekend is gone from this process and I want to know…

How are you going to help me make it up to my family?

See you soon.



SharePoint Scaling Limits

Filed under: General, Performance, Scalability, Sharepoint — Tags: , — Anthony Fast @ 6:14 am


I frequently get asked for SharePoint scaling limits so I though I would blog an entry I can refer people to.

First an extract from the Capacity Planning section of the Windows SharePoint Services Administration guide which answers general WSS limits questions:

None of these are hard limits enforced by the system. They are guidelines for designing a server that has good overall performance.

  • Site collections (Database scope) 50,000 … Total throughput degrades as the number of site collections increases.
  • Web sites (Web site scope) 2,000 … The interface for enumerating subsites of a given Web site does not perform well much
    beyond 2,000 subsites.
  • Web sites (Site collection) 250,000 – You can create a very large total number of Web sites by nesting the subsites. For example, 100
    sites each with 1000 subsites is 100,100 Web sites.
  • Documents (Folder scope) 2,000 … The interfaces for enumerating documents in a folder do not perform well beyond a thousand entries.
  • Documents (Library scope) 2 million … You can create very large document libraries by nesting folders.
  • Security principals (Web site scope) 2,000 … The size of the access control list is limited to a few thousand security principals, in other words users and groups in the Web site.
  • Users ( Web site scope) 2 million … You can add millions of people to your Web site by using Microsoft Windows security groups to manage security instead of using individual users.
  • Items (List scope) 2,000 … The interface for enumerating list items does not perform well beyond a few thousand items.
  • Web Parts (Page scope) 100 … Pages with more than 100 Web Parts are slow to render.
  • Web Part personalization (Page scope) 10,000 … Pages with more than a few thousand user personalizations are slow to render.
  • Lists (Web site scope) 2,000 … The interface for enumerating lists and libraries in a Web site does not perform well beyond a few thousand entries.
  • Document size (File scope) 50 MB … The file save performance degrades as the file size grows. The default maximum is 50 MB. This maximum is enforced by the system, but you can change it to any value up to 2 GB (2047 MB) if you have applied Windows SharePoint Services Service Pack 1.

For SharePoint Portal Server, here’s an extract from the Capacity Planning whitepaper:

It is important to understand the ramifications of the different features and functions of the SharePoint Portal Server solutions to size the system so that the performance of the system is good.

The following table lists some of the SharePoint Portal Server objects and describes their recommended use. “Typical” indicates comfortable and well tested; “maximum” indicates that the system can support that number, but not without some performance ramifications or
special configurations.

An asterisk (*) indicates a hard limit; no asterisk indicates a tested or supported limit.

  • Portal sites (full) – typically 2 … maximum 15 *
  • Portal sites (child) – typically 10 … maximum 100 *
  • Areas – typically 1,000 … maximum 10,000
  • Best Bets – typically 1,000 … maximum 25,000
  • Area depth – typically 5 … maximum 20 *
  • User profiles – typically 50,000 … maximum 1,000,000
  • Audiences – typically 500 … maximum 10,000
  • Audience memberships – typically 500,000 … maximum 5,000,000
  • SSO credentials – typically 100,00 … maximum 100,000
  • Search indexes – typically 3 … maximum 32
  • Content sources -typically 25 … maximum 250
  • Search scopes – typically 25 … maximum 250 *
  • Indexed documents per content index – typically 100,000 … maximum 5,000,000
  • Indexed documents – typically 2,500,000 … maximum 20,000,000
  • Thesaurus entries – typically 1,000 … maximum 10,000
  • Alerts – typically 50,000 … maximum 1,000,000
  • Team sites – typically 10,000 … maximum 250,000
  • Personal sites – typically 10,000 … maximum 250,000
  • Understanding the differences between Alfresco’s repository implementations

    Filed under: Alfresco, General, Performance, Scalability, WCM — Tags: , — Anthony Fast @ 6:14 am


    People new to Alfresco are often unaware of the existence of two different repository implementations within the product. One, which I’ll call the “DM Store”, is the classic store, the one that’s been used by Alfresco since the beginning. The other, the “WCM Store” or, as it is often referred to in API-speak, the “AVM Store”, was born with the addition of the Alfresco WCM product offering. Whether you are doing document management or web content management, you use the same Explorer client, but under the covers, your content lives in two very different types of repositories.

    The Alfresco story on why a second repository implementation was created is that the Engineers writing WCM didn’t believe the DM store was capable of providing the kind of support for versioning, branching, and layering functionality they needed (hence, the AVM acronym, which stands for Advanced Versioning Manager) so they created an entirely new repository implementation to support WCM.

    Why does this matter, apart from being a possible topic of conversation at your next get-together (”Healthcare is easy to fix. Do you think Alfresco will ever unify their two repository implementations?”)? It matters because the “two sides” of Alfresco are not equivalent in terms of functionality and depending on what you need to do, you may find yourself performing unnatural acts to work around the disparity.

    Many projects will be completely unaffected by the differences between Alfresco DM and Alfresco WCM. But it is important to know what these differences are when you first begin to plan your solution to avoid uncomfortable conversations between you and your customer when you realize you’ve made a bad assumption.

    I’ll assume you know the high-level capabilities of both Alfresco DM and Alfresco WCM. Obviously there are some things one product can do that the other can’t that are by design (sandboxes and virtualization in WCM, for example). What’s more important to understand are the subtle (and sometimes not-so subtle) differences between the two. Here’s the list and a table that summarizes, if you are into the whole brevity thing:

    Content Modeling. Alfresco DM uses a proprietary XML-based description of the content model while Alfresco WCM uses XML Schema. On the surface this isn’t a big deal, but it does mean if your repository contains a mix of DM- and WCM-stored data, you won’t have a single model that defines it all and you could possibly have duplication between the two.

    Custom Content Types. In Alfresco DM, when you create content, you tell Alfresco what its content type is. If you’ve extended the out-of-the-box model, you can have any number of business-specific content types with your own custom metadata. In Alfresco WCM, custom content types are not supported. In WCM, your content type is your web form. Interestingly, although the “Type” dropdown is shown in the “Create Web Content” dialog, and it will contain custom content types you’ve defined using the Alfresco DM model, your selection will not be honored. All AVM content is created as an instance of the “avmplaincontent” content type no matter what you select. However, although you must do it through an API call, you can apply custom aspects to AVM content.

    User Interface Configuration. Alfresco DM uses a proprietary XML-based configuration file to define the “property sheets” that display metadata in the Alfresco Explorer client for a given content type or aspect. Alfresco WCM uses the embedded Chiba XForms engine to inspect the XML Schema (XSD) and automatically create a web form that will produce data that conforms to the XSD. XSD annotations can be used to influence the presentation of the form fields. One outcome of this is that it is much easier to localize things like property labels in Alfresco DM than it is in Alfresco WCM.

    User Interface Extension. If you need to change how the Alfresco Explorer client behaves, there are some things you can do through XML, but advanced customizations will require JavaServer Faces (JSF) development. Alfresco DM and WCM both use the same Explorer client so this applies to both (See “Alfresco User Interface: What are my options?”). However, if you need to change how the web form engine works, you may need to write new Chiba XForms widgets. For instance, Optaros developed a web form used to describe points and regions on Google Maps. That kind of thing requires you to understand how to extend Chiba.

    Structured (XML) data entry. Data entered in an Alfresco WCM web form is saved as XML that conforms to the XSD you’ve defined. There is no similar facility for capturing data as XML available within Alfresco DM. At one point the Community code line had “ECM Forms” which was essentially WCM web forms for the DM side of the house, but that’s disappeared in the latest Community release. On the DM side, when you edit metadata you are editing object properties whose values get stored in the database, not as XML.

    Transformations. You can use either Freemarker or XSLT to transform Alfresco web form XML into other formats. That transformation is defined as part of the web form configuration which you do within the Explorer client. In Alfresco DM, transformations are more about binary file transformations (DOC to PDF or GIF to PNG, for example). If you want to do Freemarker or XSLT transformations on XML content stored in Alfresco DM, you’ll need to write that yourself (an Action would do the trick). If you want to do DM-style transformations on binary files in Alfresco WCM, that’s not out-of-the-box. You’ll have to do that using the API.

    Rule actions. Alfresco DM allows you to configure rules on folders to trigger actions (out-of-the-box or custom) to operate against newly-added, updated, or deleted documents. Alfresco WCM does not support rule actions at all.

    Auditing. Alfresco DM has a granular auditing sub-system. You can configure it to audit just about anything you want. Anything except WCM. You can audit web project creation, but not changes to individual web assets within a web project. At least not out-of-the-box.

    Object-level permissions. In Alfresco DM you can assign users and groups to roles at the folder and file level. In Alfresco WCM, the UI will only let you go as low as the web project level. The API supports more granular security but you have to implement that yourself with custom code.

    Search. Everything in Alfresco DM is full-text indexed and searchable. In Alfresco WCM, only the Staging Sandbox of each web project is indexed. You can do a search from your user sandbox but you’re really searching the Staging Sandbox. If you have any content you’ve created in your user sandbox that you have not yet committed to Staging, web project search won’t find it. Another limitation is that you cannot search across web projects. That search box that’s visible in the far upper right-hand corner of the Alfresco Explorer client is the Alfresco DM search–it won’t find anything in any of your web projects.

    Advanced Workflow. Alfresco DM and Alfresco WCM use the same JBoss jBPM workflow engine so there’s no functional difference between what you can do with workflow on either side. The only catch is that in Alfresco DM, all deployed workflows show up in the “Start Advanced Workflow” dialog whereas in WCM, you have to tell Alfresco which deployed workflows are okay to use for WCM. That’s covered in the Alfresco Developer Guide and on the wiki.

    File protocols. CIFS and FTP are the only two file protocols supported by both Alfresco DM and Alfresco WCM. Similar protocols supported by Alfresco DM such as WebDAV, inbound SMTP, and IMAP, are not supported by Alfresco WCM.

    Deployment. Some people use Alfresco DM to manage content that is published to the web because they don’t need the additional features WCM offers, or they have some other reason to export content to another server. Unfortunately, Alfresco DM does not yet offer a deployment component like the one in Alfresco WCM. If you want to export content from Alfresco DM to some other destination in a systematic way, you’ll have to roll your own solution.

    As John and Paul said, “It’s getting better”

    Some of these differences will become less drastic in coming releases. For example, Alfresco is implementing a new form service that will be used to define the content model and user interface across the entire product line, so that helps. The WCM deployment functionality is also being refactored and will ultimately work for both DM and WCM. And at every community event Alfresco talks about “repository unification” as a goal for the future, although the timeline is lightyears away in terms of software releases.

    As I said, depending on what you’re doing these differences may not affect you at all. Just make sure you don’t assume that a given feature is available everywhere, and make sure you’ve made a conscious decision about what content to put in which repository (DM or WCM) based on your requirements.


    Bex Huff: The Deep, Dark, Secret Origin Of Oracle UCM's Security Mode

    Filed under: General, Oracle UCM, Performance, Security — Tags: , , — Anthony Fast @ 11:15 pm


    The Deep, Dark, Secret Origin Of Oracle UCM’s Security Model

    September 4, 2009 – 9:54am — bex

    On a recent blog post about Oracle UCM — Should Oracle Be On Your Web Content Management Short List? — CMS Watch analyst Kas Thomas commented that he thought Oracle’s security model was a bit spooky. He admitted that this may be because he didn’t know enough about it: his concern stemmed from an overly stern warning in Oracle’s documentation.

    Alan Baer from Oracle soothed his fears and said that the documentation needed a bit of work… The documentation mentioned that changing the security model might cause data loss, which is in no way true.It should say that changing the security model might cause the perception of data loss, when in fact the repository is perfectly fine… the problem is that when you make some kinds of changes to the security model, you’ll need to update the security settings of all your users so they can access their content.

    Nevertheless, I thought it might be a good idea to explain why Oracle UCM’s security model is how it is…

    Back in the mid 1990s when UCM was first designed, it had a very basic security model. It was the first web-based content management system, so we were initially happy just to get stuff online! But immediately after that first milestone, the team had to make a tough decision on how to design the security model. We needed to get it right, because we would probably be stuck with it for a long time.

    1. Should it be a clone of other content management systems, which had access-control lists?
    2. Should it be a clone of the unix file permissions, with directory and file based ownership?
    3. Or, should it be something completely different?

    As with many things, the dev team went with door number 3…

    Unix file permissions were simply not flexible enough to manage documents that were “owned” by multiple people and teams. The directory model was compelling, but we needed something more.

    Access Control Lists (ACLs) are certainly powerful and flexible, because you store who (Bob, Joe) gets what rights (read, delete) to which documents. The ACLs are set by the content contributors when they submit content. However, ACLs are horribly slow and impossible to administer. For example, I as an administrator have very little control over how you as a user set up your access control lists. Let’s say some kinds of content are so important that I want Bob to always have access, but Joe never gets access. If Bob gets to set the ACLs on check-in, then there’s a risk he gives Joe access. It’s tough to solve this problem in any real way without a bazillion rules and exceptions that are impossible to maintain or audit.

    Instead, the team decided to design their security model with seven primary parts:

    • SECURITY GROUPS are like a classification of a piece of content. Think: restricted, classified, secret, top secret, etc. As Jay mentioned in the comments, these are groups of content items, and not groups of users.
    • ACCOUNTS are like the directory location of where a content item resides in a security hierarchy. Think: HR, R&D, London offices, London HR, etc. These are typically department-oriented, but its also easy to make cross-departmental task-specific accounts for special projects.
    • DOCUMENTS are required to have one and only one security group. Accounts are optional. This information is stored with the metadata of the document (title, author, creation date, etc.) in the database.
    • PERMISSIONS are rules about what kind of access is available to a document. You could have read-access-to-Top-Secret-documents, or delete-access-to-HR-documents. If the document is in an account, then the user’s access is the union of account and group permissions. For example, if you only had read access to the Top Secret group, and read access to HR, you’d be able to read Top-Secret-HR content. However, you would not see Top-Secret-R&D content.
    • ROLES are collections of security group permissions, so that they are easier to administer. For example, acontributor role would probably have read and write access to certain kinds of documents, whereas theadmin role would have total control over all documents. Change the role, and you change the rights of all users with that role.
    • USERS are given roles, which grants them different kinds of access to different kinds of documents. They can also be granted account access.
    • SERVICES are defined with a hard-coded access level. So a “search” service would require “read” access to a document, otherwise it won’t be displayed to the user. A “contribution” service would require that the user have “write” access to the specific group and account, otherwise you will get an access denied error.

    This kind of security model has many advantages… firstly, it is easy to maintain. Just give a user a collection of roles, and say what department they are in, and then they should have access to all the content needed to do their job. It works very well with how LDAP and Active Directory grant “permissions” to users. That’s why it is usually a minimal amount of effort to integrate Oracle UCM with existing identity management solutions.

    Secondly, this model scales very well. It is very, very fast to determine if a user has rights to perform a specific action, even if you need to do a security check on thousands of content items. For example, when somebody searches for “documents with ‘foo’ in the title,” all the content server needs to do is append a security clause to the query. For a “guest” user, the query becomes “documents with ‘foo’ in the title AND in the security group ‘Public’.” Simple, scalable, and fast.

    There are, of course, dozens of ways to enhance this model with add-on components… The optional “Collaboration Server” add-on includes ACLs, along with the obligatory documentation on how ACLs don’t scale as well as the standard security model… The optional “Need To Know” component opens up the security a bit to let people to see some parts of a content item, but not all. For example, they could see the title and date of the “Hydrogen Bomb Blueprints” document, but they would not be able to download the document. The “Records Management” component adds a whole bunch of new permissions, such a “create record” and “freeze record.” I’ve written some even weirder customizations before… they aren’t much effort, and are very solid.

    I asked Sam White if he could do it all over again, would he do it the same? For the most part, he said yes.Although he’d probably change the terminology a bit — “classification” instead of “role,” “directory” instead of “account.” In other words, he’d make it follow the LDAP terminology and conventions as closely as possible… so it would be even easier to administer.

    I do think it is a testament to the skills of the UCM team that the security model so closely mirrors how LDAP security is organized… considering LDAP was designed over many years by an international team of highly experienced security nerds. I’m also happy when it gets the “thumbs-up” from very smart, very paranoid, federal government agencies…


    SWOT analysis on Oracle UCM by the University of Minnesota


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

    UMContent (Oracle UCM) Pilot
    Implementation SWOT Analysis


    • 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.


    • 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.


    • 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.


    • 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.

    Create a free website or blog at