Based on our experience, we have identified the following three main areas as cost drivers:

SAP Architecture

Experience has regrettably shown that fundamental architecture errors are often made during the initial SAP R3 project. These errors are then expanded further with each additional project, and the successive costs keep on rising. And the entire SAP consulting market unfortunately plays along here. Offering SAP consulting services from the outside as a non-SAP consultant is a sheer impossibility. If consultants don’t speak the SAP dialect, they don’t even have a chance from the outset. That’s how the SAP community protects itself from outside influences.

As a CC manager, guiding optimization efforts with a critical eye towards targeted and long-term results is crucial. However, companies often lack sufficient experience and resources. The complexity of SAP R3 has resulted in most customers remaining at the level of the 3.0 release (from 13 years ago) with regard to architecture and technology usage. But the evolution from SAP R3 is enormous. So the question is whether companies did well by following the development – because the high level of complexity leads customers to a naive dependence. It is common knowledge that SAP itself struggles with the complexity – SAP ABAP versus SAP Java, strategic changes by top management, etc.

But the problem is really very simple to address. As optimization specialists, we have developed a method of identifying this potential. We analyze the architecture and concept, the implementation and operation. Once we have identified the pain points needing optimization in the SAP architecture, then we can delve into the underlying SAP infrastructure level and the overlying SAP ALM (SAP Application Lifecycle Management) level.

SAP Infrastructure

It becomes obvious time and again how the complexity of SAP has evolved over the years. We analyze all servers utilized for SAP and take a look at precisely how these servers are used. Our many years of experience have shown that, in almost every case, the SAP infrastructure is cumbersome and as a result more expensive to operate than it should be. Further, we have determined that targeted optimization of SAP licenses, maintenance and operation are also worthwhile.

SAP Application Lifecycle Management

For our customers, managing implementation projects and upgrades alongside daily operations is a real challenge. SAP has taken a clever approach here as well, launching methodology initiatives such as Accelerated SAP (ASAP) in the past, and Run SAP more recently. But in our experience, these very tools benefit SAP more than the customer and are once again responsible for even higher costs. With this scenario, it makes sense to analyze precisely which tools actually help the customer and optimize their targeted usage to manage costs arising from external consulting and maintenance.

SAP Quick Check – lowers costs by up to 30%

During our many years spent consulting on SAP projects and with companies that run SAP, we have learned where these pain points lie and can identify them with a quick check. In our experience, we can reduce costs for SAP customers by 10-30% at little expense to them. But we don’t just perform an analysis, we support our customers in exploiting the potential we have uncovered. Because we are completely invested in our customers’ success, we will also consider performance-based agreements.

All of these systems tend to increase costs for the complete SAP solution. In many cases customers don’t even need to implement the recommended solution because they only utilize part of it, or none of it at all. This is precisely where the greatest potential lies in an SAP optimization as a whole: primarily in the SAP architecture underlying the entire system.

There were heated protests when SAP maintenance costs increased two years ago. But maintenance comprises only a small portion of the total cost. Why don’t companies and organizations systematically and consistently resist the constant, massive cost increases with SAP systems? Most customers are probably not even aware of the opportunities they have for SAP optimization. The optimization of SAP systems offers a hefty savings potential. You just need to detect and identify the pain points. It is interesting that no one seems particularly willing to tackle the subject of SAP optimization and cost management. User groups primarily share technical experience and usually focus very little on the business-related and financial optimization of SAP systems.

Interests within the SAP community ensure that the operating costs for SAP remain high, which is fine with the software producer and SAP service providers. SAP regularly delivers products and methods for SAP optimization under the guise of cost management. Unfortunately, this often achieves the exact opposite – SAP operating costs rise even faster. The main problem lies in the existence of the SAP “ecosystem.” The different players stick together in regular interaction, mutually generating new projects to secure their existence. Everyone wants to jump on the bandwagon. The more concepts and solutions SAP launches on the market, the more work there is for the ecosystem’s beneficiaries. But is that really the best thing for customers? The fact is, the investment and operating costs of SAP continue to climb all the time. In a cost analysis, SAP is compared with SAP – what else, of course. New cost drivers can be generated this way. Thanks to the complexity of SAP systems, many customers have lost their overview and become increasingly dependent on SAP. As a non-expert, recommendations from the SAP community need to be taken with a grain of salt anyway. You sometimes even encounter a certain arrogance in the SAP consulting world. Many consultants guard their expertise by not providing any specifications/documentation for their customization work. This practice seems to be standard in the SAP consulting environment, but such practices are considered simply unprofessional outside the SAP world!

The Run SAP methodology – one of SAP’s newer initiatives – is an example of a cost driver introduced by SAP. Certified consulting services usually based on SAP technologies are provided to SAP customers. SAP skillfully convinces customers to invest in and implement the Run SAP methodology. But if you take a critical look at the Run SAP methodology, you recognize fairly quickly that Run SAP primarily helps SAP – as the quintessential ERP standard software producer – retain its customer base with regard to SAP standard changes. SAP integrates new concepts for administering and managing solutions developed in-house (only ABAP, naturally) in the SAP Solution Manager. In our opinion, however, impact analyses of SAP customization would be more useful. After all, it is well known that customization comprises the lion’s share of effort in an SAP implementation.

Summary
The potential for optimization in SAP environments is enormous. A cost reduction of 10-30% is a realistic expectation for most SAP users. Members of the SAP community protect each other and are often not even interested in an optimization.

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/ 3 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 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.

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.

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!

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.