Should you plan for future? Integration platforms and different architectural patterns - service oriented, event driven or enterprise service buses - get a lot of discussion all around the world. And of course a good architecture, its proper implementation and governance issues are the first priority. Without functioning line of business systems there's no need to worry about continuity or contingency planning. But once you have the mission critical systems  in place you should think about how to reduce risks and also plan what to do in case of emergency event.

Interconnected systems are getting more common within enterprises and more importantly more critical in day to day business environments. Quite often integration solution life cycle starts from rather small implementation and when it later evolves hopefully initially created architectural guides and frameworks are followed and updated accordingly. But as the scope and criticality of integration solution grows also the planning for beyond next project gets more important. Making sure that integration solution stays operational in the future is a part of organizations risk management.

First of course you'll need to know where you are. Overview about business processes and their technical execution path between systems is a good place to start. Depending how architecturally integration is implemented within the organization different aspects might be more crucial than others. If an integration solution is acting as business-to-business integration layer and handling all external connections from and to enterprise there might be financial pressure from contracts for maintaining certain service level. When thinking about enterprise  application integration scenarios where organizations line-of-business systems are communicating with each other first priority can be normal daily operations.

Question where you should find answer is: If a process flow between two systems is halted for some reason how long can you cope? For what level you should prepare beforehand and what kind of recovery plans are needed. After business impact analysis some decisions should be made. First should be decided the acceptable risk level - and then plan the preventive actions. Where are we now and what do we expect to happen within some timeframe into future. What is needed to execute to achieve required high availability, security or scalability issues. Reducing risks is quite simply about commitment, time, effort and money. 

After preventive steps there will still be risks no matter what you do. So there's also a need to plan for contingency. For what kind of emergency events we need to prepare and how to recover afterwards. The actual issues within the plan are a topic for another post. But to finish this one I'll underline the point that like overall architecture design continuity planning should be a living document which should be evaluated and updated regularly. Also I'd argue that if organization is not using any architectural guidance or integration frameworks - basically you're running an integration spaghetti - all the continuity planning, governance and management issues multiply.