Discuss business intelligence, integration, compliance and a host of other SAP-related topics – implementation, best practices and resources to negotiate the world of SAP better!

« January 2013 | Main | March 2013 »

February 27, 2013

BW on HANA TCO - Part 2

By Adam Zeckel

Principal - Business Consulting; Energy, Communications and Services Unit, Infosys

In Part 1, I explored the cost components relative for potential IT cost savings by moving to Business Warehouse (BW) on HANA. In this part I will expand on the three major cost categories: labor, software, and hardware.


The first significant piece of savings comes from labor. With BW on HANA, there are fewer developed objects due to streamlined architecture and faster load times during development, testing, and deployment.

Estimates from SAP and several existing customers show that this adds up to a 20% reduction in effort required to develop and maintain the data warehouse on an annual basis. Because many of these efforts include contracted workers, that savings is easily converted to the bottom line.


The second major area of savings comes from hardware. The growth in SAN space required is largely due to the "old" architecture standards for BW. Data is stored in many different layers on the data warehouse. PSAs are growing and there are layers for staging, corporate history, levels of integration and aggregation. Also, IT organizations often support multiple "production sized" environments for testing, training, performance, etc. The growth of data is then amplified across the landscape.

For BW on a legacy database, this is business as usual. If data were to corrupt or an error were to be found, it's much better to have an intermediate step to recover from as opposed to having to pull millions of records from the OLTP system - a process that can take weeks and affect the performance of the source.

With HANA as the database, such a high level of data redundancy is no longer needed. Loads run much faster for recovery. Also, the query performance is dramatically improved so users can query directly from staging layers without needing the additional layers of aggregation implemented for performance. Other features like indexes and aggregates are also not required.

Not only is the compression rate in HANA much higher, but near-line storage is a perfect complement to HANA. A mature BW environment with 5+ years of data can utilize near-line storage to limit the net add of transaction data into the warehouse.

With data growth, additional database servers are required to meet loading window SLAs. Similarly, BW Accelerator blades must be added to keep up with the growth of data. Moving to HANA allows organizations to avoid these costs.


Finally, software costs associated with moving to BW on HANA are certainly more than in the steady state BW environment. This includes both software licensing for HANA and for near-line software. However, organizations can avoid the cost of additional BWA licensing required to keep up with data growth. It's important to remember that software is only about 20% of the TCO equation.


With all the components of TCO for BW added together and compared to BW on HANA, it's clear that the future state in HANA will provide significant savings for IT organizations. Depending on the size of the implementation, moving to BW on HANA can have a payback period using IT benefits alone of less than 3 years. This analysis doesn't even include the less tangible business benefits that will undoubtedly enable business processes that are interrupted or delayed by timely access to data.

February 24, 2013

What's your mobility quotient?

