HP OpenView is the industry-leading product family for network, system, application and service management software for large distributed enterprise IT environments, with products like Network Node Manager, OpenView Operations and OpenView ServiceDesk. HP joined forces with SAP, the largest enterprise software vendor (in 2006), for IT Service and Application management. This activity had the objective to improve the service centric management of SAP-centric environments in order to reduce Total Cost of Ownership (TCO), improve quality of service delivery, reduce risk of service delivery, reduce complexity and ensure agility of SAP-centric IT environments.
HP OpenView ITSM Software Development Engineer
Jun-2005 - May 2008
Designed Incident Exchange protocol with SAP and implemented SOAP-based connector to HP Service Desk and then Service Manager.
Starting in 2004, our team (due to its background in SAP management) investigated a couple of approaches to service management of SAP environments, e.g. using a Configuration Management Database, exchanging helpdesk messages and synchronizing configuration information. From June to December 2005, we worked together with SAP to jointly design a web service interface for the exchange of helpdesk incidents, and implemented a prototype which was able to exchange incidents between SAP Solution Manager 4.0 Service Desk and HP OpenView ServiceDesk 4.5. I participated in the review and specification of the web service's operations and semantics and its underlying use cases.
The interface became available through the SAP ramp-up program in early 2006; at the same time, HP announced the new Incident Exchange service through its consulting and integration organization. Implementation continued through the summer. In September, the German iX magazine for professional IT ran a brief note on the general availability of the Incident Exchange.
The HP Integrated Incident Management Service is a service offering by HP which combines the Incident Exchange product with consulting.
Initially, I had to divide my time between this project and the ongoing transition and shadow support period of our former product. My main source code contribution to the project was the refinement of shared components for tracing, logging and configuration handling (which fit my expertise well) and the implementation of a support tool that checked the complex configuration and basic health of the deployed product. Because this was my first use of Java in a professional context, I carefully supported my code with a comprehensive JUnit test suite. I supported two junior software developers who wrote most of the core logic and web service, and supplied all non-Java code installation and application scripting.
 |
Our project manager wanted to move fast to a first release, even though we were in the midst of the transition. Thus, three off-site resources in Cupertino (a tech lead, a Java developer and a tester) were employed for six months to temporarily provide manpower. As all senior developers were occupied by the transition, the project badly lacked a technical lead. The product grew organically, without much supervision of consistency and overall structure, and very few recorded software engineering artifacts. We later payed the price for that neglect during maintenance and evolution of the product.
 |
As the initial prospective user base was quite small (large customers would only gradually migrate to the latest SAP Solution Manager version), and the solution cannot be deployed without substantial customization by helpdesk and ITIL process experts, only one beta test and a couple of demos and proofs of concept were done in 2006.
From December 2006 until April 2007, a second project extended the OpenView helpdesk support from Service Desk 4.5 to Service Desk 5.1. Service Desk 5.0 had been a complete re-write, using the new OpenView component architecture. It took much longer than planned; that release slipped by over a year. The 5.0 version only supported fresh installs, no upgrades from 4.5. That's why we only targeted 5.1, which allowed existing customers to migrate. The functionality didn't change much; however, the Java API to interact with Service Desk underwent Java package name changes and some subtle method name changes. Because of that, our source code couldn't support both API versions with the same code; although we already used the Java Reflection API for certain parts of the API, we didn't want to do the full monty there and bind to every object dynamically. Worse, our interface code was intermingled with business logic. I worked on extracting common functionality into abstract base classes in order to thin the big monster classes that interfaced with Service Desk, and now existed in two, 98%-identical flavors. A complete refactoring of the functionality (as I had suggested) was not undertaken because of time constraints, so we only opted for the low-hanging fruits. (A decision that through sheer good fortunes turned out later to be right.)
The two junior developers who had implemented two thirds of the product left after the completion of that project. The first, a contractor, got a job at an adjacent HP R&D unit in April 2007. In August, the developer that had joined our team 2.5 years ago when his team was downsized used the chance to return to his old, re-instated development team (a typical back-and-forth management decision) that was now expanding aggressively (and which belonged to the same unit our contractor had joined three months before). That left me and the replacement contractor (who had been working on multi-client support for the Incident Exchange in a side project) as the two sole developers.
 |
By then, HP had acquired Peregrine Systems, and its flagship helpdesk product, ServiceCenter was chosen as the future replacement for Service Desk. (The huge slip of the 5.0 release probably did away with the last remnants of management support.) Suddenly, the long-term support of Service Desk lost its relevance to the Incident Exchange (we only had a handful of customers by then). Instead, we had to port to ServiceCenter to capture that (larger) market (the acquisition was more about capturing market share than buying technology) and support migrations from Service Desk. (Actually, many existing Service Desk customers indignantly left for helpdesk products from other vendors.)
Supported by one contact in the ServiceCenter integrations team in San Diego and a ServiceCenter consultant in Germany, we made our first steps in ServiceCenter, which has a completely different architecture. The core of ServiceCenter consists of a generic application development framework around a file-based database (though relational DBMS can be used, too) and a GUI form designer. The helpdesk modules are written in RAD, a proprietary programming language. The core could support virtually any three-tier enterprise application, not just helpdesk stuff. The downside of this powerful system is that there is no clear boundary between the core applications and customizations, which can be implemented in RAD (and often, but not everywhere, in JavaScript, the designated successor to RAD).
 |
