integration tier change management

Intro

More systems connected and integrated into the application require a solid process and software support for

• managing frequent changes which limit impact on system users
• allow new users with new requests to join
• enable the system to integrate new funtionailty seamlessly
• have the user control access to the integrated backends without really knowing about them

Software Architecture thoughts

A tier-divided application with code versioning on that tier level supports the requirements above. Between tier communication must be one-way-depenend (if at all) and may not be mixed. For Integration Systems the connectors tier should be completly isolated and upper tiers aggregate information from them.

Connector tier user state information must be hidden from the clients.

Clients interface must include general system environment requirements (e.g. requesting information on a test or production level), which will be mapped by the integration and/or the connectors tier to the required backend systems. So the user can control his system environment semantically.

Client Business interfaces should be rock-solid right from the start. Business Methods or even Business Domains might be added, but should not require existing interfaces to change.

Keeping Business Interfaces in separate software versioning projects prevents unnecessary change of the business interface and client updates.

Deployment thoughts

Within an J2EE environment using EJBs, JNDI Naming enables to deploy different versions of code into the same container using different JDNI Names.

Names might be used to control version or system environments handeled.

Tools

none really found or written, yet