SAP and Distributed Development environment – two worlds – one challenge

Andrey Dekhtyar
CEO at Rozdoum

This year Rozdoum got a pretty unique opportunity to be involved in the project for Ministry of Defence of Ukraine related to automation of logistic processes. The underlying basis of the whole system was selected SAP ERP, where our team had to enable offline operations and processing on mobile devices. Usual use case of SAP’s ERP System implies Client Server architecture where remote workstations are connected to a central server on a permanent basis – on the contrary to usual scenario army declared necessity to work in the fields without any connection to the central system. The synchronization is expected to be executed on some postponed intervals. Local changes, reflecting offline work had to be synched at that time, as well as updates of new data.

Before this project, Rozdoum had close to nothing experience with SAP system as a whole and the same with approaches of teams that work in that environment. In this article, we would like to highlight some aspects that we faced during half a year project with different paradigms and ways of thinking.

A. Organization of development. Shared code vs individual ownership

Our 15 years of experience made us believe that a common practice in the teams, especially distributed team, is a usage of shared repository and unified style of the code base. This practice on one side blurs ownership of the code, at the same time raises responsibility of every person. On SAP side of development, we faced clear separation of special parts ownership of the code. In this behaviour one person is responsible for one functional module, so you always know whom to contact, at the same time – bus factor is equal to 1. There is no chance someone can easily pick up the code from our person and continue the development. Even more – no one even dares to do that, as no-one wants to step into other’s territory. The result is surprising and obvious at the same time – there is no common style of the code.

• Same input/output parameters to functions and modules are named completely differently

• Logging is implemented differently – with different messaging and level of details for similar things

• Error handling is different. It took us quite an effort to agree on shared format of error messages for different SAP developers – implementing different functionality – which we had to use on a mobile device and present to the end-user in one style and one format.

B. Table mindset vs Object Oriented Programming

It took long weeks to get used to the fact that our partners operated in “tables” – any data they could accept, manipulate, output as a result of module execution is A TABLE. Even a single numeric output of a functional module is a table with one column, one row and data field in that one cell. For us, who used to operate with data in sense of objects and methods as possible behaviour driven changes of these objects, it was quite unexpected at the beginning of the project. With the time we learned how to easily convert data and match that to our expectations.

C. Test environment and infrastructure

In every project which evolves with iterations, where complexity and functionality grows incrementally it is very important to presume the correctness of functionality. This especially concerns the functionality that worked once and then might have been affected by changes in other parts, i.e. retrospective testing. With SAP ERP there is no such thing as “rollback all the changes of the last day” – just impossible. Some of created documents do not have an option to be reverted. Some adjustments in modules live within environment they were created, etc. So the outcome, that we managed to setup after a while, was a reference system which was created, verified for consistency and duplicated every time we have to run a new set of tests with new functionality.

D. Bandwidth consumption

That’s one of the things you start to think about only if data size matters. For mobile devices and transmission of data in not stable network – it does matter. This is absolutely not the case when you have a fat SAP client, stable connection, and unlimited bandwidth. Obstacles that we found in this project are that it’s really hard to teach people to take care of things that didn’t use to. So basically the solution we have implemented was an intermediate Mobile App server between SAP and all the mobile clients of the system. This intermediate server collected all necessary data, stripped out the necessary data and ensured communication with mobile devices.

As an outcome of this project – we made a conclusion that both sides learned quite a lot from the other party. We brought the understanding of what is the value a team work to SAP guys, and how to organize incremental development with proper testing. What we gained from them – are complexity and scale of big corporate systems. I believe it was beneficial for both worlds and we all are looking forward to a launch of the project that should bring value to Ukrainian soldiers.