BS7.0 and future technologies

[Former Member]

I'm been around the SAP block for a few years now, I've seen R2 and my first installation was on 2.1J.

Now SAP have releases BS7.0 what is the impact going to be on those of us how look after the system, upgrade,install and generally keep the whole thing running?

To me it looks like it may stifle innovation as we just cannot upgrade properly. Will there come a time in say 5 yeas where a major upgrade will be required which may well be impossible due to so many different components being at different releases?

What does it mean for innovation at the technical Layer. Not much has seem to have happened really over the last few years.

At 3.0 we had the new memory management, STMS.

Later on we had Java

But since then there has not been any real change at the "Basis" layer for a long time.

What has happened to "Secure Java" with the shared memory stack and roll in/outs to the jvm.

Whats happened to the idea of jvm's being integrated into the disp+work packages.

Faster installation methods, other than a nice fancy Java front-end not much has really changed and it still takes an age to install and patch. With so many components it has a major impact on implementations.

SAP used to pride itself that all admin function were in the same place. Now you have solution manager, Portal, Redwood (for job sceduling), all the multiple components that go with PI7.0

Discuss!

[markus_doehr2]

I'm been around the SAP block for a few years now, I've seen R2 and my first installation was on 2.1J.

Now SAP have releases BS7.0 what is the impact going to be on those of us how look after the system, upgrade,install and generally keep the whole thing running?

I personally see not such a big change in BS 7.0. The major change to ERP 6.0 is - to my understanding - the usage of the switch framework to enable specific functionalities. Apart from that there´s no so much difference in the "core" if we focus the view on ERP 6.0.

To me it looks like it may stifle innovation as we just cannot upgrade properly. Will there come a time in say 5 yeas where a major upgrade will be required which may well be impossible due to so many different components being at different releases?

The dependency thing between components is one big major issue, I would even go as far as saying that this is the issue when running SAP installations. I heard a speech where a PM of Netweaver told us, that the development was assuming up to Q3 last year, that each time a new release or support packages comes out, all customers implement as soon as the CDs arrive at their place. They build new functionality only on top of the latest release and latest support packages. That is, how we all know, not true, the contrary is the case.

But since then there has not been any real change at the "Basis" layer for a long time.

What has happened to "Secure Java" with the shared memory stack and roll in/outs to the jvm.

The problem here is, that the actual production versions run on top of an ancient Java version (1.4.2). Sun holds the license for that and there´s not much SAP can do about it but deal with it. We saw now recently the big discussion about supporting such an old Java version on new operating systems such as Windows 2008.

Whats happened to the idea of jvm's being integrated into the disp+work packages.

This happend - and is already used in e. g. CRM for the pricing engine. They call it VMC (VM Container). If you have a look at a 7.00 kernel directory you will find a Java runtime there. However, it turned out to be not that easy to maintain and configure and I think that´s the reason why one didn´t follow that approach for other products.

Faster installation methods, other than a nice fancy Java front-end not much has really changed and it still takes an age to install and patch. With so many components it has a major impact on implementations.

SAP used to pride itself that all admin function were in the same place.

You´re right to some extent. But I think the latest sapinst became a very good tool for installations. If you of course use the default for an ERP installation, it will take ages. With some experience on that side you´re able to install systems pretty quickly. Since the SR2 releases of the installation media I haven´t had any bigger problems that I wasn´t able to solve myself.

Our upgrade from 4.7 to ERP 6.0 was one of the smoothest and best upgrades we did. If I think back to the past (2.2x or 3.x times) and compare this to today, they did improve the upgrade process majorly bar the fact, that systems are much more complex today.

Now you have solution manager, Portal, Redwood (for job sceduling), all the multiple components that go with PI7.0

Personal opinion: SolMan could have become such a good tool - but it drifted too far away from its original goal. SolMans base is CRM and that´s the main culprit. It can´t be more complex than it is today. I have the impression that it´s still very experimental, coming right out of the development and WAY too complex to setup and maintain itself. We had internal discussions - also with consultants - and it turned out, that we would need an additional person in the IT to run and maintain a SolMan if we wanted to use it as it was originally positioned, let aside all the dependencies in the connected systems that need to be taken care of.

Redwood is a VERY good tool but since it runs on our database (MaxDB) only as Java application we don´t dare to use it in production (burned child dreads the fire).

All in all I think: you cannot get rid of complexity, no matter which tools (SAPs or external) you use. We, the administrators, will have to deal with that.

