A flexible configuration framework

I am currently designing a system which by default will be interacting with many software, hardware components, some supplied by various third parties. One of the common pitfall for system of this kind is people tend to ignore, or at least do not pay enough attention to, the challenge presented by the system configuration, formally referred as deployment.

I am not discussing configuration in the sense of setting system parameters, configure program environment as such. Dealing with a middle or large size of system, first thing I learnt is not to focus on each individual component (from design phase) and never make assumption how people would like to connect their cables (or setup their wireless links). System configuration has been mostly pushed to the front line and in many organisations it to a degree became a de-facto FAE (field application engineering) function. On one hand experienced FAE engineers becomes a rare race; on the other hand, many of them do not really have sufficient visibility of the system capability supplied and configured by themselves. Deployment of such system became a lengthy and painful process between the customer, distributor or integrator, and of course (engineers within) the organisation.

We have put a lot of thoughts in designing one of our new product, trying to find a most intuitive way for people to deploy the system. They only need to know what they want to know about what they are doing. The overall presentation of configuration UI for such system will be a Zoomable diagram. System needs to define and group certain entities at different layers. Join and leave group will be default supported functionalities for an individual entity at that level. Multicast could be enabled and disabled in the group. Entities within group could also be addressable. Each group is governed by group policy, which will be applied on top of the entity policy. Each entity has defined interfaces (communication interface, supported inter-entity communication channels). Entity is a logically self-sufficient unity and GUI is NOT an entity. All interfaces are configurable and expose the same configuration interface, of course with different property implementation. Similar to the /proc/ concept in Linux, each running entity will create a dynamic symbolic link, to which read and write could be enabled to dynamically change entity behavior and this will allow embedded script engine to be possible in the future as well. Wizard alike step by step system configuration is used to provide clear and un-ambiguous options at each level. The key point is the wizard will be triggered at each level with different content. Drag & drop toolbox will dynamically reflect the selectable and configurable entities could be contained by current Entity-of-focus. To integrate with third party devices, a generic wrapper interface is to be implemented for each of them. It could as as simple as to pass command and retrieve status; it could also be as complicated as to implement a functional agent to interfere the logic. At last, but definitely the least, the multi-level hierarchy will be serialised into XML file and could be reloaded and edit anytime in the future.