For over 15 years, I worked on the topic of SAP change and configuration management. Time and again I encounter SAP consolidation projects from SAP R/3 to SAP R/3. The motivation for such projects is familiar to everyone – reduce costs for SAP operations. Unfortunately, we have seen that SAP has scarcely learned from experience. Already after going live with the first corporate subsidiary, the company is facing a dilemma of whether to go live with additional corporate subsidiaries and operate the first live launch as a competitor.

This competitive situation for SAP projects can only be brought under control with SAP Application Lifecycle Management (SAP ALM).

Beteo defines the following guidelines for this:

SAP single-client architecture

Due to the competitive situation of several companies, products, etc. for the same SAP client, business process errors are already being identified in the development environment.

Digitalized change processes

Digitalized change processes ensure proactive momentum and link the various support systems that are participating in SAP change processes (control through redundancy).

Consistency assurance through SAP Solution Manager with SAP customizing synchronization

This permits autonomy of decentralized developments (primarily SAP customizing). Internal developments using component-oriented software engineering. Component-oriented software engineering in development and customizing allows long-lasting, dynamic software systems that can be adapted to changing business environments.

Strict naming conventions for all development objects (SAP and non-SAP), including SAP customizing

So that each object to be developed (including SAP customizing entries) can be referenced by its logical components.

Software-supported SAP impact management

SAP impact management offers only one benefit when it is dynamically stacked from the logical components to the technical components.

Consistent SAP transport management

System-supported solution approaches for ensuring vertical and horizontal consistency are an absolute must, ideally directly coupled with component management.

SAP architecture management

Not everything that SAP communicates also functions in practice. Critical scrutiny of solution approaches from SAP is appropriate or even better – your own opinion, i.e., knowing your own requirements for managing SAP Template.

Multi-program-capable project management.

The dependencies and intersections between several SAP projects must be comprehensively managed.

Conclusion

All of these guidelines together – and really only all of them together – allow consistent SAP Template management. This sounds like a lot of technical complexity. Practice demonstrates that with complex SAP systems, the benefit outweighs the complexity many times over – if not the benefit of sustainable assurance of a corporate-wide SAP system.

May 17, 2010 by Dieter Steiger

SAP Marketing has a long tradition of always using the latest buzzwords. SAP Cloud Computing is “the next big thing.” That’s why SAP is talking about cloud computing. Making SAP available as a cloud-based product means offering all SAP functions via Web browser. But there’s more to it. If individual users want to access SAP functionality in the cloud – data management and parameterization of systems and SAP Business Processes for individual customers must first be completed. This is easier said than done by SAP in my opinion. But why? Other packaged software producers have long been offering such cloud-based products. In order to answer the question, it is helpful to understand how SAP is technically constructed. SAP is software that has undergone numerous, sometimes dramatic phases of evolution to become what we loosely call “SAP” today. A brief introduction to SAP R/3 software architecture provides deeper insight.

SAP evolution of SAP R/3

1. Software package: Four IBM software specialists launch SAP with one of the first mainframe-based transactional models. SAP R/2 is born. Initially, with modules for accounting only, followed by modules created using the SAP-developed programming language ABAP for new areas such as logistics.

2. Client server: The client server wave spills over to SAP. SAP first ports R/2 to IBM AS/400. But the system never runs adequately. In a rapid second attempt, porting to HP Unix is successful. The result is the ABAP-based client server application SAP R/3, which in contrast to R/2, provides a graphical user interface. As with R/2, subsequent new business functionalities are developed, and additional releases appear up to SAP R/3- Release 3.0. SAP R/3 now consists of numerous modules that can be summed up as accounting, logistics, and human resources.

3. Redundant systems: With SAP R/3 Rel. 3.0, SAP managed to become the market trendsetter. The term ERP becomes a virtual synonym for SAP R/3. Through growth and large-scale implementation as well as immense scalability requirements, challenges to basic technology and business functionality increase. In order to satisfy growing expectations, SAP ALE (Application Link Enabling) is launched. As one of the first packaged softwares, SAP institutionalizes the concept of controlled redundancies in a software suite.

4. Internet: Internet euphoria is rampant, and SAP has a technological answer to the trend: SAP R/3 Rel. 3.1 with SAP ITS (Internet Transaction Server). SAP ITS is in a position to convert the SAP-internal SAP GUI log into HTTP and vise versa. This allows a direct jump from simple HTML pages into the SAP R/3 business application.

5. SAP component architecture: In order to integrate new, popular applications into the platform, SAP attempts to separate the strong SAP basis kernel from the SAP application kernel. A similar separation is completed at the application level. The entire HR module is decoupled in terms of ABAP from the remaining primary accounting and logistics modules. As of this point in time, communication between applications is based only on SAP ALE.

The separation of the SAP basis also forms the foundation for additional business functionality that is no longer classified solely as enterprise resource planning: SAP BW (Business-Warehouse) and SAP CRM (Customer Relationship Management). SAP is now still based on ABAP but consists of various ABAP application components – ABAP heterogeneous!

6. Single sign-on: SAP quickly recognizes that as a consequence of ABAP heterogeneity, logging on users with different systems must now be eliminated. With SAP R/3 – Release 4.5, SAP launches an ABAP-based workplace. This makes a single sign-on based on SAP GUI possible, which controls jumps to the various ABAP production systems.

7. SAP Portal: The entire market is talking about portals, and with its ABAP-based Portal Workplace, SAP can absolutely not satisfy the demands of modern portals.