Markus

[Former Member]

I agree that the upgrade functionality has improved majorly (unless you have some SAP pre-release code in the system in the SAP namespace but not owned by SAP as no tools find the software before the upgrade).

I've used the sapinst tools to their fullest, but the concept of loading the database with such large amounts of data just takes a long time.

Why not deliver a fully built DB (similar to SQLservers de-tach/re-attach). Copy the files down, script to rename the database. Finished

Why does SAP not push the concept of MCOS (Multiple components one system), perfect for SME.

One 4way box, one DB and maybe a bunch of App servers in prod is all you should need.

[markus_doehr2]

I've used the sapinst tools to their fullest, but the concept of loading the database with such large amounts of data just takes a long time.

Why not deliver a fully built DB (similar to SQLservers de-tach/re-attach). Copy the files down, script to rename the database. Finished

Because not everyone in the world (thanx god!) uses Windows and SQL Server. Check how many database SAP supports (and their different versions), together with all the OS combinations, together with endianess differences... it´s just not possible. I think the R3load approach is pretty good, one DB export independent of the database and OS.

Why does SAP not push the concept of MCOS (Multiple components one system), perfect for SME.

One 4way box, one DB and maybe a bunch of App servers in prod is all you should need.

I´m not sure if that would scale. For smaller customers this may work, however, a machine running e.g . 120 processes for one applications has a total different scheduling/scaling behaviour than a box with 500+ processes. And the MCOD thing has proven to be not the best (during upgrades/patch installations etc.). It has all pros and cons - sure, it always depends on your requirement.

Markus

[Former Member]

This is were the partner community should be more involved. Yes the R3load process works well, but it puts a very large overhead on projects, generally requiring anywhere between 12 and 24 working hours to install (depending on hardware). And generally DEV kit is not that highly specified and is usually required yesturday.

SAP does not support that many DBs

Oracle

DB2

SQLserver

MaxDB

on different platforms

Surely it does not take that much efford to install everything up front on different servers. Burn the DVDs as file copies and have a script that does the re-naming of the database SID. This should be up to the partners.

Is MCOD really that bad (as long as there is a migration route from MCOD for scalability). With the advent of Support Stacks, all components should be on the same database release anyway.

Note. Cloud computing is coming. Deploying SAP into a cloud using R3load will be a no-no.

[Former Member]

In the lifetime of an SAP project, 12-24 hours to build a first DEV system isn't that big an impact. After a customer has built one, then they can use virtualisation tools to make extra copies for their own use which can be recovred in short times...The advantage of the custoemr doing it is hey can pick things like the languages to import, do some basic post install steps etc and make sure the disk layout meets their own requirements...

[Former Member]

You say that 7 to 12 hours is not that long. However the cost can be quite significant to a customer (I work for a consultantcy company).

When we sign a deal, the customer generally expects to get going ASAP.

First off, kit needs to be ordered, racked up storage attached. This can take a few weeks/months in itself.

Then the Basis guys start. A landscape with

ERP, CRM, SRM, BI, PI, Solman and portal, generally takes 3 or 4 good basis guys about 3 to 4 weeks to install, tune, maybe patch (sods law says a new SPS will appear just after install), get the systems talking to each other, getting the backups working, etc, etc.

Typically the installation alone will take 5 days with 4 people with such a large landscape. (Especially if we do not have root access, which is more and more common).

That is a cost of typically, £20K. It seems small but these days customers and consultancies are looking at reducing all costs.

