How to convince your Manager/VP/CIO that scripting is useful
With the emergence of the “Scripting Community,” here on SDN you might find yourself asking, “How can I actually get to use of this stuff on my company’s systems?” In this blog I will attempt to give you some talking points to use in this discussion. I will break this down into two major areas; the first is an argument for people who have a very diverse landscape, many systems doing many different things. The second section is devoted to companies that are more SAP centric where most, if not all, of their systems run SAP and very few non-SAP systems exist. Certainly, both may apply to you, feel free to pick and choose based on your target.
The first person that scripting will help in this area is your system admin who is just trying to come up with a way of managing 80 systems that all speak different languages. It’s like the UN in their data center, just without the little white ear thingies that translate Nafaanra to English. Using scripting languages a developer could write code once and run it on all the systems that exist in their landscape. If someone decides to switch from MS platform to another OS, no need to re-write your scripts! Could this be done in Java, yes but it might be quite back breaking using JNI to do OS level tasks, with Ruby and Python that has already been done for you, the OS is abstracted so you need not worry about the details of what OS the script is running on.
Additionally, thanks to Piers Harding, you can even connect to SAP systems via RFCs. So your script could be running on a Linux machine connect to a SAP server take some statistics, clean up some files on the OS and then update some information in the database of your choice and the whole thing would be totally portable.
The two groups of people to benefit the most from using scripting languages in a company that uses almost entirely SAP products are the end users and the developers. The reason these two opposite ends of the spectrum are getting the benefit is simple, the developers get a new richer toolkit, and the end-users get a more attractive richer end user experience. A great example of this is Piers’ last Ruby on Rails with AJAX which would be very hard using just BSPs. ( I am not getting implementation specifics as this is meant for your Manager/VP/CIO and trust s/he doesn’t care. ) Just looking in terms of pure SLOC you can see how much work the Rails framework saves you. Now instead of spending all your time trying to make BSPs look nice you can start with a toolkit that allows you to build more desktop-like UIs.
With these two groups being helped by using something like Rails we can deliver value on both ends of the process, faster prototyping and building and more acceptance from the user community of what your developers create. Lowering the cost of custom development and increasing user acceptance something most SAP IT shops struggle with. Granted, using Rails the end destination is a remote function module, so you are still limited to the extent of the RFCs allowable in SAP, for now.
Finally and probably most importantly is that although SAP will never support these programming languages they certainly condone their use. They are very interested in increasing the user base around the scripting languages. I imagine, the usage of SAP by open source developers and by developers who don’t want to use regular Java, ABAP or VC++ could only help them in the long run. So, although the scripting connectors aren’t truly supported the more people who start to use and understand them, just as happened with Linux and Apache, create a whole community of people willing to help and support the ongoing development and support. Keep in mind, SDN members ~250k — employees at SAP ~ 30k.
I hope this helps you convince your higher-ups that scripting is important and can be very useful to your organization. The more people that get to work on this and make it “enterprise ready” the larger the community will grow and as the community grows we will be able to create more and build newer even more useful systems.