Skip to Content
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..
To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    Why not we use the ABAP Webdynpro and Workflow abilities of XI to achieve that which are inherent abilities?

    We can exploit both the ABAP stack and Java Stack in SAP XI to do the same instead of using portal based deployment or mercury which might involve additional licensing cost.

    1. Former Member Post author

      Product evaluation for CMDB implementation is still under consideration.The customer already has a enterprise license for Mercury used by a few subsidiaries which could be extended to entire ITIL exercise.Developing ABAP webdynpros was not favored because the IS team which would be using and managing the solution didnt have competency on ABAP stack and more of a Java/open standards shop..Some open source webservers are also under evaluation..

      1. Former Member
        The hitch here is cost occurred for extending the license Vs having ABAP resources cost has to be then evaluated.Is getting an ABAP resource not cheaper?

        Iam sure you know better.

        1. Former Member Post author

          Quite a valid point.There were quite a few  other aspects considered for this choice..some can be mentioned here while some remain proprietary to the org..We considered
          – The availability of resources inhouse to manage CMDB.Their experience managing existing enterprise middleware and familiarity to CM processes played a big role.
          – Availability of Java pgmmers(cost) to build the solution.Chk mktprices in a outsourced model – Good Java pgmmers are available in the market but not ABAP these days..You should know that.. ๐Ÿ™‚
          – Fitment of product to standard ITIL processes.
          – Enterprise license didn’t involve additional cost to them..They already were using it.
          – Extensibility of CMDB to other Change mgmt processes for the core enterprise Middleware in the orgn.Note that SAP XI was considered only from SAP integration aspects and restricted to 35% of total infrastructure remaining predominantly being custom/BoB’s with no immediate phase out strategies.


Leave a Reply