We for instance are looking at a rapid startup regime. We already have a master system built. We detach (sql server), reattach and do the java import. We even have all the RFC destinations defined (why can't SM59 be moved into the SLD, grrr).

A whole landscape is deployed in two days into vmware partitions.

Production I agree is should take along time to build as performance/scalability/stability is key.

[markus_doehr2]

> SAP does not support that many DBs

> Oracle

> DB2

> SQLserver

> MaxDB

> on different platforms

to be precise:

DB2 for Linux, Unix and Windows

DB2 for System i

DB2 for System z

On top, backups are endian dependent, you can't import an Oracle backup to a Windows machine and vice versa, same is true for MaxDB.

Basically that "dump" is used in Java installations, you see how long it takes to import a 500 MB dump...

> Is MCOD really that bad (as long as there is a migration route from MCOD for scalability).

Imagine you do a SP or Ehp installation on one component. You can't switch archiving off since there are other production instances running. You will need a LOT of space for transaction/archive logs...

Markus

[markus_doehr2]

> First off, kit needs to be ordered, racked up storage attached. This can take a few weeks/months in itself.

> Then the Basis guys start.

This is not a SAP issue

> We for instance are looking at a rapid startup regime. We already have a master system built. We detach (sql server), reattach and do the java import. We even have all the RFC destinations defined (why can't SM59 be moved into the SLD, grrr).

> A whole landscape is deployed in two days into vmware partitions.

If you and the customer uses VMWare - yes. VMWare itself is a huge cost factor.

Each customer has its own requirement, I would e. g. never install Java Addins to ABAP installations (hard dependencies!), other customers maybe able to live with that; one does install one Portal, others use Federal Portal Networks due to the different applications that can't run together etc. etc. So there is no one-for-all fits solution because each customer has different requirements/scenarios.

Markus

[Former Member]

Space is cheap, compared to admin time, especially in the SME area.

A typical MCOD type customer would generally have downtime for the whole system at the weekends anyway. Backup/switch off redo logs/Apply SP/Backup Switch on redo logs.

In most cases you have to take the other apps down anyway. Often SRM/CRM can't much without the ERP system being up anyway.

[markus_doehr2]

> Space is cheap, compared to admin time, especially in the SME area.

You think so?

> In most cases you have to take the other apps down anyway. Often SRM/CRM can't much without the ERP system being up anyway.

Yes - true. But what about e. g. system copies? You will "destroy" you whole landscape if you copy systems since you always copy all - and need to regenerate all connections, just not that of the system you copy...

As I said - depends on the requirements. For smaller customers this may be the total best way. For us it would be a nightmare.

Markus

[Former Member]

I hear what you are saying. However when it comes to development/Sandpit environments the deployment methology is very different. Half the time we are doing the technical design during the blueprint and often realisation (customers never know what they really want).

I just feel there is not that much innovation around the whole deployment methodology and making the job of the Basis consultant easier and more importantly quicker.

We have enough on our plates having to deal with virtualisation, backup technologies, unstable JVMs (service.sap.com being a prime example of how unstable it can be) and all the application specific issues that usually hit the BASIS BUCKET.

Other things I'd like to see. Live migration of SAP from one server to another (probably more of a problem for the DB vendors).

Centralised RFC/logical system (this is at the moment a big pain, with each type of SAP system using different users, naming conventions, etc)

Meaningfull error messages in Java (OK need to kick Sun on that one)

A proper Centralised CCMS/Java monitor/alerting/problem management system, that does not require CRM knowledge to setup.

[Former Member]

Is it not SAP's recommendation to copy an entire environment not just individual components?

[Former Member]

>SAP does not support that many DBs

>Oracle

>DB2

>SQLserver

>MaxDB

>on different platforms

I don't really understand your statement...how many databases do other ERP vendors support? Say, one in Redwood Shores?

>I just feel there is not that much innovation around the whole deployment methodology and making the job of the Basis consultant easier and more importantly quicker.

I work in the SAP NetWeaver RIG, which interfaces greatly between the field and development. I completely agree with you, and this is a well-known issue. Strategically, we plan to focus on making the lifecycle management tools and procedures better. I used to be a Basis consultant, so I can feel your pain. Trust me, we make our voices known to development about this on a regular basis. There is no "magic dust", however, and development does take some time. I am not in a position to make promises, but I believe it will get better in this area.

>Other things I'd like to see. Live migration of SAP from one server to another (probably more of a problem for the DB vendors).

This is being explored in the virtualization/Adaptive Computing area...perhaps we will see this one day. VMWare claims that they can do it with VMotion, but I have not seen it so I am not aware of its limitations.

[former_member110461]

Other things I'd like to see. Live migration of SAP from one server to another (probably more of a problem for the DB vendors).
This is being explored in the virtualization/Adaptive Computing area...perhaps we will see this one day. VMWare claims that they can do it with VMotion, but I have not seen it so I am not aware of its limitations. 

I've seen an SAP system moved from one VM server to another without any issues - no dropped connections, no update failures (I was running the update test program at the time to try and prove a bet that it would fail!). Was very impressive. Whilst it isn't quite a migration in that it is a pure copy, it is still impressive.

Fenton - you're causing chaos as usual I see

[JPReyes]

Moved to Coffee Corner

Regards

Juan