In our previous post, we explained the benefits of an N+1 landscape. The full article can be found here, but the main advantage is that an N+1 landscape gives you two full, separate DEV and QAS environments. It allows you to build long-term enhancements on one landscape while leaving your maintenance landscape free to tackle any maintenance work that pops up in the meantime. This is a great approach, but it can be tricky to make sure that the system in development will fulfill all the requirements being met by the system it’s intended to replace. In this post, we’ll explore a few ways you can address this issue, and help you pick the right one for your organization.
Before we dive into the solutions, we should clarify what the problem is. The new system you are designing in your enhancement landscape starts out as an identical copy of your production system, but that doesn’t last long. The long-term system soon bears little resemblance to the common ancestor, as you would expect. But as immediate business needs are addressed in the maintenance landscape, the production system also diverges.
The problem is that the future system has to fulfill all the needs the production system fulfills now, including the requirements that have been added after the fork. But SAP systems are full of complex interdependencies and because the two systems are very different, it’s not usually possible to just copy and paste. In other words, just because a chicken shares a common ancestor with an ostrich does not mean that they can be organ donors for each other. How do you get your long-term enhancement to incorporate the quick modifications and break-fixes that happened after the fork without having to build every new object from scratch?
SAP’s Solution Manager product includes two tools that are especially useful for reconciling different systems in an N+1 environment. The Change Request Manager, or ChaRM, is a powerful tool for managing the change control process. Once configured, ChaRM automates most of the compartmentalization, progress tracking, and alerts that were previously done by hand. It exists to replace the collection of spreadsheets and individual emails of traditional change-control. For example, when a change request is made, ChaRM automatically issues instructions to the appropriate people, and it tracks progress and status of all pending changes. ChaRM is especially useful in the N+1 context because it can identify and display all of a particular SAP object’s dependencies in a user-friendly manner. ChaRM is not specific to N+1 landscapes – it is useful in any type of landscape with ongoing change management.
Retrofit, on the other hand, exists specifically to make it easier to reconcile different systems on separate landscapes. Retrofit works by going through each object in one system and identify its counterpart in another system. Like ChaRM, it is also capable of identifying and displaying dependencies. Retrofit allows developers working on one object to lock that object’s counterpart until the work is completed so that the other system’s developers aren’t doing work that’s just going to be overwritten anyways. By comparing objects, Retrofit can also streamline the reconciliation process. In areas where the systems are radically different, Retrofit can’t help – they will have to be reconciled by hand. But if there are only minor differences, Retrofit will ask the developers to make the change with the Correction Workbench, rather than transporting it directly. The Correction Workbench displays the discrepancies side-by-side, which makes it much easier for the developer to review and synchronize the versions before committing to a change. And if Retrofit determines that a new object from one landscape won’t disrupt the other, it transports it automatically.
Each tool is useful on its own, so you can mix and match them into one of four different combinations. There’s no ‘best’ combination – each is the fastest and cheapest for certain types of organizations. We’ll go through the options, along with their relative strengths and weaknesses, to help you identify which combination you need.
The simplest option is to do both the change management and consolidation by hand. Dependencies are identified individually, and most team members have permission to make changes to any part of the system. While this ad hoc approach may seem amateurish, it is actually the best choice for many organizations. Remember, the reason that startups are so quick and responsive is because they don’t have a lot of rules governing their actions. It requires no additional expenses or training, and it is fast and flexible because proposed changes don’t have to pass through layers of bureaucracy. If most of your team is familiar with the whole system, if the IT system being worked on is simple and stable, or if you don’t have more than one management layer, other options won’t be worth their cost to implement.
The second option is to use traditional change management techniques, but to implement the actual changes with Retrofit. This option does require you to implement Retrofit and train team members to use it, but it offers several important advantages. Retrofit allows you to manage a larger volume of changes with a lower error rate than you would be able to accomplish doing the work by hand. It eliminates situations in which teams are working on objects that are already identical. Since it automatically identifies dependencies, it’s also very useful in situations where the team is geographically separated or can’t convene easily. Like the previous option, this is best suited for flat management structures and simple governance processes.
The third option is to use ChaRM, but not Retrofit. This is the least common of the four options because ChaRM requires a lot more configuration than Retrofit to be useful. ChaRM works by automating the tasks of your governance structure, so if you don’t have a robust and comprehensive governance structure already in place, ChaRM won’t do much for you. Even if your business does have such a structure, it’s far more difficult to configure ChaRM than it is to configure Retrofit, so it’s rare to find a business with the former but not the latter. The one case in which this pairing makes sense is if you have to have a heavily-regulated governance structure and a very low volume of maintenance change requests. If you aren’t making many changes to your production system, it’s not hard to reconcile your systems and Retrofit is just overkill.
The last option is to use both ChaRM and Retrofit. This combination requires the most work to set up, but it can handle structural complexity and change volumes that the other combinations can’t match. If you have an intricate IT system, a detailed governance structure, and a large team to manage, this is the best option for you. In the long run, you’ll move much faster and more accurately by using these two systems together.
TL;DR
If you have a big team and a lot of changes, use ChaRM and Retrofit. If you have lots regulatory requirements and a low volume of change requests, use ChaRM. If you have a small organization but a lot of work to do, use Retrofit. If your team and your task are small, do it by hand.
Originally posted at http://bigconcepts.com/2015/12/30/managing-changes-in-your-n1-landscape/
