Eight Months in Product Support at SAP

SAP was founded in 1972 by ex-IBM engineers with the purpose of creating “real-time” business software. It is a multi-national corporation with offices in over 100 countries, with headquarters in Waldorf, Germany. They specialize in enterprise software that is used to manage business operations and customer relations. Over the years SAP has grown to be one of the largest software companies in the world. Since 2001 SAP has grown dramatically through some high profile acquisitions that has expanded its profile dramatically, one of which was the buying of Sybase in 2010. SAP’s clients span many different industry and range from massive to small in size.

An Office in Transition

While my co-op term was technically with SAP I was working at an office in transition; one of the Sybase offices that SAP acquired in 2010. My term took place at an old Sybase office, just outside of the University of Waterloo. Though Sybase was acquired in 2010 it remained a separate entity until the start of 2013 when integration in SAP began. This means that while working in support we were using two different systems for everything; one for old Sybase processes and one for the new SAP processes. It was an interesting dynamic watching as what we were tasked with doing changed over my eight months.

Working for a Large Company

This was my first experience working in any technology company and the size of SAP only made it more interesting. I will hopefully have experience working at a smaller compnay in the future so that I can compare and contrast the experiences. For now though I’ll try to outline some good things and bad things that I found while working at SAP.

There were a good number of things that I found to be very positive about working at such a large company. Firstly, the sheer amount of resources available to me in support was astounding. If need be I could very easily replicate a customer’s environment with nearly every modern operating system available through the use of virtualization software. This allowed me to setup complex environments with multiple machines, and operating systems as fast as the operating system(s) could be installed. This ability was very helpful when it came to solving customer issues and many hours were saved just with this one facility. Another benefit was that every support case was logged, meaning that usually there was already an answer to a case, saving even more time. I don’t believe a younger, smaller company would have such extensive records, let alone a search engine that could effectively return relevant results for even the most esoteric problem. Naturally this database of cases was an indespensible tool for everyone in support. Finally the ability to pass high priority cases around the world (referred to as following the sun internally), allowing customers to get round-the-clock support is something that is only possible in larger companies with offices all over the world. The fact that we could offer this to our customers was an amazing feature of our support contracts and allowed for some truly great customer service.

Of course nothing is perfect and there were some drawbacks to working at such a large company. First and foremost the sheer amount of documentation and information that was needed to do my job felt almost insurmountable when I started. There were three weeks of training at the beginning of my first term and so much information was given out in those first few weeks that there was no way I could’ve remembered everything. This also meant that when it came time to start picking up cases you had to kind of go in blind. I like to learn using trial by fire so I didn’t mind it that much but it was a daunting experience nonetheless. Another drawback for me was the segregation of information between different departments, there were times where information I needed wasn’t available to me and I would have to wait for someone with that information to respond to question(s). This could be frustrating at times not just for me but for customers that were waiting on this information too. I feel like at a smaller company this segregation wouldn’t be as bad or even a problem at all.

Products

During my time in support I worked with two different database products SQL Anywhere and Advantage Database Server. Both products have very storied histories, each having been released in the early nineties. Though both are databases the two products were very different from each other and each presented their own challenges and advantages.

SQL Anywhere

SQL Anywhere is a Relational Database Management System that can be run on many different platforms. There are many different components to the application platfrom, some so large that I didn’t even support them. The components that I supported were:

  • SQL Anywhere Server — The main component of SQL Anywhere, the multi-platform server that runs on nearly any modern desktop/server operating system
  • UltraLite — A small footprint version of SQL Anywhere designed to be embedded in applications on low resource devices such as mobile phones
  • SQL Remote — A synchronization system designed for occansionally syncing users that uses a send-receive message transfer technology
  • MobiLink — A scalable, session-based server that facilitates synchronization between a consolidated, central store and remote clients. The MobiLink server has the ability to work independtly, without a SQL Anywhere database as it supports many different relational databases.

SQL Anywhere as a whole was designed for embedded application stores and mobile applications, because of this it is designed for high performance and scalability in an environment with thousands of users in a server environment to zero-administration, embedded environments. Supporting SQL Anywhere was an overall enjoyable experience, the documentation was very thorough and since it has been deployed in many different configurations there is plenty of past cases detailing potential problems. Another advantage to the product was that since it was designed to work in a zero-administration environment it is relatively simple at its core and then progressively gets more complicated as the environment around it becomes more complex. While SQL Anywhere can be very complex, it was well designed and in the end was a pleasurable experience to support.

Advantage Database Server

Advantage Database Server is a Relational Database Management System that is built with legacy, client/server applications in mind. Advantage began as a solution for Clipper developers that promised higher performance and increased stability over the alternatives available at the time. These days Advantage is employed in small to medium sized applications in a client/server environment or as a local application store. Advantage is normally used for legacy applications because of its support for other older file formats like Visual FoxPro and DBF tables along with its own proprietary file format.

Supporting Advantage was certainly more of a challenge than SQL Anywhere. This was mainly due to the legacy environments that Advantage is encountered in. More than once I was supporting DOS based systems, in 2013! This meant that usually I was looking at questionable documentation for older systems and trying to figure out how to deal with systems that I have no experience with. Though it was harder it was just as rewarding as working on SQL Anywhere.