SAP therefore buys Top-Tier, which at the time had already developed an interface based on the SAP HTML-GUI. With this acquisition, SAP takes over a non-ABAP-based technology for the first time. SAP Java and ABAP enter into a landmark relationship.

8. SAP Application Server: Now with the technological Java/ABAP heterogeneity of components, SAP launches the marketing construct SAP NetWeaver with the goal of using each of these very different technologies through a shared platform. SAP NetWeaver incorporates the following seven purchasable product suites:

• SAP NetWeaver Application Server ABAP – ABAP-based business systems are stacked and made available here.
• SAP NetWeaver Application Server Java – Java-based systems are stacked and made available here.
• SAP NetWeaver BI (business intelligence – previously BW)
• SAP NetWeaver PI (process execution, initially called XI)
• SAP NetWeaver Portal
• SAP NetWeaver MDM (master data management)
• SAP NetWeaver Mobile

9. Service-oriented architecture: SAP Marketing then jumps onto the next largest IT architecture wave after client/server: service-oriented architecture (SOA). The company SAP ESOA, now known as SAP SOA, is launched. Among other things, this allegedly allows SAP to fulfill conditions for offering cloud computing products.

Data management for business processes

This evolution of SAP provides an impression of the complexity and extensive nature of an SAP system built from components. With SAP Enterprise installations in which the entire SAP Business Suite is deployed, an SAP system with an architecture that includes a number of production systems with databases in the upper double-digit range quickly came into being – for historical reasons and due to customer requirements – but still without upstream development, testing, staging, prototype, and training systems. This SAP complexity can be very difficult for a customer to manage. And now the next marketing wave – SAP Cloud Computing. Such a system is to be built to meet the on-demand requirements of individual users? On demand in the cloud for users from hundreds of different customers with differing requirements in terms of system alignment?

With the knowledge of previous history and SAP software architecture, SAP Business by Design is based on a logical, unique SAP installation for each customer. How does SAP intend to manage the individuality of each of these unique installation systems, not to mention understand what this means for individual systems with a reasonable amount of complexity? Lifecycle Management in the cloud and beyond is a challenge that is too immense.

Through the illustration of the SAP evolution model, one can conclude what this means for SAP to provide the SAP business functionality of an SAP backend module within a browser that is based on user-specific roles. This is why SAP is expanding its R/3 client/server world to include additional architecture levels as support for this Internet technology. SAP must now enhance infrastructure areas with additional and more productive server levels, which will cause the complexity of the system and maintenance to increase even further.

SAP functionality including data in the cloud

Thanks to the latest SAP phase of technological evolution, namely SAP SOA, SAP business functions are available on the Web – but with an SAP standard with only a single-digit percentage of SAP functionality. It is noteworthy that SAP Web functionality often does not correspond 1:1 with installed SAP functionality at the customer. SAP is running on two tracks simultaneously: one for the long-established ABAP users and one for the new “Java freaks.” And they are not yet running in sync.

SAP cloud computing – conclusion

Can business functionality based on a 20-year-old concept and the associated system environment handle the demands of modern cloud computing as described in the first paragraph? From my perspective, cloud computing-supported virtualization, scalability of the system world and data management for transactional processing of extensive business data (which is based on individual settings) are unrealistic and not feasible, at least not if we want to remain within a reasonable degree of complexity. SAP is attempting once again to ride a marketing wave from the outset – to “fly along in the cloud.” Could this cloud build up to dangerous storms for SAP?

Previously, SAP ensured that changes to its own code were under control and that is was providing support to customers with software upgrades. With SAP as a cloud computing product, this has come to an end. Now SAP must stack unique customer environments and maintain them throughout the lifecycle – and not only SAP code, also the entire configuration and all systems. Tools such as SAP Solution Manager are not created for this comprehensive SAP change management task and are only of limited use. Problems previously left for the customer to resolve are becoming a challenge for SAP itself.

Is this the reason why the SAP cloud product Business by Design is making only sluggish progress? In any case, a quick increase in the number of Business by Design users without corresponding, effective, customized SAP customer provisioning and an SAP Lifecycle Management solution would be fatal for SAP.

In principle, this is not a problem for SAP Business by Design customers, as long as the SAP cloud product is priced right and is technically sound. But is SAP really in a position – beyond marketing messages – to deliver such a product at an affordable price? It’s up to SAP to prove this. If unsuccessful, either SAP or SAP Cloud Computing users could pay dearly for the attempt.

]]> http://www.beteoblog.com/2010/06/11/sap-cloud-computing/feed/ 1 http://www.beteoblog.com/2010/06/11/sap-cloud-computing/ http://feedproxy.google.com/~r/beteoblog/PjWE/~3/AM9AA5Z2b3c/ http://www.beteoblog.com/2009/04/23/project-portfolio-management-ca-clarity-ppm-or-hp-ppm/#comments Thu, 23 Apr 2009 12:29:54 +0000 Christoph Langenbahn http://www.beteoblog.com/?p=448

Based upon our experiences with projects using various PPM tools, we took the liberty of comparing two project portfolio management heavyweights, namely CA Clarity PPM v12 and HP PPM Center 7.5.

When it comes to project controlling and project management, CA Clarity PPM and HP PPM offer the traditional multi-project and project management functions as a complement to tools such as MS Project or in standalone mode. Open and flexible interfaces to peripheral systems as well as additional standard interfaces to project management systems established on the market, such as Microsoft Project, are included in both products.

Support for project planning and project prioritization for an innovation process that is superordinate to the projects is provided in the tools as a standard feature and best practice processes for it are included.

