January 21, 2015

Digital Transformation: Top 10 Changes Through 2017

To navigate through the emerging IT landscape, chief information officers will need to completely reinvent themselves and their roles. If they don’t, they risk being supplanted by chief digital officers. This article looks at IDC’s predictions for the coming years.

The era of digital transformation has dawned: IT managers are evolving into cloud services brokers, more and more products are being bought and sold online, and Big Data is opening up compelling new vistas of analytical insight. While clearly a source of opportunity, the digital transformation of companies will not be plain sailing for everyone.
These are the key changes that businesses can expect to witness between now and 2017:

1. New tasks for CIOs

By 2017, say the IDC analysts, CIOs who wish to thrive and develop in the future will already be spending 80% of their time on analytics and cyber security and on creating new revenue models in the digital services sphere. Merely focusing on traditional IT topics like standardization and consolidation will put CIOs in danger of losing out on their privileged position at the company’s “top table.”

2. IT as a Service (ITaaS)

CIOs are seeing their control over technology spending steadily diminish. In fact, a recent Gartner analysis estimates that the proportion of technology spending outside of IT will rise to 90% by 2020. It is therefore vital for IT departments to style themselves as services brokers and prepare to meet business units’ requirements quickly and reliably. By 2016, says IDC, 65% of strategies will require what it calls the “3rd Platform,” which is built on a combination of “mobile devices and apps, cloud services, mobile broadband networks, Big Data, and social technologies.” As such, the third platform provides what Unisys’ Nicholas D. Evans refers to as an “agile new IT fabric for applications, data centers, and, most importantly, the user experience.” IDC refers to the new, third platform-based solutions as “IT as a Service” (ITaaS).

3. Cybersecurity will raise IT’s profile

Thanks to cloud computing, business units are increasingly opting to circumvent the IT department and “do their own thing” when it comes to implementing new solutions. Often, though, those business units have either little or no IT security expertise. This state of affairs will present CIOs and IT departments with an opportunity to strengthen their profile and their value to the company. Provided, that is, that they succeed in positioning themselves as the definitive go-to security specialists.

4. Accelerated application delivery

Increasingly, business units are drawing up their own technical agendas and calling on IT to implement them quickly and flexibly. By 2015, say the IDC analysts, more than half of businesses (60%) will be blending software development and operations roles and adopting the so-called DevOps approach to provision new applications faster. This transformation will also rely on third platform technology.

5. New architecture

By 2016, four out of five CIOs will deliver a new architectural model. Their main motivation will be to deliver services and applications quickly and in full compliance with security standards and thus respond swiftly to business units’ requirements – while at the same time proactively creating services by offering additional insight gleaned from new analytics options and Big Data.

6. The CDO will replace the CIO

By virtue of their superior strategy-setting, innovative, and relationship-building skills, chief digital officers will supplant more than half (60%) of CIOs in the c-suite rankings by 2020. Creating digital products relies not on the traditional strengths of IT – such as automating business processes – but on the ability to constantly reinvent and reimagine. IDC calls it going “beyond the comfort zone”. Innovative IT services will be the responsibility of CDOs working in collaboration with marketing and the business units.

7. Most CIOs will opt for third platform

Hyper-scalable: the 3rd platform
Hyper-scalable: the 3rd platform
By 2016, four fifths of CIOs will adopt the third platform technology as the foundation for creating new applications and services. According to IDC, the third platform has cloud at its core and offers solutions that can be accessed from any device, in any location, and at any time. Its success will hinge on whether the corresponding apps will be able to match up to rapidly evolving mobile devices and transmission speeds. Otherwise, businesses will not benefit from the full potential offered by Big Data analysis and social technologies.

8. Pan-enterprise data and analytics strategy

IT departments will come under increasing pressure to transform the mass of data that businesses generate into actionable information and insight. “Only transformed data is valuable data,” might well be the corporate slogan for 2018. Consequently, companies will need to implement an effective data governance strategy and integrate their entire stock of archived, new, and Big Data in a practical model that allows for complete data accountability and traceability.

