Skip to main content
  1. Posts/

An Architect and Manager Perspective of Siebel OpenUI

·4 mins

Siebel OpenUI has taken the Siebel world by storm. Arguably the single biggest announcement since Siebel 8.0 in Y2007 in this part of the world, the technology looks exciting and is a big boost to extend the aging product. OpenUI is also a big shift for Siebel IT managers/architects/developers. As in any change, this needs some shifts and realignment of development and implementation strategy.

Planning the Project #

  • Include the cost of OpenUI, no one wants traditional Siebel UI anymore. Include this in your cost and sell the solution, this really is a big deal
  • Set expectations on the customization on the UI layer. OpenUI is not a new product, it still is Siebel. Do not over promise based on PoCs or that shining new javascript module/framework that appears to do magic along with OpenUI
  • Estimate for the project effort by taking inputs from javascript and CSS resources. Plan for the technology resources as well, the best of Siebel guys may take up to 2-3 months to learn and get started on advanced customization without prior exposure to javascript frameworks. Get help from usability experts for major UI changes, clearly defined wireframes are pretty much a standard for web development
  • Plan for PoCs and try to align scope based on the PoC feedback and lessons learnt
  • Create and track risks about OpenUI implementation
    • Business expectation risks: Start small and enhance later. Do not show an advanced order capture screen only to revert to the Siebel list and form later.
    • Technology risks: OpenUI is two minor-version old (as of May, 2013) and WILL have problems. Problems as of today may go away with the next version as always, but it might make or break your project in the meantime
  • Set parameters and boundaries for testing, deployment and support. OpenUI may support all browsers and devices, but will your application do that? Can your team test each of the browser/OS/device combinations?
  • Change your load test strategy. Bring in a perspective to include load on the client as well. Use typical client configurations to watch OpenUI in action
  • Plan for some extensive involvement of business SMEs if you are deploying a lot of usability changes
  • Plan for hardware changes if the existing setup will barely support the application. OpenUI is another OM
  • Plan for client infrastructure changes if your users still hang around IE 6 or IE 8
  • Finally, account for the costs of any new development tools needed by your javascript/CSS team

Design #

  • Proof of Concept (PoC) is your friend, but expect problems in the actual development. Do not ignore PoC, do not over-promise based on PoC results. Capture learning for later.
  • Design with extensibility and support in mind. Customization and extension to PM/PR layers for applets is not yet supported for other entities. Do not plan to replace the presentation layer until v8.1.1.12 (well, that is not logical to say the least. If one trusts Oracle all fixes to OpenUI defects are in v8.1.1.11. The next version if of course one step higher in usability heaven)
  • Any large scale changes to the UI has to be certified by usability experts. Review everything - even UI colour changes, fonts, button shapes et. al. if you are going to change those. OpenUI follows (or tries to follow) Oracle UX . Make use of their expertise, rather than reinventing the wheel
  • Evaluate mobile and offline requirements carefully. The product direction for those features is interesting, but that is a future that you don’t control

Develop #

  • Development plan has to call out Javascript and CSS development. Plan to roll this out first and fine tune during the course of development
  • Unit test in the browser that will be extensively used by the users. If the budget allows for it, identify critical functionalities and execute unit test cases in other browsers too

If you have stayed here so far, you might make the obvious observation that planning is covered here in more detail. Development and deployment will get updated here or in later posts as we gain more experience (and hopefully expertise) in the next few months.