Who’s job is it anyway and other such things
Add-ons, Components and Confusion
Following on from my The Solman 7.1 Experience Slight Return blog and associated pain, it’s now time to look at some other issues that seem to hit the BASIS BUCKET.
Full Speed ahead
So your favorite sales team and Solution Architect have come up with the next big proposal. It all looks nice and sexy and works perfectly on PowerPoint.
You have, ERP, SRM, PI, CRM, Portals, and BusinessObjects the whole nine yards.
So the project launches, 6 months of blueprint and 6 months of implementation.
In an ideal world (would love to go there), blueprint would finish and all Non Functional and functional requirements would be captured. The technical architect can then get to work, design an appropriate landscape, will know the versions of software to install and all components that are required.
However, having swallowed the blue pill (remember the matrix), we are now in the real world.
The Technical Architect (TA) and Basis team start on day 1.
You look at the proposal and all it states is.
CRM, SRM, PI, Portal and BusinessObjects
So you get busy installing. You’ve even delivered some of the systems early. Pat on the back!!
As Technical Architect you can now get down to your real job, i.e. Designing the DR/HA solution, sizing the environment, creating all of the build specifications that are going to be passed to the hosting partner. A contract with the hosting partner is put in place and all seems to be going well.
Hit the breaks
Two months into the project and suddenly all hell breaks loose. The functional consultants are on the war path. They have finally logged onto the system.
“I need component XYZ activated”
“I need Add-on ABC installed on CRM”
“I need a portal that talks to the internet”
“I need……………”
Confusion
So you take a step back and ask the Solution Architect/Functional consultant to come up with a final list of add-ons and components that are required.
You are met with a blank stare and rolling eyes…….. “Isn’t that your Job?”
(Un)fortunately being technical I try to avoid functional stuff at all cost, I don’t pretend I understand the functional specifications and Process Design Documents. So I return:
“Isn’t that your Job?”
Now if you happen to have been working on a project with similar scope you may have second guessed what is required at install time. But in this particular instance I’m a virgin. But I am not the only one facing this issue.
So whose Job is it anyway? Answers on the back of a post card please.
Personally I think it is SAPs delivery model that is at fault there. Functional consultants and Solution Architects, quite rightly have no idea how technically the delivery model works. Likewise Basis, quite rightly have no idea about functionality.
There must be a better way!
Landscapes
You have now finally determined (more by trial and error), which add-ons and components are required and have created numerous change requests. Of course by now your landscape has changed as the blueprint has come to a conclusion.
It has been decided that you require a parallel development environment and associated QA environment, Pre-production training and of course production. So you now have a 7 environment Landscape with 10 or more separate SAP components per environment.
Due to data center policies you have to split the database and application server layers, maybe with a central services layer in-between.
Then you need to take client strategies into account. Java is not multi-client, so for every ABAP client you may need another portal instance.
All of a sudden you’re are looking at 150 different installs, with hundreds of (virtual) operating systems, Terabytes of memory and tens of terabytes of disk.
There goes my TCO
For a small SME type customer this size of landscape is very hard to swallow and could well make or break situation in terms of project success.
There must be a better way
Here are my ideas.
a) Multi-Tenancy ABAP: Why can’t I just have one big ABAP stack where I can deploy all of my ABAP based applications? We have a MANDT key on every table, Why not a SID key?
b) Client specific Java? Why can’t I have a single Java stack talking to different ABAP clients, or even have a client based java application?
c) Some proper guidance (not a paid for service) on landscape optimization, the current documentation of SDN and the marketplace is very old.
d) How about an auto deploy of Add-ons. Why not have an IMG that is auto updated from the Marketplace, so all functionality is visible.
If you decide you need a particular piece of functionality, it makes a call to SAP and auto downloads the required Add-on. That would the guess work out of the equation.