One lesson I’ve learned in building CMDBs is to cleanly separate the UI from the web service API. In the Java world, for example, this means that the API should be its own package (e.g., WAR file). The UI should be separate, whether that’s a separate WAR, a rich client (Flex, JavaFX, etc.), GWT app, or whatever. Various configuration and release management tools (e.g., uDeploy, DeployIt, Chef) work in this fashion, and with good reason. Here are some advantages of the approach.
Keeps everything automatable. This is by far the most important benefit. Ultimately you’re establishing a CMDB because you want to integrate and automate, so the data needs to be readily accessible to automation. If you treat the UI as just another client of a web service API, then you have an architecture that forces you to implement everything as a service, with the result that you can automate anything that the UI can do. And it will also force you to establish a proper discipline around defining and evolving the API, which is critical to your effort’s overall success.
Makes the API more robust. The CMDB’s API is the heart and soul of your devops platform, and cleaving away the UI makes the API more robust. Somebody won’t accidentally break the API while making a change to the UI.
Allows the UI and API to scale independently. In the early days it may be that most of what you do with your CMDB is user-driven, but the goal over time is once again to automate your environment. Eventually you should expect that your API will get lots of traffic because you have automation making all kinds of requests (reads and writes) against it, and the UI will receive significantly less use. It’s useful to be able to scale those independently since they have different expected load patterns.
Facilitates testing. In some cases it may be easier to test your API if the UI is separate. You don’t have to worry about interactions with UI components, UI configuration and the like.