Both manufacturers offer a workflow engine with which these processes can be converted into digitized workflows corresponding to the requirements. The workflow engine interfaces for administrators are quite different at the first glance. Defining workflows initially seems simpler in HP PPM because the individual steps are arranged graphically on the screen and then, similar as with CA Clarity PPM, they have to be defined in detail. The user’s view of the workflow to graphically depict where the workflow is located in the process is more appealing in HP PPM.

Generally, the CA Clarity PPM’s user interface is more contemporary. In order to use the drill-down feature from the Clarity PPM dashboard graphics, one must first install the Adobe SVG Viewer that is available free of charge; this is not necessary for HP PPM.

Both products offer dashboard functionalities with drill-down capability based on portlet technologies and largely adjustable interfaces. In this way, both products can be completely customized and expanded to one’s own needs and preferred usage.

In addition, both products offer functionalities that, in addition to tactically provided budgets and resource allotments, also allow a strategic alignment to higher-level business objectives.

Here is where the actual approach-related differences emerge in regard to supporting accompanying business processes such as resource, time, and financial management as well as comprehensive innovation management within the company.

CA Clarity PPM v12

CA Clarity PPM offers functionalities from idea-related decision-making to prioritization and analysis, taking into consideration existing resource allocations and a diverse range of budgetary perspectives. In the tool itself, one can carry out both strategic as well as tactical planning, including execution and controlling management for single or multiple projects, in a flexible manner.

The modular setup of the functional components allows the system to be optimally fitted to an organization’s level of maturity in terms of project planning and management. Extensive functions for graphic workflows, collaboration, and document management round off the tool’s functionality.

CA Clarity Dashboard

CA Clarity PPM offers standard interfaces to:

• Microsoft Project, OWB (Open WorkBench)
• CA Unicenter Service Desk, CA Software Change Manager, and CA Unicenter Asset Portfolio Management

Features and requirements that favor using CA Clarity PPM

• Detailed cost control by defining cost plans
• Scenarios at project- and department-levels pertaining to resources and working with cost plan variants
• Supplier management functions
• Direct charging and billing (internally and externally) for projects stemming from a single point of control application
• Portfolio-related scenario staging based on various cost-benefit plans in addition to resource requirements
• Parent / child relationships for master and department portfolios and organizational structure-related portfolios/programs
• Integratability into existing CA products

HP PPM Center 7.5

HP PPMC also offers functions to strategically analyze and tactically plan future projects. In doing so, HP PPM places greater emphasis on project controlling aspects to manage the project portfolio of an individual business unit.

The functions pertaining to supplier, resource, time, and especially financial management are limited. If necessary, these can be covered by the integration of third-party solutions on hand in the company.

By means of an integration platform, the HP PPM product is easily integrated into the HP BTO software portfolio. Interfaces allow one to deploy HP Quality Center and HP uCMDB for example directly from the workflows.

HP PPM dashboard

HP PPM V7.5 offers standard interfaces to:

• Microsoft Project
• HP Service Manager (HP SM), HP Universal CMDB (HP uCMDB), and HP Quality Center (HP QC)
• SAP CTS (SAP Change and Transport Management)

Features and requirements that favor using HP PPM

• Portfolio management field exclusively in the focus of an (IT) organizational department
• Use of “leading” human resource, financial, and controlling peripheral systems
• No planned enterprise portfolio management (EPM) activities
• No billing for projects stemming from the PPM system, but stemming from the “leading” financial application
• Integratability into existing HP BTO products
• Existing use of HP PPM as the application deployment system, e.g., Oracle Applications, SAP, and Peoplesoft, as well as the need for interfaces to these

Clarity PPM vs. HP PPM Comparison

Generally, CA Clarity PPM and HP PPM are suited for use as project portfolio management solutions. Business-related factors or a preference for a given manufacturer therefore play an important role in the decision. Nevertheless, one of the two solutions can be objectively favored based on a company’s detailed requirements.

• Requirements for a comprehensive portfolio management tool, including integrated aspects such as financial and resource planning, as well as company-wide deployment are arguments for CA Clarity PPM.
• Requirements for a project portfolio management tool for project controlling within a department or company-wide, then integrated into leading financial, resource, and planning tools make HP PPM a viable alternative.

Actual practice has shown that one can work successfully with both tools. Successful implementation of a software-based PPM solution depends less on the individual strengths and weaknesses of the PPM software, and more on how the workflows of the individual organizations are depicted, how the applications are integrated into the environment, and what implementation approach is selected.

HP Service Manager is used to administer and process tickets within the framework of IT Service Management. The Service Manager adheres to ITIL V3. Various modules are used, such as incident, problem, change, etc. With the ESS (Employee Self Service) Web control surface, end users can issue their own interaction tickets, which a support technician can then use to open an incident. If no solution is found, the  Service Desk can transfer incidents and interaction tickets as well as track problems and changes.

HP Service Manager shows limits with Change Management

Simplified workflows are certainly possible with Service Manager. However if comprehensive Change Management is in operation, requirements exceed conventional ITIL functionalities. The administration of all relevant objects is of utmost importance. Information about infrastructure as well as about organizational (organizational units, roles, security aspects, etc.), technical (programs, change requests, transactions, etc.), and descriptive (documentation, concepts, test cases, etc.) objects – and their relationships – should be represented. This is beyond the scope of HP Service Manager. As soon as requirements increase and greater flexibility is needed, a tool such as the HP Project and Portfolio Management Center (PPM) is necessary. PPM provides extremely powerful workflow controls with a variety interfaces to additional tools and to the Service Manager. In addition, PPM allows control of any number of commands to be performed and external Web services to be controlled. This allows for example control of SAP transports, administration of Quality Center (QC) requirements and defects as well as an additional configuration database, such as HP UCMDB, to be updated. Compared to more technically mature PPM workflow controls, Service Manager demonstrates significant weaknesses in flexible administration and process configuration.

