* We need a support of plugins (component, modules) to extend the platform based on different customer's needs

!!! Topics with highest relevance

(A) (automatic) adaptation to evolving APIs -- see [[Attach:schuzka-5.4.2011.jpg | notes from brainstorming]]
* generating adaptation and modification of third party-components (existing clients) to changes in our API
* what-if scenarios - which clients would I break with such-and-such API change?
* search a repository for a relevant API for an existing client
* metrics to assess API - stability, complexity
* process to support the above - how to assess API, how to evolve it, what to do after it evolved

(B) testing of components based on semi-real data
* monitoring (QoS) in customer environment, obtaining real usage data
* generating tests (mainly load, performance, reliability) with data based on those monitored
* testing in a simulated environment
* visualization of results and metrics and test results

!!! A previous list of possibly relevant topics (with relevance to IW needs):

???

** existing solutions

----

* (automatic) adaptation of components to (slightly) different APIs (medium)
** adaptation and modification of third party-components
** generating adapters for existing clients of our (changing) API
** what-if scenarios - which clients would I break with such-and-such API change?
** search a repo for a relevant API for an existing client
** metrics to assess API - stability, complexity

* the modules should be manageable according to a given customer as follows:
** enable/disable
** monitor
** charge out
** limit the resources

** authentication of messages
** role based authorization mechanism

** (vaclav sykora) I don't fully undestand the point

Visualization can be useful in following points mentioned above:

** an 'universal' bus, events, messaging, ...

* visualization of components (low)
** visualization of considerable wide set of components

** Custom metric visualization (including QoS)
** Exploring component dependencies
** Traceability analysis (including EFP)

** components customized based on customer needs.

** Tool for dependencies visualization and assembling
** Visual exploring of variation/extension points

** Automatic update hints (with/without visualization)

** Visualization of results and metrics and test results in diagram

* visualization can be useful in following points mentioned above:
** verification of components compatibility
** repository of components

Additional ideas:
** Internal component analysis
** Visual comparison of views
** Automatic finding components in code (or macro-components in components)

* analysis of platform-plugin-component structure/technology solution
* development, SCM and build support

** an 'universal' bus, events, messiging, ...
** monitoring of messages coming through
** filtering of messages
** authentication of messages

** verification of different version on components
** replacement of an old components by a new one.
** verification of compatibility of third-party components

** adaptation and modification of third party-components
** probably needless for our home-made components

** visualisation of considerable wide set of components
** monitoring of runtime state of components
** monitoring of customer installation

** product lines
** components customised based on customer needs.
** different edition for different prices

** updates of running systems
** seamless update without restart
** configuration on the fly

** building up the application from storage
** mining components based on configuration

** testing in development environment
** monitoring (QoS) in customer environment

* communication of components with each other and communication of components with the platform (high)

** important in a case we allow third-party components. Then we may want to adapt existing components to fit our API.

** useful for once we have wide sets of components. It include tooling for visualisation of stand-alone or running components.

** product lines - components may be customised based on customer needs. We may have 'free', 'silver' 'gold' edition of components for different prices

** important if we want to plug components to a running platform on the fly

* monitoring and testing of components (high)

!! Ideas of what could we do

Current state:
* We have a platform
* We need a support of plugins (component, modules) to extend the platform based on different customer's needs.

A list of possibly relevant topics (with relevance to IW needs):
* communication of components with with each other and communication of components with the platform (high)
** a unified way of communication
* verification of components compatibility (medium)
** if we had a lot of components in different versions we would need to check whether a change of a component affects a system
* (automatic) adaptation of components to (slightly) different APIs (medium)
** important in a case we allow a third-party components. Then we may want to adapt existing components
* visualisation of components (low)
** useful for a wide sets of components. It include tooling for visualisation of stand-alone or running components
* configuration of components based on customer needs (high)
** product lines - components may be customised based on customer needs.
* deployment of components to the running platform (low)
** important if we want to plug components to a running platform
* repository of components (medium)
** a unified storage
* monitoring ans testing of components (medium)