One of my last engagements has an unusual reporting system. The customer drives its own system which tracks travel and time expenses. Every contractor to get paid ought to fill her hours and her travel expenses into this system. At the end of every week you open one transaction for filling hours you worked for the customer and another transaction for putting travel expenses. The customer has, of course, his own policy for reporting travel expenses. You put a predefined per-deem article for every day you spent in the office. No need to dive to deep into details what is hotel price, car rent, and daily internet – just the predefined sum of money for every day you were there. Cool! No headache. Thats ok. No surprise yet.
Another system in place where every contractor has to record its time is a project-based task tracking system. Here each project member has to record his day-to-day project activities. Now each team member has to report it regardless of who her employer is whether she works for the customer or is a contractor just report it! So we got transaction number three. If the first system (about travel expenses and contractors cost) is to govern cost of contractors then the second one is to see what every project task has been cost so far. The systems probably are of interest of different groups of project management. Definitely they represent different data. Undoubtedly they dont double each other and almost dont overlap.
If you work for SAP then you have to report your time and travel expenses in real transactions (no quotation marks) CATSXT and PR05 accordingly. Do you see already the point? A slight feeling of redundant data? Yeah, youre right! Weve reported this already, at least big part of it in the customers transactions. We dont report exactly the same data as we provided for the customer though – now its another level of granularity. SAP wants to know about every days hotel, ration, rental car, fuel and so on. But the data we put into the customers system ensues from the data we put to PR05. If we have our CATSXT and PR05 completed we can populate the customers expenses reports with an accuracy of 100%.
Now it became quite painful. Every week I worked for this customer I had to complete 5 forms and then to email my e-tickets confirmations to the customer. It took good half an hour to do it and verify everything is committed correctly.
Im sure at that moment you understand why I put the ESA into the blogs name. Its an obvious ESA scenario for all 5 systems that can interact to the benefit of their users. Let me clarify.
Im not saying that even one of the systems should be eliminated for the sake of the cool modern architecture. All of them can remain there. Each of them has its own target, own outlook, own application, and own users. Im just saying that if these systems were developed as services or, rather, if corresponding services were in place to communicate with the systems then it would be possible to move the burden of boring and error prone processes of double entry project related data from users to the services. Im only talking about a technical aspect of the scenario. Even the technical one has many questions yet to get answered. Messages have to be translated, intelligently mapped (probably split and later merged), these services have to be properly orchestrated, a collision-resolving system has to be implemented, most likely some monitoring transactions could be added, and presumably there are much more self-communicating transactions than the five I ran across. All these questions are up to the ESA. They naturally belong to the ESA world and the ESA has answers for all of them.
Just a few words about a business aspect of the integration. Following to the modern fashion to name books and articles using words like dummies or idiots, I had a stupid temptation to name this blog ESA for morons. But then a question about the relevancy of the ESA in this case arose. What is the return of investments here? How much would it cost to build this integration (for two companies) and what are the benefits of it (for the two companies)? I was told by other SAP consultants with a decade of SAP experience that such double entry is rather an exception. So maybe it doesnt make business sense to do it, I dont really know. But technically speaking it is enough pragmatic during system design and planning to think that the systems may be accessed and consumed not only from its primary UI but by some inanimate service. If this approach is one of the underlying principles of the architecture from the very beginning of system design then any future integration becomes much easier, much cheaper, and ultimately more appealing for implementation.
P.S Despite such triple-work this customer is one of the best Ive ever had occasion to work with:-)