By integrating the change process into PPM, a change request issued in the Service Manager – in which no longer just the Service Desk but also other teams, tools, and processes are integrated and a broad range of decisions for controlling the change process are required – can be transferred to PPM. Because processes in PPM can be better and more flexibly modeled, the change process is completely administered through PPM. A change ticket in the Service Manager still receives only the requested status updates so that the Service Desk knows for example that a development has been launched or that a change is being tested and nearly complete. Users are continuously informed of status.

Integration change process: PPM-Service Manager

Integration with HP PPM

Through a PPM add-on called MAC (Managing Application Change), integration of different tools is possible. Necessary Java classes and configuration examples are provided during installation. All communication between PPM and Service Manager is based on the Web service interface in the Service Manager.

First of all, the Web service for the requested module must be configured in the Service Manager, in our case Change Management. When all necessary fields as well as any number fields and functions are available through the Web service, the Java stub for PPM can be produced from the Service Manager WSDL file. Through this stub, PPM can communicate with the Service Manager. Of course it is also possible to access the Service Manager from PPM or any other Web service.

At a determined interval, PPM searches the Service Manager to determine is a new change has been opened. This change is then fetched and opened in PPM as a new request. It is also possible to send status updates to the Service Manager, thereby informing the Service Desk about the progress of the process. When the process is complete, the same interface is used to send the message back to the Service Manager and close the change.

Conclusion

Service Manager workflow controls are not sufficient for implementing and automating a comprehensive change process from start to finish, for example test management in QC, expanded configuration management in the uCMDB, or transport administration in SAP.  However the possibilities are open upon integration of the change process into PPM. Configuration necessary to integrate the tools is nonetheless somewhat complex: the stub must by newly constructed as soon as the configuration of the Web service has been changed, mapping of fields takes place through JavaScript code and without a configuration control surface, time formats must be correctly converted, files must be repeatedly deleted, a small mistake results in the entire integration not functioning … In summary, integration appears to remain rather underdeveloped, and experience is necessary to achieve successful and efficient implementation.

However, when integration runs as desired, and all fields are correctly copied and converted, its usefulness is enormous. The most diverse processes are thoroughly integrated: from issuing tickets by end users and development to testing and deployment. This also includes dashboards, notifications, and reports that can be flexibly and process- as well as project-comprehensive generated, administered, and customized. Every participant stays informed, and changes to systems are controlled and thus implemented with lower  risk.

The most recent Forrester Wave (Q3 2008) examined the six biggest developers of functional testing solutions. Based on the current offer and the strategy regarding the direction the corresponding solution is to take, HP was ranked number one and IBM came in second. It’s time to take a closer look at the current flagship products and compare them against each other.

In the red corner of the ring, representing IBM, please welcome Rational Quality Manager Standard Edition (version 1.002) and in the white corner, representing HP, please welcome Quality Center 10.0 (Enterprise Edition). In this bout, the current world champion Quality Center (QC) will be defending its title against the challenger Quality Manager (QM) with the fearsome left hook in the area of “look and feel” as well as in the key discipline of “range of functions.”

Appearance – Playfulness vs. Solidity

Both solutions are opened using a URL in the browser. Here, Quality Center (QC) 10 still depends on Active-X, which has been deactivated in many companies and for that reason usually has to be distributed as an additional package to the clients. Quality Manager (QM) doesn’t face this obstacle and therefore runs perfectly, including in Firefox.

Once accessed, QC and QM have very clearly laid out appearances. In QM, one always starts on a personal dashboard. This dashboard is very easy to configure and looks good, too. As described in the blog entitled HP Quality Center 10 from a Test Manager’s Perspective, the QC 10 also offers an integrated dashboard which has a similar range of functions as QM’s.

One navigates through both test suites using a vertical icon bar, which can be masked in the QC and arranged horizontally as an option in the QM. Overall, QM seems faster and more modern, more dynamic, and more interactive, whereby QC seems more plain and professional. QC can’t be changed much, with most of it controlled by means of lists and parameters and a little VBScript. On the other hand, QM can be totally reconfigured and adjusted to the n^th degree in regard to a company’s internal workflows. If QM has more of a Facebook look and feel, then QC would be more like Xing; that’s why descriptions like playful versus grounded are apt.

Range of Functions

The getting-started hurdle for new testing solutions is high. In order to come close or beat the industry champion Quality Center, special moves are called for right in the first release. So what does Quality Manager include in its first release to take on QC?

It would be best for us to compare the individual mini-modules/functions that are needed in day-to-day work in a table to then pick out the corresponding winner:

Legend:
0 = Functionality/mini-module not available
1 = Functionality/mini-module available
2 = Functionality/mini-module better than the competitor's
3 = Functionality/mini-module is very good
* = proved stability and scalability (QC) /
    modern web 2.0 interface without Active-X (QM)

In my opinion, the primary difference pertains to QM’s interactive test plan (planning), which QC lacks. The test plan should in no way be confused with the Quality Center’s test plan module. This is a bona fide test plan that is jointly generated through the distribution of work items (generally by the test manager). Individual items, such as requirements, test cases, or assembling corresponding test teams can be delegated to other QM users by means of work items. The test managers in charge can monitor progress at any time via the dashboard, making it ideal for offshore projects!