In his keynote on the BlackBerry 10 launch, Thorsten Heins, the CEO of BlackBerry (or erstwhile RIM), talked about the transformation to mobile computing from a mere mobile communication. In this space of mobile computing, the mobile device is always on, connected simultaneously to personal and enterprise worlds and enables a seamless user experience reliably and securely. The BB 10 and its ecosystem of partners and developers is already moving in the direction of mobile computing and so are others among the wide gamut of stakeholders in enterprise mobility.
However, enterprises themselves seem to be a little out of step with the movements in enterprise mobility. The thinking within the enterprises seem to be traversing a whole spectrum of perspectives on what mobility means for them, what is the priority of being mobile and when do they start being mobile. Mobility quotient could be a term which can describe the appetite of enterprises to deploy and embrace mobility.
If one were to gauge the mobility quotient of enterprises at this point, one would stumble on the following clusters of enterprises:
    • Low quotient enterprises: Many such enterprises would have analyzed mobility but would have stopped short of implementing it because of a variety of reasons like budget constraints in a difficult business cycle or prioritization of other IT initiatives over mobility. Others would have felt that technology is still not mature enough to deploy mobility in a cost effective, predictable and timely manner. The rest could have perceived mobility not leading to significant productivity or competitive advantages. This cluster of enterprises are more or less in a wait and watch mode and quite unsure of mobility from multiple aspects.


    • Medium quotient enterprises: It would be interesting to look at what mobility means to some of these enterprises. The ability to access SAP screens or providing approvals from a tablet via VPN while sitting in a cafeteria, 200 km away from the office would seem to be an important step towards mobility for some organizations. Others may provide minimal provisioning of handled devices for managers who are able to approve leave requests or purchase orders on the go. The user interface may not be very important even if the screens on the handheld device needs frequent scrolling. Data security would be a paramount concern to many such enterprises. Many of these enterprises would have mastered the provision of access and transactions to employees and business partners over the Internet, where they can control identity management and data security with independence and without the need to control the devices being used to access. But with mobile devices and an "always on" access, its even important to control who is using the provisioned device and that the device cannot be used for anything else but for the access function to the enterprise. A lot of users belonging to such enterprises would carry an official as well as a private hand held device. 


    • High quotient enterprises: Enterprises in this cluster value the productivity of their employees or an anywhere anytime customer connect as critical for their competitive advantage. a lot of the business functions used in the ERPs of these enterprises are "applyfied" or mobilized as applications suitable for smartfone access. Salesmen can give realtime quotes to the customers for a customized product configuration , marketing coordinators can order a promotion event as soon as they negotiate prices with their supplier sitting in his office, accounting clerks can push the workflow forward by inserting missing invoice data as they travel in a subway, HR vice presidents can access the attrition report as they address an off-site meet or the customer can pay his EMI quite late in the night. The hand-helds simplify the tasks of employees, decrease training costs and boost productivity. Enterprises are beginning to move into this cluster as they become more sure about their costs, security and the benefits when they embrace mobility. Many employees in these enterprises are bringing their own devices as the enterprise becomes more device agnostic and the focus shifts on mobile application management rather than mobile device management. The employees device provides him or her the same level of experience in his professional and private worlds and he can easily switch between the two on the same device.

Enterprises could find themselves internally at different mobility quotients based on use cases which are prevalent across different parts of the enterprise. The challenge is to articulate a common minimum mobility strategy which finds resonance with organization wide objectives and needs. In the enterprise history when the ERP, e-business and Internet commerce was first embraced, the enterprise was ahead of its employees and customers, who took baby steps in learning and working with these systems. The tables are turned this time. The employees and customers already know how to leverage their smartfones to conduct personal transactions on apps, on the go, while the enterprise trails them.

More often than not, the CIO is pondering over his business context, tasking teams to explore mobility proof of concepts, getting consultations from product vendors, but still not able to state his mobility quotient. The viewpoint in these situations could be blinkered by a narrow set of parameters defined by IT based on past TCO experiences, but could discount important usage imperatives coming from the employees, customers and the business partners. A synthesis of perspectives on mobility can well determine how much mobility does the enterprise need and by when is it needed. Experienced consulting organizations like Infosys have enabled many an enterprise to build up their strategies and embrace mobility in a way which is best suited to the enterprise. 

February 14, 2013

Why consumers don't want a smart meter

The term smart meter usually refers to electric meters which keep detailed statistics on usage, but it can be used for gas or water meter as well performing the same job. Additionally, a lot of smart meters can also perform telemetering, in which they interface remotely with utility companies. Smart meters have been around for years. National governments have always been in favor of making them mandatory for every household, but among the consumers the controversy has never been this big.  This article is written from a Dutch utilities perspective but the reasons can be considered on a European level.  The advantages of this technology versus the drawbacks for the consumers.

Privacy issues

The greatest reason for protest lies in the privacy issues that smart meters could carry. Usage information of the households are stored with the energy companies. How much energy a household uses, when it is being used and for which reason it is being used will be shared with your energy company once a smart meter is installed in your home. This data is then used by them to make better estimation of energy buy-in and production, which will then lead to cost advantages. Whether this advantage is carried forward to lower prices the consumer is to be seen, but at least the customer will not experience the problems of estimating consumption and backbilling any longer.

