An Architect and Manager Perspective of Siebel OpenUI
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
- 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
- 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 v220.127.116.11 (well, that is not logical to say the least. If one trusts Oracle all fixes to OpenUI defects are in v18.104.22.168. 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
- 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.