QM’s test environment management, which is not available in QC, is also pretty neat. If connected, test equipment can be provided with images at the click of a button and reserved accordingly for a test.

In contrast, Quality Center offers an integrated baselining tool and risk-based quality management, which we were unable to find in QM.

Summary

In a direct comparison, Quality Center is (still?) in the lead. However, with the JAZZ platform and the Open Commercial Development, Quality Manager has a speed advantage that needs to be taken into account. The current version of QM doesn’t have multi-project support yet, but it is expected to be available in April 2009 with version 1.01. On jazz.net, one can also check (“open” for that reason) what is currently being tinkered on. That’s one reason to look forward to fast release cycles. It remains to be seen whether customers want this type of speed from these testing solutions and will also import the new versions right away.

The QC versus QM match doesn’t end with a knockout. If one tallies up the points, the winner is QC with a score of 20 to 14 because it simply does many things in a better or niftier way than Quality Manager (importing test cases is supported in QC with a Word or Excel plug-in; in QM, the upload is done without support in the XML format). But even here, QM will probably catch up quickly. This is also necessary since QM’s release 1 deals with a new solution which in everyday work still has “teething pains” (e.g., test cases can’t be copied and saving attachments is sometimes impossible).

Ultimately, it’s worth noting whether one’s company already relies on IBM Rational products and the JAZZ platform in general, because combining development, requirements engineering, and testing on the same platform has a lot of cost-saving potential. To top it off, choosing a functional testing solution is always a price-related issue.

Security is especially important in online applications, yet far too little attention is paid to it. Perform a quick risk assessment just prior to implementation, jerry-rig a plug for the biggest holes, and you’ll have the software up and running in no time. Then a few days later, the first bytes of customer data are stolen. Does it have to happen this way?

In an incredibly short time, online security risks have become the primary risk for businesses. One reason is that nowadays business-critical applications have to be accessible online at any time to customers, partners, and internal users. Continuous availability opens the floodgates for friend and foe. Interactive contents exacerbate the whole thing. Statistics show that hackers don’t have to be asked twice to do what they do. Currently, one of the favorite modes of attack is cross site scripting (XSS). For example, a hacker tries to manipulate a web application in such a manner that damaging script code is embedded in the displayed page (e.g., in a guest book or an auction site page). The browser processes this actually trustable website including the harmful code and thereby sends the current login information back to the hacker. Even though companies take security absolutely seriously, reports regarding successful attacks are a daily occurrence. What’s happening here?

Fig. 1: Quality vs. Security

FINALLY RETHINKING THE SITUATION

The lion’s share of an IT security budget is invested in network security, e.g., for firewalls and intrusion detection systems, even though according to Gartner , 75 percent of the hacker attacks take place directly via the application and not the networks. To spend money specifically on where the greatest danger lurks requires rethinking the situation. Ideally, pains are taken in software development to ensure that no security loopholes even exist or to remedy these immediately. Those who are late with their testing are wasting money. However, the problem isn’t that easy to fix because the software is geared to preferably provide what is described in the functional specifications. As a result, checks are performed on what the applications are supposed to do, but not on what they are not supposed to be able to do. Developers with expertise in the field of secure development are a rare breed. Testing also has to be tailored to the new requirements. Unfortunately, one rarely sees a penetration test as part of a test concept. Likewise, the skills profile of a tester who is supposed to verify the functionality is different than that of a security tester. While one is looking for things that don’t work, the other should be looking for the undesired functionalities that allow too much to take place – in other words, we’re talking about real detective work.

SOLUTION APPROACHES

Making online applications secure requires specific measures:

1. Implementing security rules, guidelines, and regulations
2. Creating security requirements and attack scenarios
3. Performing specific security architecture reviews
4. Developing and complying with secure coding guidelines
5. Performing:
a) White box penetration test
b) Grey box penetration tests
c) Black box penetration tests
6. Monitoring operating systems continuously
7. Making assessments and feedback loops part of the first step

Fig. 2: Toolbox for actual implementation measures

ACUTE NEED FOR ACTION

In Switzerland, the secure programming and performance of penetration tests are still in their infancy. There most certainly is a need to make application more secure and to include the entire software development cycle when creating secure applications. By implementing the solution approaches above, one can gradually increase the application security’s maturity. However, it takes considerable amount of time and money in the short term because systematic training of the test and development units is necessary. In any event, setting up one’s own security testing squad does make sense.

TOOL SUPPORT

Once the activities are defined, they can be accelerated. Large-scale software manufacturers such as HP or IBM have recently shored up their capabilities in regard to security testing of web applications through targeted acquisitions. Certain fields of use may also have corresponding open source solutions. IBM, like HP, offers security-related tools that support an application’s entire lifecycle from its creation to its replacement:

For developers:

• Code is checked for security while being entered
• Solution recommendations and links appear if requested

For testers:

• Automated security tests check web applications and services for flaws
• Any discovered flaws are saved with the corresponding priority depending on the security risk and assigned to the responsible developer

For security experts:

• A 24/7 solution combs through complete web applications looking for security loopholes
• Automatic verification pertaining to legal, company internal, and regulatory provisions

The tools described are becoming better and better. Experts scan the Internet daily for new risks. As for anti-virus solutions, the tools are kept current with new signatures and detection patterns by means of updates.

SUMMARY

Targeted investments are necessary. Regardless of the maturity level an organization has reached, there is always room for improvement. The investment is certainly worthwhile because besides financial losses, a company’s image is also at stake.