Cases, Cases and More Cases

Working in support is a challenging job because the cases never stop coming. You have to learn to not only solve cases quickly but to handle working multiple cases in a day, context switching between different problems. Past the actual technical problems, this context switching is probably the most difficult part of the job, you have to be able to completely switch focus on problems if a customer calls you with new information on their case. The other difficulty with support is constantly managing the priority of different cases; if someone is down in production and none of users can use their system you need to be able to set other cases aside temporarily. The only problem is that you can’t simply let other cases fall by the wayside, you need to actually work on those too, balancing your time between the high priority case and all your other cases. Finally, in support you cannot stop new cases from coming in, this means that you have to properly manage your time whether you have five cases or twenty. Overall, support is not just about technical knowledge and the ability to solve cases quickly, but the ability to manage your time properly so that no cases are neglected.

Other than working cases, co-ops in support at Waterloo have another responsibility, the co-op side project. The project is entirely self-directed; the co-ops decide what they want to do and how they’re going to do it, the only condition being that the products we support are used in some way. It is a proof-of-concept application so at the end of the term it doesn’t have to be production ready but we must present what we have to a group of colleagues, developers and anyone else that wants to come to the presentation. Overall both projects were great learning experiences and they taught me a lot.

Summer 2013: SAP Hotels

The first project I was a part of was the SAP Hotels application. Basically this was a hotel booking application; users could go on the mobile or web app and book hotel rooms. A SQL Anywhere database managed all the info and a MobiLink server synced the data to the mobile and web applications. Aside from helping to design the overall architecture of the application my main role was desgining and writing the Android application that customers would use to book rooms at the hotel, they would also have the ability to cancel existing reservations. This was my first time writing a mobile application and I learned a lot about mobile design and Android development.

The mobile application used an UltraLite database as the application store, this database synced with the MobiLink server, with each mobile device getting their own copy of the database (the whole database was not synced, only data pertaining to that user). Thankfully because SQL Anywhere is pretty much plug-and-play, setting up the syncing was one of the easier things I had to do for the app. I would say the hardest thing I had to do was properly laying out the different screens and the UI contained within. When you design a web page or a desktop application you usually only need a couple different screens since you can fit many different UI elements on the screen. With mobile you have no such luxury and need to carefully plan out the functions of each screen as well as the ‘flow’ of moving between different screens. This planning ensures that the user is not overloaded with functions on one screen but navigating between screens is fluid and makes sense. While it won’t compile you can find the code for this project on Github.

Fall 2013: SAP Sales

The next project we did was a sales platform. A hypothetical company would buy the platform and then put their products into the database, once that was done they’d have an online precesence to sell their products with. The app came in multiple parts; the SQL Anywhere database, the MobiLink setup, the mobile application used by sales people that synced with MobiLink, a desktop application used by managers to manage the platform and a website used by customers that created sales requests. My responsibility was the web app, which I wrote in Go. I chose to write it in Go because I had been playing around with the language and wanted to learn more about it. To help increase the speed of the development I used the Revel Web Framework to write it.

Unfortunately this project did not go as smoothly as the first one. The fall term was much busier in terms of case load than the summer term was. This meant that there was not as much time to devote to the side project, since cases always took priority. I had never done any web development before and that coupled with the very limited amount of time I had to work on it meant that I, unfortunately, did not get everything done for this term. I was able to setup all the basic pages and render some information from the database into the page, as well as create users and login as existings users. Overall while the project taught me a lot about backend web development and strengthened my frontend skills the real lesson was in time management. We, as a team, should’ve seen how busy the term was starting to become and scaled back our requirements to better fit the time frame that we had. This term’s project was an ambitious one in terms of features and we should have realized that we had to remove features in order to put more polish on the features that we needed.

Reflections

I learned so much from this co-op term, not only about professional, highly technical customer service but about development, time management, and responsibility. The biggest thing that stuck with me though, is that my heart is in development. I loved helping people solve their problems and the challenge of troubleshooting their problems, but support is not where I want to be for the rest of my life. I’m thankful that this job showed me how much I enjoy development and that I’m making the right decisions for my schooling. Don’t get me wrong though, the job is really great and I would recommend this co-op placement to any student that is interested in solving tough problems. Most importantly though the people are great, even though we were working in a massive company, with tens of thousands of employees, the support team in Waterloo was small, tight-knit and generally awesome.

I’d really like to thank everyone I worked with but especially Scott McCurdie and Connie Stevens for giving a student with no work experience in the software industry his first shot. I’d also like to thank Jeff Albion and Nick Elson for being so helpful with my tougher cases and being always willing to answer my technical questions. And of course everyone else on the support team that was so welcoming and helpful to me and the other co-ops, it can’t be easy dealing with new people that don’t know what’s going on every four months. It was a great two terms at SAP and while I don’t think I’d return to support I will definitely remember my great time there.


Originally published at jhorvat.github.io on January 1, 2014.

Show your support

Clapping shows how much you appreciated Julian Horvat’s story.