As a result, it was much harder to deliver an out-of-the-box integration; you don't know how a customer has customized a particular feature; except for brand-new objects, you always run the risk of overwriting existing customizations when your unload is applied to a customer system. In the end, the ServiceCenter Incident Exchange integration needed even more consulting work than the Service Desk integration. This, and the political fallout and infighting from the merger with Peregrine Systems made it hard to obtain a decision on how to productize the Incident Exchange. Our team wanted a clear, long-term mandate; a decision to broaden the service offering to become an official HP product would have provided strength. (Our team was in a fragile state, as all other projects after the completed transition had only advanced to investigative or prototype stages.) It took almost a year until the right person with the authority was found and a decision was made. By then, the customary end-of-year reorganization had swept our team back to our old master (the Operations Management organization), who wasn't interested in the Service Desk area at all, and wanted us to drop the Incident Exchange as soon as possible.
Finally, in January 2008, the product manager for integrations into ServiceCenter (the next version would be renamed to Service Manager, presumably to better accommodate the Service Desk customers who were willing to migrate to it) decided to productize the Incident Exchange through a new R&D team in Shanghai, China. That team was built from scratch and mostly staffed with engineers who had supported Service Desk so far. (Initially, Service Desk had been acquired from a company in the Netherlands; HP had later moved product support and maintenance to China in order to free the original developers for the big migration to the new OpenView component architecture.) Our team identified the necessary skills, but they already had those Service Desk developers, and no ServiceCenter expertise, and very specialized talent with SAP skills is very hard (and expensive) to come up with in a booming low-cost geography. Despite our serious doubts, they carried on with hiring and onboarding, and had the team in place at the beginning of March 2008.
 |
From that point in time, we had regular (once or twice a week) virtual meetings, where I presented the architecture and use cases of the Incident Exchange, and demoed the existing integration into Service Desk and the prototype integration into ServiceCenter. I divided by time evenly between those remote education sessions, Q&A via email or instant messaging, transition planning and implementation and code cleanup tasks. My experiences from the previous two transitions helped me a lot, and I had a lot of historical baseline data to improve my estimates and task breakdowns. There was only one difference: In the past, I had owned the products since their inception; this time, the product had never been released, was in an unstable state between alpha and beta, and I had been the target of a haphazard transition from my former colleagues only eight months ago.
After eight weeks of preparation, demos and Q&As, two engineers from the Shanghai team visited our team for a three-week onsite transition. One of these engineers was to become the ServiceCenter expert, the other should handle the SAP integration. According to our planned schedule, they would spend most of the time with me and our contractor in a meeting room, using whiteboards, projected design documents, source code fragments or live remote sessions for an intense knowledge transfer. Occasionally we split into two groups or retreated to our cubicles for details or to debug a problem; most of the material was introductory and high-level for lack of prerequisites and transition time, anyway. These constraints also relieved my worries that my own knowledge was limited, and that I didn't know many implementation details and would have to ask my former colleagues about that. Most of these worries were unfounded, though, and I confidently presented the topics as if I had never done anything else. In the last couple of days, we even delved into difficult synchronization and parallel processing topics, found a few bugs in our prototype, and did the troubleshooting and defect classification on the spot.
Our visitors left on a Friday, and the following Monday, my daughter was born. Perfect timing! As previously arranged with my manager, I mostly worked from home office, answering questions and monitoring the progress of the new team. Though we had established a good and friendly working relationship with our two visitors, and I also had had email contacts with all other team members beforehand, only very few questions came up. I was a little bit disappointed, because I had done my utmost to be responsive, had explained things thoroughly and with lots of background information to bridge any cultural or language barriers, and had offered my help and insights at any opportunity. Maybe the new team was overwhelmed, maybe there's also a cultural component, that they want to prove themselves, don't want to be monitored too closely. Despite the diversion of a newborn baby, I longed to be a virtual team member of the new team, fading out only slowly, after seeing that nothing had fallen off the table. I stood in marked contrast to my manager and team mates; who were quick to forget about the Incident Exchange and the political forlornness surrounding it.
The HP Service Manager to SAP Solution Manager Exchange (product number TA125AA/E) was released in October 2008; my manager had forwarded me a short note about the 1.0 release. In November 2008, the manager of the Shanghai team left for another business unit. At that point in time, I hadn't received any updates from them for months.
At the beginning of 2009, a Google search for the product number lists two non-HP sites that sell Incident Exchange licenses. A product number search at hp.com or the BTO Software portal doesn't yield any results. I did manage to download a two-page Solution Brief HP Service Manager Exchange with SAP Solution Manager
from the Service Center page, though.
Ingo Karkat; last update Jan-2009