The new Version 10 of the HP Quality Center (QC) is now available. Yet what are the actual advantages of the new QC compared to its predecessor from a Test Manager’s perspective?

Below, I will take a look at some of the new features and changes, and I will answer the question whether one should even make the switch.

The Most Significant Changes

The new QC Version 10 has seen a series of changes, of which the most significant ones are:

• Version control
• Baselining
• Integrated dashboard
• Shared libraries
• Cross Project Customization

Version Control

Finally, QC has been provided with a fully integrated version control. In past versions, one had to make do with third-party integration, which generally stumbled rather than ran. The version control, if desired, must first be activated for every individual project via the SiteAdmin. Once this is done, all entities falling under the version control become Version 1. QC entities include requirements, tests, test resources, and business components. If one wishes to add a test step to a test case for example, one is automatically requested to check this test case. As soon as there is more than one version of an entity, one can compare various versions against each other or retrieve an older version.

Summary: The whole thing is intuitive and easy to operate. But what’s the use of having eight versions of a requirement, when one doesn’t know which software release a version belongs to?

Baselining

Along with version control comes baselining, which is intended to answer the question above. Using the new “Management” module that replaces the “Releases” introduced in 9.x one gets to the baseline function via the “Libraries” tab. This enables one to obtain a summary of a complete testing release and retrieve it if necessary. In this way, a test set can be pinned to a baseline in the test lab. In other words, as of now, the manual copying of entire trees into the test plan module is a thing of the past. At last, test managers will be able to properly organize software that has multiple parallel releases (in production, current release, future release).

Summary: Setting up the baseline works very well. While creating it, a log keeps one updated on what is currently taking place. However, setting up baselines probably needs to be done during off-peak hours since it can take a while for larger QC projects.

Integrated Dashboard

Equally interesting for test managers is the new integrated dashboard that can be found on the left-hand navigation bar where the “Management” module is, too. The special feature of the new dashboard does not pertain to the graphics, which are not particularly appealing, but the “Cross-Project” functionality. It is now finally possible, when working on a QC project, to get an overview of all of one’s ongoing projects. These dashboards are freely configurable and can be designated to be personal favorites or publicly accessible. Special Excel reports also enable direct access to the database via SQL. The generated reports can then be graphically processed at the same time by means of VBScript.

Summary: The new dashboard module is quickly customized and achieves its purpose in ongoing projects. What is missing is a sensible way of printing content for a given project meeting, for example.

Shared Libraries

Libraries, which are located in the “Management” module, can be re-used and distributed with Version 10. A library represents a collection of entities in a QC project, including their relationships to each other. When dealing with many similar projects, it offers the advantage of not having to repeatedly create entities. Libraries can be imported from project A into project B, compared against each other, or even synchronized. A library also allows one to collect the same entities as in versioning. Defects are not included, but they can be shared with the new “HP Quality Center Synchronizer” manually among several QC projects. As mentioned, the advantages really only present themselves when one has many and/or large-scale projects. I suppose that is why this functionality is available only in the QC Premier Edition (also available are the Standard and Enterprise editions).

Summary: It remains to be seen whether this function will actually be used in real-world applications. In my opinion, it makes perfect sense to be able to take over pre-defined assets from another project so that one doesn’t have to keep re-inventing the wheel.

Cross Project Customization

And now here’s the last big change: Cross Project Customization. Many organizations have defined standards, such as a uniform defect status field or a standardized priority scale, for their software quality-related areas. However, these fields and lists were often changed or even deleted by QC project administrators. Some companies have even gone to great lengths in using their own programming to define a template that can be distributed to all QC projects, thereby establishing a uniform standard.

For all those who want to spare themselves this time and effort or do not wish to keep an in-house programmed interface going, there is a solution. Site Administrator now provides a way to link projects with a template. If the template is changed, the delta can then be passed on later at the right point in time. This function has been awaited not only by test managers who like to have the same configuration in all their projects, but especially also by the respective operators of QC installations, namely the system administrators. Cross Project Customization is also only available in the Premier Edition.

Summary: This change is awesome! Finally, testing organizations or Test Factory managers are able to implement a certain basic standard in their projects. Once this is accomplished, nothing can get in the way of standardized, across-the-board reporting.

Is an Upgrade Worth It?

The new Version 10 is an absolute milestone not only for tests managers. It also makes life easier for testers, Test Factory managers, as well as QC system administrators. The new functions have been anticipated for quite some time and have been implemented in the new product in a well-conceived manner.

However, there are still questions about how stable the new version is (my tests ran flawlessly) and how simple a migration of a larger installation might be. If these questions receive favorable responses, one should absolutely consider switching over to the new version!

The new concept of the Enhancement Packages (EhPs) from SAP is ingenious from a technical perspective. It’s actually too bad that SAP, the supplier par excellence for business software, has taken so long to create this software logistics concept. Based on the time and effort they’ve put in, any SAP CIO can tell you what this gap in the framework has cost customers. Yet it’s not quite as cut and dried as suggested in the Inside IT article entitled “No More Tedious Upgrades” dated February 4, 2009. The way Roche’s CIO Jennifer Allerton is quoted, one might be led to believe that specialists are no longer need for upgrades. Allerton explained to the Wall Street Journal that Roche had completed four complete upgrades in the last year, which required a team of 15 specialists. She believed that the new Business Suite would enable the company to avoid having to carry out upgrades. And this is a deadly fallacy.