Against these advantages for the energy companies and a possible reduction of energy prices is the drawback of sacrificing your privacy when this information is shared. Advocates of the smart meter say that the data will never be looked at in such a detail. But we can clearly see the parallels with for example what Google is doing with data on internet behavior of their users.  Google uses information of its users on how they use browse the net, to offer them so called 'interest based advertising'[1]. It is also Google that is a major supporter of intelligent meter reading. In the recent past the company worked on a energy monitoring tool that would give consumers access to their energy information by storing this information in the cloud. Even though the project has stopped, we can imagine the debate on the commercialization of information by Google that could have started was this program rolled out.

Most people aren't bothered about receiving targeted adverts. Even if this is based on internet behavior. Why should you be bothered? You have nothing to hide? But most people could lack seeing the big picture. Sharing energy usage information could show when we are home, when we aren't, when we sleep, when we are awake, what we use and thus tell us what we need.

Cracking the code

The energy companies aren't the only one that will have the possibility to know whether you are home or not. Smart meters communicate their reading via internet connections or straight through the electricity network. This gives malicious parties the opportunity to crack the meter remotely, without notice of the user. Even with encrypted technology securing the connection, one cannot pass the thought of hackers breaking through firewalls. Dutch energy companies have started rolling out smart meters already 5 years ago and have not seen much malicious hacking activity performed as of yet. The risk of eavesdropping and outside tampering is considered by them as low. But the number of installed smart meters is also still low; the market might not be an attractive target for criminals yet. European legislation states that in 2020 more than 80% of household will have a smart meter. By then the market will have critical mass for illegals to break the code, read your current usage and then, for example break into your home. But the impact could be bigger than this. Energy companies intend to shut down energy supply from a distant if the customer is a bad payer. You can imagine that if this power is in the wrong hands, whole neighborhoods can be brought to a standstill within seconds.

One might think that communication via the electricity network instead of over the internet could be safer, as this is owned by the energy companies themselves. But this is also a false security. With special metering devices connected to another socket, signals can be picked up and tampered. Electromagnetic radiation can also be detected and interpreted.

Slow government

The national authorities are obviously protecting the privacy of its citizens. Bills adapting to the arrival of smart meters have already been proposed, but even 5 years after the installation of the first meters, only certain legislation have actually passed. This has made the energy companies reluctant to install smart meters on a wider scale. Only in certain situations, such as new build, renovation and during regular meter replacement, does a smart meter have to be installed. A mass roll out is not expected until 2014. Which functional requirements a smart meter will have to meet (what it reads, how the data is passed, what information it should provide) has only been proposed to the Dutch house of commons[i], but has not been discussed yet.

Commotion was stirred up initially when the original bill also obliged households to install a meter in their homes. Installing the meter wasn't only mandatory, it would also accompanied by coercive measures. According to the bill a non compliancy could result in a 6 months imprisonment and a 17000 euro penalty. Meanwhile the house of lords has rejected the plans for an obligatory installation, but damage to the image of smart meters has already been done.

We can conclude that the consumer is all but ready to be sentenced to loss of freedom and privacy. More importantly, there is still a certain lack of information provided to the consumer, what is and is not possible once this intelligent meter is placed inside their homes. Until that time, the roll out is slow and only for the voluntary.



The pitfalls of Agile software development

Since the late 1990's several methodologies for developing software have begun to get increasing public attention. Each had a different combination of old and new methodologies or were evolvements of old methodologies. But all emphasized on close collaboration between the technical team and the business experts; face-to-face communication leading to short communication channels and less misinterpretation of expectations. Software is delivered on a more frequent basis and each delivery has business value in mind. Teams are self organizing; roles are clear but also interchangeable and no hierarchy exists.

In 2001 a group of 17 independent minded practitioners of programming methodologies met up to come to a consensus around the main values of their methodologies. These values were recorded in what is known as the Manifesto of Agile software development[1][1]

·         Individuals and interactions over processes and tools

·         Working software over comprehensive documentation

·         Customer collaboration over contract negotiation

·         Responding to change over following a plan

