Last weekend at SAP Inside Track NL in EindhovenSAP Mentor Gregor Wolf and I discussed aspects of normative and non-normative documentation. We both agreed that a SAP System is a treasure chest containing many frameworks that are most important for developing business applications on top of SAP Business Suite. The reason is very simple: am NetWeaver AS ABAP isn’t just n very stable and robust application server, it is a platform for business programming.
I already blogged several times about the value of these frameworks because they are tremendously important for customers, partners and for the “SAP” brand, too. If you don’t know what I’m talking I recommend the following blogs: Reuse Tools – the Treasure Chest of ABAP Systems and Reuse Tools as Part of SAP Branding and Value Chain in SAP Ecosystem. And some of those frameworks are so useful or interesting so that I start to blog about them: Operations Research & ABAP and Forward Error Handling – A short look at SAP Business Suite Ehp 4.
What’s the problem?
It seems to me that SAP puts the focus on some frameworks with huge strategic value like Business Workflow, SOA Frameworks like Error and Conflict Handler and Idempotency Framework, BRFplus, Adobe Interactive Forms and so on. They are tremendously important and you’ll find much documentation.
In fact there are much more frameworks which have no official documentation or documentation only for end users but not for developers who want to use the framework in their own applications. I give you some examples:
- Parallelization Framework – this is most important if you have to deal with mass data
- Generic Error Handling – nearly every business application needs a framework for manual and automatic error processes
- Correspondence Tool for output management processes
I guess that the reason is simple that there is no legal documentation for developers: Creation takes time and money. On the other hand SAP has to prioritize in which order the documentation gets created and published.
Working for an ISV I know that there is a lot of internal documentation in wikis, Office documents and so on. Usually we can’t publish it for many reasons:
- The quality is poor compared to documentation made by professional documentation developers.
- It uses terms that are internally known but not to the community. Sometimes it contains code examples and screenshots that are not up to date.
- It was written by people who created and maintained a tool and so it covers most advanced but not basic topics.
- Sometime it contains names of developers we don’t want to publish because there are defined support processes & support organizations.
The Solution is simple: Let the Community help SAP
But it getting a somewhat “clean” version of an internal document is easily done. The hardest work is to get the documentation in a state that it is understandable for people who have no or only a basic understanding is a time consuming task.
But here the community can help: SAP gives the internal documentation to a group of experts from the community and they are doing the work. When it has a good quality these documents are published on SDN as non-normative documentation.
I think this is the road to success:
- Because the documentation comes from internal documentation the quality will be very high.
- The whole ecosystem (customers, partner and even people from SAP) can learn from those documents.
- We can keep the documentation easily up to date.
And this is what I suggest:
- Product Owners from SAP should do their best to have a concise & complete documentation.
- If the documentation can’t be published in time they should give a suitable set of internal documents to the community for community driven improvement of the documentation.
Even if there’s a good legal documentation it can make sense to give documents for expert users to the community because this documentation will never be published on SAP Library because it goes too much into detail.