There’s no doubt that from a software logistics perspective, SAP did its homework. But this perspective is restricted primarily to the impact of changes only within the scope of standard SAP software functions. Customer-specific modifications and integrations are not considered. Can you name a large-scale customer that has not carried out massive modifications on it system, expanded it, and integrated it into its application environment? By the way, this is not unusual for SAP. Even in regard to the innovations pertaining to the Solution Manager and the Transport Management System, the problem is always only perceived from the software manufacturer’s viewpoint. The customer’s environment remains the customer’s problem. “Switch technology” that forms the basis of the EhPs can also be used when customers want to expand the SAP standards themselves; however, ABAP developers first have to learn new development methods to suit this purpose.

Accordingly, the EhP concept does not pertain to customizing or modified functions in actual customer SAP environments. However, this is typically where customers put most of their money when they implement SAP. Change impact analyses for EhP activations remain absolutely necessary. SAP assistance tools will not be able to accomplish these in the future either. In fact, they will continue to require, and all the more often, the utilization of tools developed by specialized companies such as IntelliCorp or Panaya.

Incidentally, a prerequisite for implementing EhPs is SAP NetWeaver 7.0. For SAP customers who are not yet running SAP NW 7.0, their only choice is still the conventional SAP upgrade.

Differences between Implementing EhPs and Traditional Upgrades

a) When installing new and upgraded SAP functions on the SAP platform

EhPs can be installed at any time, although the physical effort remains the same. However for the users, activating new functions and thus the customization of business processes is no longer directly time-dependent on solely installing the new functions on the SAP platform.

b) When activating the new and upgraded SAP business functions for users

In a separate step from the technical aspects of installing new functions, activating them can be done for users at any time, supposedly in a dynamic manner also for sub-functions of the SAP release.

However, this dynamic holds hazards. Just as in upgrades, it is critical when preparing EhPs to be activated to gather additional requirements of the newly provided functionalities. This is necessary to analyze the effects of activating new functions provided by SAP on the configured basis as well as on changes being made to the system that stem from projects and support change requests.

By means of such analyses, the impact level of activating individual EhPs and necessary preparatory and post-activation tasks, such as test activities, can be determined. This will clearly reveal how much time and effort was needed to import individual EhPs.

The flexible and dynamic activation of individual “business switches” is all the more reason to require an impact analysis. First, it is exceptionally helpful, when thanks to analysis tools, it already becomes clear which transactions contained in an EhP are actually implemented in a company. Based upon the business user expectations generated by SAP marketing, the customer’s SAP competence center has to comprehensively analyze these transactions in a time-flexible manner for the EhPs to be activated. Then pre- and post-processing measures for activation can be initiated on short notice in a systematic manner.

Impact Analysis

Most SAP customers have experienced the effects, regardless whether they stem from upgrades or now from “activating EhPs.” The fully implemented application portfolio is repeatedly upgraded so that the new technical functions based on old technical operating modes can be maintained, instead of actively managing only the delta between old and new functionalities (documentation, tests, etc.), not to mention that one can access information from previous application changes.

The only real fix remains to invest in a sustainable SAP Application Lifecycle Management solution to support the competing implementation of SAP initiatives and SAP operations.

Summary: SAP Enhancement Packages as a Panacea

The considerable amount of time required to identify, implement, and test new and customized business functions still remains the same even with EhPs, and is perhaps even slightly more due to the flexible, step-wise activation that businesses find appealing.

Due to the newly provided business functionality, available in whole or in parts, the impact analysis has become more complex and certainly more time-consuming.
Now that the technical installation of EhPs has become time-independent, time can be gained in the provision of sub-functions. This time savings must absolutely be re-invested in the impact analysis and the corresponding flexible pre- and post-processing so as not to incur the risk of quality-related problems in production that could result in production stoppages. As a result of this time-independence and the growing complexity in the system itself, the time and effort required by lifecycle management tends to increase if anything. The assumption that thanks to EhPs, one can save on resources needed for managing changes to the SAP system quickly proves to be a fallacy.

A Gallup poll from last year in German companies shows: 67 percent of employees make work to rule. Cause was the lack of leadership culture, of real self-evident characteristics such as esteem, respect, personal development opportunity and involvement in decisions. The damage to the economy because of the lack of innovation and frustration of customers projected at around 100 billion euros. Could in any case, even better, right?

About the positive relationship of cultural characteristics such as performance, trust, responsibility and autonomy with the success of companies, there are a large number of scientific findings and personal perception. It is more difficult to say which pattern in detail leads to success. Comparative studies depend on time and location: examples of American companies on the east coast of the early 90s do not necessarily answer to our questions today. Seemed earlier features such as stability and identity speak for superior cultures, there are now flexibility and diversity taken for granted. In the end responsible leaders must say what they think is right and what they want (reasonably related to an actual culture analysis of their enterprise).

Ever more powerful cultures differ

• by openness to other internally and externally, in contrast to autism and isolation,
• liberalism in the sense of positive appreciation of other perspectives, in contrast to the prevailing fundamentalist attitude,
• diversity as a richness and internal structure in contrast to the uniform.

These are the consistent results of comparative cultural and historical studies. Derived from this I have detailed and described some specific patterns from “adaptibility” to “trust”.

About the author:
Dr. Michael Loebbert is Coach and Management Consultant and author of the montly publication “Change Management Short Cut“.

HP PPM in combination with beteo’s SAP Change Control Current Practice can help SAP customers to reduce cost and risk the SAP change process.

This article summarizes the potential benefits, challenges and approaches of implementing a SAP change control solution based on HP PPM and beteo SAP Change Control Current Practice as well as illustrates a sample customer reference.