In this article I would like to cover the failures that I have experienced in the Scrum development methodology at our customers development and what could be done to improve the process. Scrum is one of the Agile development methodologies that uses time boxed effort, known as Sprint cycles, to develop a working increment of a software. Sprint cycles (usually) last 3 weeks, in which requirement analysis, development, testing and documenting are all being performed. Which requirement are to be build in a Sprint are determined from a Product backlog (pool of user requirements) determined by the user community and moved into the Sprint backlog for planning. Each item on the Sprint backlog is called an Epic and can be narrowed down into separate pieces of coding called Stories. In order to determine the effort for bringing each Story live, Pokering takes place, determining how many Stories can be handled within a Sprint with the available resources. Every day team members gather in a Standup to discuss the work done yesterday, the planning for that day and possible impediments, in order to track the progress of each Story. After 3 weeks a review takes place of the work that was completed and not completed and a go/no go decision to Production is made. Finally in the Sprint retrospective all team members gather to discuss the past Sprint in a Retrospective, determining what went well and what the improvements are for the next Sprint.

A three week period between start and end of a project sounds like a dream to every customer. The thought of having a working product in such a short timeframe means that the end user does not have to wait months for there requirements to be delivered and the change list is not frozen from the start. In reality, a three week period is just sufficient for a small piece of software to work, sometimes as limited as a one line code. Major projects such as the European payment system (SEPA) or the New Market Model in the Netherlandsare comprised of multiple large changes, that relate to different systems and have a big bang go-live. Although the Scrum methodology foresees these scenarios by breaking down large changes in small Stories that are finally merged into one grant product, successful merging requires the same planning and management that is performed in the traditional Waterfall model. And because the changes are big and complicated, a three week period is not sufficient to design, build and test the whole solution.

Agile is about customer centricity and responding to change. One would think that understanding the customer is key to achieve these goals. Often the Agile team will therefore accept a request for change which is stated in high level description. "We want a page with a comprehensive customer overview" or "We want this page to run 50% quicker". Existing waterfall methodologies would not work if requirements are stated in such a vague manner. But as Agile prescribes the user representative to closely work with developer, the requirements become clearer and sharper along the way and the end product becomes exactly what the user had in mind in the first place. One can imagine that a lack of clarity from the start can lead to development going overtime and over budget. Or when a strict 3 week development cycle is kept, the software can be instable due to reduced testing time. What was expected to be a simple change could end up as a major unforseen effort.

One of the philosophies of Agile is working software over documentation. That sounds like music to the ears of a developer. Just build, build, build and we'll see about the documentation later. Unfortunately, documentation is best written when it is fresh in the mind. When documentation is written after go-live of the software, it is often seen as a hassled task and is often forgotten. For the maintenance team taking care of the software after go live, this is far from ideal. There is most of the time a lack of knowledge transfer between the developing Agile team and the maintenance team, causing discussions of what is and what isn't the task of the development team when it comes to the handover. As the Agile team is on a tight 3 week schedule of delivery, documentation can be of bad quality. Whilst Agile manifesto is saying that "Working software is more important than comprehensive documentation" it is actually trying to say that it "prefers" working software over (not abandon) comprehensive documentation. Try to create working software, because this is the only thing that adds value to the customer's business and not the extensive documentation. Still, useful documentation is to be delivered.

"Failing to plan is planning to fail" is often said. And with Agile's fundamental value of responding to change over following a plan, makes Agile an unstructured and short term thinking methodology. How does 3 week Agile delivery fit in a corporate strategy that is often months and years planned ahead? Requirements come from business users who only deal with day to day issues, which can only put a plaster on the wound but does not bring long term value to the organization. That is why product plans often comprise of change request that can not be legitimized by corporate goals and often have an exaggerated business case, saving thousands or even millions, but really will not.

Agile just cannot be seen as the magic trick that will solve all issues in software development. Its pitfalls are numerous and the criticism on its predecessors are not fair. We cannot leave out planning just because we want something as fast as possible. If we want to deliver long term value, two broad categories of planning should always happen[2][2]:

