Migration Minute

Mock 1: how to avoid another tragedy...

The Greeks knew how to do a tragedy. All you need is a good natured hero, an innocent victim and an impossible challenge. You know he will fail miserably. After many pathetically failed attempts to take the city of Troy, our hero Odysseus eventually resorts to elaborate trickery (in the form of a wooden horse) to bring in his soldiers. Destroying Troy however does not bring about lasting peace. Odysseus just walks away eventually. It takes him a full 10 years to finally return home, only to find that his wife doesn't recognize him anymore! What a tragic story...

To me this sounds awfully familiar (not the wife part). I have got one word for you: Mock-1. The hero? that is the Data Lead, who valiantly strides to get the data loaded in time for the Integration test. The hapless victim? Naturally, the wide eyed key user who will be faced with the sordid end result to use in his/her test cases. The impossible challenge? How can anyone provide data in the right quality given the fact that:

• The customizing needed for all the data objects has not been made available in the test client. Surprise, anyone?
• The source data is hopelessly out of shape and resists all previous assumptions. So far for data governance.
• The mapping rules have never been double checked by the functional teams to determine if these even fit their test cases. It's better to draw process diagrams anyway.
• The business have never had the full "SAP experience" and espouse sky high expectations, of course encouraged by a risk avoiding project management. Right....

So what happens? Faced with enormous pressure, the hero decides to go for plan B. This means compromising on time, scope an quality. He has no choice, there is no real plan B of course. Finally, after many long nights work the result is there: the integration test is on hold, there are 300 defects in SolMan and everyone knows the root cause: "the data is not good!". Well done! Thats how we do projects!

By the way, Mock-1 is the graveyard for Data Leads. Most firings happen during this time in the project. Then they bring in a new guy, a new hero. Perhaps an Ajax or a Paris, who knows. If you are unlucky, they hire Bozo the clown.

The redemption of Mock-1.

You can wait until the tragedy becomes a comedy. But it's better to get something else. A redemption story. Rather than fighting the symptoms, try to save your Mock-1, and thus save a lot of time and money.

• Most migrations focus too much on building tooling. It seems to always be the goal to move bits and bytes from one system to the next. Instead, take time to write decent Functional Designs and Mapping Designs. Use a robust and simple process to build and test tooling, but spend most energy on the functional data topics. Make it clear to the functional and business consultants that you need part of their time to work on data topics. Regarding tooling, the trend in the market is to use standard tooling like Migration Cockpit and ADM. Use the tools that are already part of the SAP stack instead of building your own. If you need something special, use the Rfc process to have a proper developer write a tool. Even better, fire an OSS note so SAP can help you. That's what they are there for.
• Use an Object Owner concept to clarify roles and responsibilities. For each object, define who (a person name! not a team!) in the functional team is responsible for the data migration. In the migration team, another Object Owner is agreed for the more technical side. Together with the Data Owner from the business, these three are responsible end-to-end for everything migratory. It's like replacing the exhausted hero with the three musketeers. Still not ideal, but better nevertheless.
• Build a realistic timeline instead of "date setting" (we are not the Millerites). Take enough time to execute the Mock-1 loads. Agree with the functional teams when the config is fully transported to your test client ("technical cutover"). Have some flexibility in the Integration test plan. Define a dataset in advance that will be part of the migration. Focus on clear data criteria that must be in place and manage business expectations on the rest.
• Finally, consider disconnecting the Mock-1 from the Integration test altogether. Be realistic about your data quality in the source, be realistic about the maturity of the solution at this point. Use Mock-1 to test the migration process only, and use separate test data for the Integration test. This may sound like defeat, but it is better to lose one battle and still win the war.

Redemption is never easy. That is because it takes faith and action, and integrity. Work on saving your Mock-1 from this day onward. It is possible.