Potential Benefits of a SAP Change control solution with HP PPM and beteo’s SAP Change Control Current Practice

• Improved Efficiency: For 80% of all changes deployment time is reduced by 85 percent or more, manual intervention efforts by 50 to 70 percent – lowering overall SAP deployment cost and risk. Same customer headcount can manage more changes, reducing risk, change backlog and increasing traceability.
• One Uniform Change Management: One single approach will manage all changes to all applications, across all environments and platforms, automating migrations and deployments of all software changes from projects and support. Typically the overall time spent on the change process can be reduced by 20 to 30 percent.
• Digitized Best Practice: In addition the one approach will be codified, automated and governed for the entire change and deployment cycle with beteo Current Practice processes for effective change management. Like that best practice application development methodologies are enforced.
• Automated Deployment for customer projects, changes from customer’s support and from SAP: Roll-outs from change request process and project implementations, SAP upgrades, SAP service packs, SAP hot fixes, change requests from support, configurations, SAP instance consolidations, and migrations to avoid costly delays and errors are highly automated including consistency assuring measures. Managing multiple deployment environments is enabled with full control over individual changes and groups of changes or releases.
• Complete Visibility: A system of record audit trail for visibility across the entire change process with comprehensive reports and a real-time dashboard are made available.

Change Control challenges faced by SAP customers

For SAP systems as for any IT system nothing is more constant than change. At least once a week, numerous changes initiated by the customer’s  support, project teams or by SAP are moved into the SAP system landscapes and semi-automatically or manually transported to production servers. Because of the typically elaborate, complex system landscape of large SAP customers in their overall business environment, the risk that something goes wrong is high and complex, expensive manual interventions are often required to get changes applied without impacting the running SAP systems and customer’s operations.

A consistent, beteo Current Practice-based tool-supported SAP Change Control implements, controls and largely automates the SAP change process. A secure way of executing auto-deployment of SAP transports, for ABAP as well as non-ABAP changes, across the SAP landscape will be made available. It prevents system components from breaking down, resulting problems don’t need to be analyzed ex post and manually solved by system specialists anymore.

SAP offers a system with quite convenient possibilities to implement changes across system landscapes. Unless there are parallel changes from support and projects in complex system landscapes implemented, SAP’s tool supported transport management for changes does a good job. It allows transport routes to be defined across the system, transport requests to be released and change packages to be distributed and installed across the system, including defined validation steps.

But SAP’s rather sophisticated system has its limits. First, the process of rolling out changes is quite error-prone. Second, compliance rules are not completely met. And third, the system is susceptible to inconsistencies.

• Changes are more or less simultaneously distributed across the solution landscape via transport processes. Differences in runtime speed in the various phases of distribution and verification can cause time-dependent changes to be implemented in the wrong order.
• There might be conflicting changes from different projects, the customer’s support and SAP.
• Manual changes might be executed at the wrong time.
• SAP Customizing changes are not versioned and have no lock mechanism. It happens easily that they are unintentionally overwritten.
• Once changes and change sequences have been executed, they cannot easily be executed a second time.

Ways to handle SAP Change Control challenges

There are ways to proactively handle these problems with a reasonable effort. Applying beteo’s “SAP Change Control Current Practice” in combination with HP PPM implies the following:

• For all changes to the solution landscape, there is a change request and an approval. There is no transport request (technical change) without change request (organizational change). All changes are documented.
• Changes are grouped according to projects, areas of use and common technical objects involvement, so that the transport is unlikely to cause conflicts with the system environment. The projects have more autonomy concerning transport.
• Transport and routine tasks are automatically executed in the correct order, including comprehensive measures to ensure consistency.
• Potential errors caused by changes that are transported faster than others or by unintentional overwriting are recognized in time and remedied proactively. This also applies to transporting different changes from all kinds of SAP or non-SAP systems, such as changes to SAP CRM, SAP ERP, or SAP BW objects, SAP customizing, Java packages, SAP portal configurations – and to many interdependent components that must be changed.
• Entries into the Change Control documentation are made automatically and users of dependant objects for a change are being alerted.
• Change processes are strictly followed.
• All changes are executed in a secure way; rollback functions can be made available and changes run repeatedly.
• There is a complete audit trail for all changes.

A reference customer for a HP PPM based SAP Change Control

The reference customer needed a software solution that would formalize, standardize, and automate every step in the SAP Transport Management process. The new solution had to control the entire change management process in a single, end-to-end workflow — from change request through testing and interim releases to live activation. The new Change Management should underpin the automated, controlled distribution of new and/or modified SAP software processes on the basis of a regulated information flow .

The challenge
To formalize, standardize, and automate the process of taking new or modified electronic business processes in the SAP R/3 environment live, in accordance with the best practices defined in the Information Technology Infrastructure Library (ITIL). The customer was looking for a solution that would provide no-gaps support for every step in the SAP Transport Management System.

Business Value
With beteo’s experts and HP PPM, the customer achieved a change and transport management process to carefully control the system-wide distribution of software updates. The result: no more system failures, less manual work, and projects completed on time and on budget.

• The customer successfully adapted and implemented SAP Change Control based on HP PPM and a solution architecture by beteo’s senior solution architect in a short timeframe.
• The customer now has the ability to optimize its electronic business process on an ongoing basis, without risking the expense and annoyance of system failures.
• HP PPM Change Management helped ensure that already the first strategic SAP project was completed successfully — on time and on budget.

About the customer
The reference customer is a large German SAP customer occupying market-leading positions in several utility business segments.