I had an oppurtunity to take part in an Architecture study exercise for a huge firm looking to deploy a comprehensive SAP XI deployment environment involving multiple XI production landscapes catering to SAP integration requirements of its subsidiaries. Servers were to be located Geographically(America, Asia and MidEast-Europe) to address the unique business requirements of each region. The sizing,failover and clustering requirements and options were also studied considering the operational demands of the businesses in each region. Some of the recommendations revolved around the Development-to-Deployment strategies to be considered in such a large scale enviroment with multiple SAP development servers(could be 10’s if not 100’s) to be used by local companies over which the Central integration services team had no control.At any time the landscape had to be resilient enough to manage multiple active deployments. One of the unique problems we faced was in deciding the overall deployment governance model between multiple teams – The Local BASIS teams, Local SAP XI Project teams, the Central Deployment Team(to manage the transports and verification of deployments) and a Central BASIS team to administer and manage the SLD and Deployment servers in each region. The complexity grows much larger when the deployments criss-cross regions wherein the local projects deploy on a cross regional SAP XI server for messaging requirements. This model rose among other reasons also due to lack of comprehensive/reliable native messaging ability between SAP XI servers.How we addressed these, may be I’ll cover some other time, lets focus now on the Change and transport aspects. The challenge was that the recommendations would have had to fit ITIL process framework from an adherence perspective particularly handling issues around Change and Release management. Technically we designed the transport mechanism between the IT-Preprod-Prod servers in each region to be structured CMS transport processes while the local development and deployments to production landscape would go by Manual transport owing to limitations with single CMS environment handling multiple Dev servers. From a process perspective the Challenges from change mgmt and release mgmt aspects emerged more from the interface blocks between Local Development team and Regional deployment team.After some fumbling around for a solution we evolved a integrated workflow that would document the deployment requests between the local team and regional team which could be implemented using a Web based portal deployment solution or a standard tool like Mercury. As of now this is not yet in place to share my learnings but one of the salient aspects to the design is a possibility to track and fix any issues arising out of manual transports mishaps between different landscapes(the .tpz mixup hazards). The workflow would also persist the information in a Change Management database to report on the activities, issues and timelines for task requests pushed to the regional deployment landscape.The process would also facilitate automatic intimation of deployment request to the regional deployment teams. As a leading SI increasingly partnering clients on their Enterprise SOA quest, we have observed that as larger organisations move towards Enterprise SOA , they also are seen trying to consolidate the EAI/ESB infrastructure in the landscape.Few firms have adopted strategies that call for SAP XI coexistence with other pureplay middleware while a more SAP dependent business may choose to move to SAP XI for their Enterprise messaging with needs to ultimately reduce licensing costs and as a way to improve Vendor reliability. But ultimately the transition process needs a process framework to guide these activities. Such transitions are highly challenging and pitfalls uncharted, but that makes more sense to have a committed adoption of process frameworks aiding service deployments. As we see the technology maturing and more stable the number of technical blogs around tweaking XI have come down quite a bit but I think we could see this more as an oppurtunity for people to share experiences faced with client landscapes…And I dont need to state that no TWO clients have the same Problems in scale/size..