9. Risk assessment will become more professional

IDC predicts that, by 2017, “more than a third of all vendor relationships revolving around third platform technologies will fail”. It is therefore essential for enterprises to conduct risk assessments of third-party relationships based on rulings such as the Safe Harbor agreement (established between the European Union and the USA to regulate the way that the U.S. handles the personal data of European citizens) and other compliance-relevant regulations. Due diligence checks will also be vital to avoid problems resulting from poor-quality third-party services, financial bottlenecks, business strategy changes, and planned acquisitions. These comprise checks on technological, financial, and IT security risks.

10. Open standards frameworks

Come 2018, every second company will favor an open standards-based IT infrastructure. This is down to the proliferation of mobile devices in the enterprise and to the fact that IT-based collaboration with external partners is becoming increasingly commonplace. Thus, IDC predicts, companies will pare down to the minimum the number of areas that require additional standards, compliance specifications, and governance structures. Embracing an open standards-based framework will also create an environment in which business units can experiment and develop their own solutions.
- See more at: http://www.news-sap.com/digital-transformation-top-ten-changes-2017/#sthash.4mYByH7k.dpuf

Is SAP HANA really multitenant?


In latest release (SAP HANA SP09) SAP released new SAP HANA feature – Multitenant Database Containers (MDC). I am personally excited by this news and I am seeing there quite a huge potential. But what are the real use cases for this feature? Is it making SAP HANA really cloud product which can be used to serve different customers? Or it is feature for one customer which can help him consolidate his workloads...

I am getting these questions quite often and honestly I did not yet formed my own opinion myself. Although this might be little illogical I decided to write a blog on this topic because it might be good way to draw some attention to this point and maybe (hopefully) trigger some discussion on this topic.

This blog is containing my own ideas and opinions – it is NOT reflecting opinion of my employer in any way.

Concept of Multitenant Database Containers (MDC)

MDC containers are nicely explained in many other materials, blogs and articles – so I will not attempt to document something what is already covered. For explanation I can point for example to SAP HANA Master Guide (page 25) available here: http://help.sap.com/hana_platform

In short – with latest SAP HANA release you are able to create multiple separate database containers which will be listening on specified ports and which will be independent on each other. This brings many benefits against traditional MCOD and MCOS deployment models (see SAP HANA Master Guide mentioned above for definition and explanation).

I would not hesitate to say that this new option might be seen as replacement for MCOD and MCOS making them obsolete and I would not expect big disagreement from the community.

Can SAP HANA be used for multiple customers?

But does this feature really replace virtualization? Can one SAP HANA installation be used by different customers? Is this concept safe enough?

Currently I would be very careful in deploying SAP HANA in this way. By saying this I do not mean it is not possible – all I am trying to say is that extra effort is required before such deployment can be used.

What is my main concern? Typically shared environments are offering very strong separation which is achieved on network level. Customers are really using same infrastructure however this infrastructure is configured in a way that network packet cannot leave from one tenant into another tenant - unless of course this is desired and it is intentionally configured – and even in such case these packets are traveling across one or more firewalls controlling that this traffic is really something expected.

This is very important for security because humans are very creative and they tend to find most unbelievable ways how to break into places which were (until that moment) seen as impenetrable.

Probably all hypervisors (including VMware) are offering this strong separation. Individual Virtual Machines (VMs) are having own IP address and hypervisor is ensuring that packets are delivered only to the particular VM which is expected to receive them.

Issue with SAP HANA being used by multiple customers is that such strong separation on network level is not possible. I have no reason to not trust SAP when they say that SAP HANA is internally multitenant. But I know for sure it is not externally multitenant on network level – it simply cannot be on its own at this phase. It is still one environment accessible by many customers. If customer can connect to one port (associated with their database container) then there is chance he might be able to connect to the other port which is associated with database container of different customer. At least this will happen if no additional actions are taken to secure such setup.

What could be done to improve such setup? Well after talking to different people I found that there are number of ways how you might increase the security of such setup.