1.    Selecting which initiatives should be funded - doing the right work.

 2.    And once a project has passed the "should we do this?" filter we need to focus on doing the work right.

To achieve this we need to plan at many levels.

Innovation or problem: Every organisation needs a mechanism to get work into the pipeline - idea generation needs to be encouraged and problems identified. At the initial idea/problem generation stage there should be very little filtering, every member of the organisation should be able to point out something that is not working in the most effective way, identify a problem the organisation needs to address or propose a completely new thing that could be done.

Portfolio Planning: Portfolio planning is a governance level activity which is about selecting the right programs and projects which the organisation should fund at any given time. Deciding which work to undertake should be based on the organisations mission and goals - work should only be funded that delivers on the strategy set at the highest levels in the organisation.

Program Management: A program requires additional coordination to keep the interrelated streams of work synchronised. The program manager should be a dedicated role who has the strategic view of all the streams of work that must come together to deliver to overall program. The program manager provides the unifying vision for the separate project teams who will work on different streams of work.

Articulate the Vision: teams need to gain a clear understanding of the goals and objectives that have driven the selection of this project to be worked on. Team members often don't understand why they are developing what they are developing. Stewardship of the product vision is the responsibility of the product owner - this persons main responsibility to the team is to explain the why question.

We can conclude that to make Agile a success it cannot remain a single level project execution methodology. Putting the development team central will only work if we only aim for short term value. To succeed in an ever changing environment, corporate level planning is still required to ensure end-to-end impact. And that is why Agile is not just a 3 week development methodology, but is also a continuously adapting management process.



February 8, 2013

SAP... setting a trend of quicker, leaner & agile adoption.

Traditionally, the very thought of Enterprise Applications often struck a chord with several aspects large-scale: time-to-awareness, time to evaluate, installation infrastructure, implementation time and cost, to name a few. All in large scale - one of the main reasons that majority of the consumption came from relatively large enterprises. In recent times, however, this tradition has been seeing a fast disruption, in the world of SAP, through innovative software packaging models & effectively leveraging more recent technologies.

SAP, with its slew of strategic moves such as Rapid Deployment Solutions (RDS), unification of Mobility platforms, HANA-based solutions, host of On-Demand solutions plus the Cloud-based offerings (eg. HANA-one as well as the aforementioned solutions), is setting a new trend in customer adoption of its solutions. The trend, when seen holistically, is at a convergence of these offerings potentially giving an exceptional advantage to clients across three key dimensions: quicker, leaner & agile.


Agile Trend.pngHere's a bird's eye view of what drive this trend.

- Transparent promise of fixed scope, time & price

- As a norm, the implementation timeline is capped at 12weeks.
- Aimed at significantly improving the ratio of software cost to implementation cost
- Cloud RDS offering enables test-drive and jump-start, and allows migration on-premise
- 100+ packages and growing

On-Demand (OD) Solutions
- Wide range - Business One, Business ByDesign, BO-BI-, Customer-, Sales-, Financial-, Travel-, Social-OD to name a few
- Allows picking in proportion to the business needs and investment plans on hand

- Suitable for large enterprises too to test-drive or/and adopt specific solutions
- Lean enough to adopt specific solutions under different business situations (e.g. addition of subsidiaries or creating POCs etc.)
- Cloud-based OD offers high agility to test-drive and adopt in an economical way

- Helps minimize upfront Capex
- Moderates the need for specialized staff to operate
- Enables high agility for IT to respond to business needs
- Offers high scalability vis-à-vis business growth & expansions of enterprises
- Enables quick test-driving of technology platforms (e.g. HANA, SUP, etc.) & solutions (OD) & jump-start adoption in an easy & low-cost fashion
- Wide range of partnership options and cloud strategies (public, private, hybrid, etc.)

This trend potentially empowers customers (SMEs or otherwise) to virtually cherry-pick & embrace solutions with more freedom and agility, in relatively quick & economical ways. Interestingly, this is fast becoming a field for various consulting & technology players such as Infosys to leverage the convergence, make a differentiation and bring value to their clients across the three dimensions.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter