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. The application management team is responsible for the development of availability and performance management software solutions (Smart Plug-Ins) for various enterprise applications (SAP, Oracle, Microsoft Exchange), which enhance the core OpenView products with application-specific management capabilities.
HP OpenView Application Management Software Development Engineer
Oct-1999 - Jun-2006
Ported the Smart Plug-In for SAP R/3 to new Windows IT management platform, split off common ConfigFilePolicyType component, and maintained both over several years and releases.
 |
In October 1999, after completing my diploma thesis in a different team of the same OpenView R&D organization, I started my first job at HP. Together with a colleague who's been my mentor for the first nine months, I ported the Smart Plug-In for SAP R/3 for the IT/Operations Unix management product to the upcoming Windows management product, which was being built concurrently. The main challenges were adapting the mature, but completely Unix-centered product design into a viable, native Windows product. I was able to apply my deep technical knowledge of the Windows operating system, using MFC and DCOM technologies. The new Windows management product was not very stable back then, and interfaces kept changing, so I quickly learned to focus on testing, traceability and a thorough, documented design. The release schedule of the Windows management product kept slipping, and my colleague was assigned to another task. I had gradually picked up all related tasks such as packaging and synchronization with the other four team members, who were supplying the SAP management instrumentation. Because I'd been good at identifying common, reusable components, the product was eventually split into the SAP management product and an internal component called ConfigFilePolicyType, which was used by other Smart Plug-Ins as well. There was shared development on this component, involving cross-Atlantic communication with two offices in the US. I participated in beta testing at a customer site, and both product and component were successfully released in June 2001.
 |
For the second release, I took on the main project leadership and responsibility for the internal component ConfigFilePolicyType, while working closely together with and leveraging from the SAP-SPI project lead. In parallel, I worked on the Windows integration of the SAP-SPI, rooting out prototype code left over from my former colleague and adapted to changed interfaces and a completely new packaging mechanism. The second release of the SAP-SPI for Windows, including a Japanese language version, was successfully released one year after the initial version.
I quickly had become a fully accepted member of our strong team, and my colleagues have been commending me for my deep knowledge of computing science topics and software engineering practices, which I am very willing to share with others. I wanted to improve communication; especially since people in other locations depended on my components. I set up a personal web server to provide project- and work-related information and documentation, but also personal content like photos from team events. Essentially, this website hosted our team weblog (back in 2001, still with Web 1.0 technology).
I am especially proud of having had the luck to become part of a group of diverse, intelligent professionals. Our differences in character and style have caused us to rely on each other and turn into a tight, jelled team, which weathered many reorganizations, three different managers in three years, and a lot of change within HP.
 |
In early 2003, I had participated in 5 major SAP-SPI and 3 ConfigFilePolicyType releases. As these products had grown into mature and profitable OpenView staples, tasks shifted to grooming the value delivery chain and positioning our components among the OpenView spectrum. Dealing with change had been a recurring theme in the years past, as other SPI teams were relocated and the organization had been reorganized multiple times. There was a lot of pressure from both internal, architectural changes of our main OpenView integration platforms, and from an aggressive expansion of the managed application, as SAP evolved from a traditional, three-tiered application to a complex, interconnected business suite incorporating Web, XML and J2EE technologies.
 |
This exciting change coincided with the economic downturn and tightly controlled investment. Attrition reduced our team to its tight core of five engineers. Everyone had to manage multiple roles and responsibilities, together with conflicting release schedules of our Windows and Unix integration products. Our team's diversity and strong sense of mission were crucial in coping with the inevitable stress and frustration. I put an emphasis on maintaining structure, quality and software engineering practices against my colleagues' chaotic pragmatism. For example, I introduced the concepts of refactoring and automated unit tests to accelerate development while reducing bugs. We had already succeeded in getting common functionality incorporated into the next major platform release; I was driving the requirements process. And then it seemed as if corporate alliances would elevate our product into much more prominence.
At the end of 2005, our team was transitioning to new projects. I'd already handed over my ConfigFilePolicyType component in mid-2005. After 5 releases, this pragmatic add-on was finally being incorporated into the main Windows management product where it always belonged to (but was left out of due to resource shortages). The transition went very well, because over the years, I had developed close personal contact to that team, had produced up-to-date documentation and specifications, and turned over a well-factored component with no defect backlog.
 |
Around the same time, management decided to consolidate all SPIs in one low-cost location. We'd always been struggling with an investment that was barely enough to keep our SAP-SPI alive. Internal technological changes were forced on us and bound so many resources that we'd been falling behind in the SAP management capabilities, which are the main interest of our customers. After 7 SAP-SPI releases, we were free for new tasks in our organization. Probably, these projects would still be related to SAP, this time not on the operational level, but in the service and business process area.
Depending on the project phase, the job focused on a changing subset of these main tasks:
Apart from a close collaboration with the development teams, the job involved the following people:
Ingo Karkat; last update Sep-2006