For example you might encrypt communication channels and encrypt the storage to make it harder to access the data from other tenants. However this is not blocking the access to the other tenants – it is only making it more difficult.

Another alternative might be to put firewalls around SAP HANA to filter the traffic and to ensure that each tenant is blocked from connecting to ports (representing database containers) that do not belong to given tenant. This might be working solution however it is increasing the costs and overall complexity of such solution. Also might impact bandwidth and latency of particular flows spoiling performance. And last but not least – effort to automate such setup is increasing considerably.

Last area worth mentioning is openness of SAP HANA itself. SAP HANA is not “only” database – it is more than this – it is platform in which we can develop applications. However from security perspective this brings a lot of risks. I am not SAP HANA developer so I might be wrong here (and feel free to correct me here if you think so) but I can imagine smart developer coding application which will allow him to connect to port belonging to another tenant's database container which might be network flow not controlled by firewall because it is on same server.

Bottom line – I am seeing all options above only as obstacles which are making it more difficult for attacker to breach into database containers belonging to other tenants. And honestly at this point I do not know what is the best infrastructure architecture to securely deploy SAP HANA used by different customers.

And this is where I am seeing additional effort required. This is either something individual providers will have to figure out themselves or something where SAP can create reference architecture.

Of course it is obvious that such reference architecture would boost MDC adoption among various providers offering SAP HANA to their customers while absence of it will be strong inhibitor. And since objective of sharing workloads is motivated by intention to decrease the costs this will in turn impact adoption of SAP HANA itself.

Is there any smarter solution?

I am seeing approach I described above as very complex and not very transparent and I believe there is better option however SAP would have to step into the new area where they are not yet operating. This act might also have some drawbacks which were described in following blog: http://diginomica.com/2013/12/20/multi-tenant-multi-instance-saas-spectrum

Here I would like to outline that all descriptions below are my own speculations of what could be done to make SAP HANA truly multitenant. This is NOT what SAP suggested that they plan to do or what is on their roadmap.

In my opinion major improvement would be if SAP HANA would adopt some principles from virtualization – in particular Software Defined Networking (SDN) approach. There is no need to virtualize complete VMs – it would be sufficient to allow SAP HANA to associate each database container with its own IP address and then ensure routing of particular network packets to the right destination. In short it would be doing similar network service VMware hypervisor is doing to individual VMs.

On top of this SAP HANA would need similar options like VMware to define internal routing so that it is clear which database containers inside one SAP HANA installation belong to the same customer and are allowed to see each other and which are blocked on internal network level (inside SAP HANA instance).

Why is this critical? Because if done properly it will push down the separation between tenants to the network level (although virtualized) ensuring that no breach could happen on application level – and all this without the need to build overcomplicated network architectures.

It would also enable additional features which are seen in virtualized world (here I will use VMware as reference). I can imagine having similar features like vMotion – where database container could be moved to another node without any disruption – as IP address would remain same it could be stateful move completely transparent to external applications. Feature like VMware Distributed Resource Scheduler (DRS) where SAP HANA itself could relocate containers based on actual utilization and respecting preconfigured rules. Or features like VMware Fault Tolerance where container would be internally redundant preventing any disruption in case that one node will fail.

All this could be complemented by allowing differences in revisions on individual nodes – which could help to ensure that any updates are completely without any downtime – where nodes will be upgraded one by one and containers would be relocated without any disruption to the node with latest revision.

In summary such step might open quite a lot of options for SAP HANA where SAP HANA would become virtualization layer on its own – completely separating application (database container) from underlying infrastructure (hardware, OS, instance processes).

Summary

To summarize – I believe that SAP HANA Multitenant Database Containers (MDC) are interesting option how to consolidate workloads for large customers having multiple SAP HANA landscapes or in other similar situations where strong separation is not that critical.

On the other hand I am not yet convinced that SAP HANA MDC containers can be used (at least not out-of-the box) as shared solution for different customers on same SAP HANA installation. It might be possible – but not without very careful assessment of risks and creation of infrastructure architecture which would ensure full separation of individual clients.

I do not know how much is SAP ambitious with SAP HANA and if they really intend to turn SAP HANA into fully multitenant software but I am curious to see how things will develop with next releases of SAP HANA.

December 11, 2014

Architecture of SAP NetWeaver Application Server Dual Stack

SAP NetWeaver Application Server is the powerful foundation for the entire SAP software stack. It also provides a platform for other SAP NetWeaver components (for example, SAP EPSAP NetWeaver Process Integration), as well as for ABAP and Java applications (for example, SAP Business Suite).
The design of SAP NetWeaver Application Server is aimed at providing an exceptionally high level of robustness and supportability for the applications running on it. To be able to use the applications as independently as possible of the hardware environment, SAP NetWeaver Application Server Dual Stack consists of Application Server ABAP (AS ABAP) and Application Server Java (AS JAVA).
The architecture of SAP NetWeaver Application Server Dual Stack and basic terminology are explained below. For details, see the component-specific documentation.

Specifications of SAP NetWeaver Application Server
SAP NetWeaver Application Server can be installed in various specifications depending on the SAP product and applications used. A distinction is made between ABAP systems, Java systems, and dual-stack systems.

December 10, 2014

Concept of the Monitoring Architecture

The alerts are displayed in a tree structure in the alert monitor, and assigned a severity and a color (yellow for a warning, red for a problem). You can see the current status of your system and process alerts here. The alert monitor is based on the monitoring architecture, which was introduced in SAP R/3 4.0:
This graphic is explained in the accompanying text
The CCMS monitoring architecture is not a monolithic monitoring and administration program. Rather, it offers a flexible framework into which extensive monitoring and administration functions can easily be added.
The elements of the monitoring architecture function largely independently of each other and can, particularly, be further developed and adjusted independently of each other.
·  Data Supplier
data supplier is a program that delivers data to the monitoring architecture. It belongs to one of the individual system components and creates monitoring objects that report values to the monitoring architecture. The monitoring architecture is delivered with the data suppliers for the most important components of your SAP system and its environment and can therefore be immediately used.
Data suppliers pass their information to the monitoring architecture. The monitoring architecture provides an infrastructure for gathering and managing system information. The monitoring architecture therefore constantly compares the values reported by the data suppliers for the monitored objects with threshold values and displays an alert if a value exceeds or falls below a threshold value.
·  Data Consumers
A data consumer is a program that reads data from the monitoring architecture; it displays the information transferred to the monitoring architecture by the data suppliers. SAP delivers both the standard data consumer and other special monitors that all use the data delivered by the monitoring architecture.
·  Monitoring Objects and Attributes
A monitoring object describes an object that is to be monitored. A monitoring attribute represents a type of information that is to be reported for a monitoring object. Monitoring objects include, for example, the CPU in your host system, the database, and SAP services, such as background processing. Monitoring attributes for a CPU object could be CPU utilization and the average CPU workload for the last five minutes.
The alert monitor also provides the administration methods that you need to monitor the system. In this way, you can set threshold values for alerts and add or adjust auto-reaction and analysis methods: if an alert is triggered, auto-reaction methods react automatically, and you can use an analysis method to investigate the cause of an alert without leaving the alert monitor. The monitoring architecture also contains tools for administering and archiving the alerts.

SAP CIN Interview Questions & Answers

1.     How does CIN determine the tax rates?
CIN determines taxes based on the chapter-id of the material. There are 2 levels for rate determination. First the system will check if there is an exceptional rate available. If this is available then that rate is picked up. This rate could be for a material or material and customer combination. If there are no exceptions then the system looks for chapter-id of that material.  The customer will have an excise tax status, which along with the plant status will give a final excise status. Based on the excise status and the chapter-id the rates are maintained.
2.      Can I change the tax rates retrospectively?
You can change the excise rates with any given validity period. After making the changes you will have to update the sales orders if the new tax rates have to be considered for future deliveries.