What’s wrong with Solution Manager 7.1?
Solution Manager 7.1 has a lot of interesting features and going forward I do believe Solution Manager can play a significant role in the SAP system landscape.
Being positive matters to me and that’s also why I want to stress the fact that I don’t dislike Solution Manager, far from it. This blog post is a result of me caring about this product. I’m reflecting upon what is being said in the hallways and what no one seems to be articulating in public. If no one provides this feedback, how do you expect to see things change over time right?
The recommended landscape for SAP Solution Manager consists out of a SAP system landscape with three SAP systems (see picture 1.0). Respectively: development, acceptance and production.
A lot of customers are still running with one or two Solution Manager system(s) though. A landscape with at least two Solution Managers is recommended because of the frequent maintenance that Solution Manager needs. Doing maintenance on a landscape that consists out of a single SAP system has it’s risks of course.
So what’s the big deal then?
The problem is that the landscape strategy is not taken into account by many scenarios. A two or three SAP system landscape works fine for scenarios like Service Desk and Change Request Management. However, the landscape strategy is not geared towards using the technical capabilities of SAP Solution Manager.
A typical example is Change Validation Reporting. What do you want to check for example, is that all the systems that belong to a certain system landscape have the same kernel level. This means that all the managed SAP systems that you want to compare to each other have to be connected to a single Solution Manager. It’s just one example out of many examples. In the end it requires you to have all of your managed SAP systems connected to a single Solution Manager if you want to benefit from the functionality that is being provided. Not just the systems using RFC connections but the diagnostic agents have to be connected and that means that you cannot connect them to another Solution Manager because you can only connect an agent to one Solution Manager.
If you follow the recommendations you have two or three Solution Managers running and each Solution Manager has its own Wily Introscope installation (see picture 1.0). Most customers end up with a landscape that looks like the visualization in picture 1.1 because that’s the only way you can actually use all of those neat features like Change Validation Reporting which can serve to be very useful.
Instead of working this way SAP could provide ways to connect development to development, acceptance to acceptance and production to production. Then provide the option to use scenarios like Configuration Validation reporting across the different Solution Managers (see picture 1.2). Instead of creating two almost dummy like Solution Managers in terms of technical scenarios you could end up with three medium sized Solution Managers instead of one huge productive Solution Manager.
Diagnostics Agent strategy
Starting from Solution Manager 7.1, diagnostics agents are really needed to get your managed system setup performed properly. It’s the only way you can get a green traffic light although other issues exist to help prevent the customer from getting the green lights on.
Does it make sense to have diagnostic agents installed everywhere? Yes and no. Yes because it enables you to use advanced features in Solution Manager and on the other side No because your productive SAP Solution Manager landscape sizing can explode rapidly. In some cases I think SAP could have used different ways of fetching certain data that does not force the use of diagnostics agents.
In my opinion the idea is great and it works for small SAP system landscape environment but it’s dreadful to maintain on a large scale. Those agents are mini AS Java based instances (no database though) and as such they consume memory and cpu, they require a unique SID+Instance Number combination and you need to take them into account for fail-over scenarios and so on.
Another fun fact is that if you run through the managed system setup without assigning a diagnostics agent you will have a bunch of extractors running on your Solution Manager which will fail constantly because there is no diagnostics agent available for the managed SAP system! Yes you can disable them but why doesn’t SAP wait to enable them until a Diagnostics Agent is actually assigned? That would make sense.
I always wonder why SAP didn’t integrate the agent capabilities into the SAP kernel or at least into a process of some sort that is closer to native coding instead of having AS Java based instances doing this type of data fetching / log file interpretations.
One of the parts on which I have commented in the past is the landscape maintenance. SAP introduced the LMDB with Solution Manager 7.1 and in my opinion made something dreadful (maintaining SLD/SMSY) even worse by adding another source of managed SAP system information.
While SAP has been doing some effort to get more information out there about error messages which you can bump into, from an end-user perspective the landscape maintenance sucks to be honest. It doesn’t feel innovative or intuitive at all. There are too many places to maintain data, too many wizard, too many checks that succeed while your managed SAP system is still managed incorrectly.
The whole notion of getting information of a managed SAP system and maintaining it has become even more complicated. The question is why? For me this should be highly automated and require little to no interaction from the system administrator. There are way too many different steps and technical terms to make this procedure efficient and easy to understand.
Besides the not so great user experience there is also the problem of having to go into several sources and manually cleaning up entries after a system or an agent has become obsolete. It’s a mess waiting to happen.
Customer Engagement Initiative cancelled
There was a customer engagement initiative scheduled that handled the subject of SAP system landscape maintenance and I already signed up for it along with my customer to participate in that initiative and provide SAP with feedback and thoughts in an attempt to get the landscape maintenance improved. Sad enough SAP cancelled the initiative! There was no explanation to why the initiative got cancelled.
Download basket approval
I’ll keep coming back with my idea to remove download basket approvals until the download basket approvals are gone. I’m serious here. SAP does not seem to be picking up the idea, perhaps the right persons are not reading this or they are just ignoring me. I already tried contacting a couple of well known persons within SAP who could help out but I’m not getting any response at all. They must not like my blog “Download basket approval gone with the wind”. Maybe the title is a bit straight forward.
Don’t be surprised if you see me building an application on the Netweaver cloud to get a digital petition going to get these download basket approvals removed. If I fail at building the application, I’ll take paper to SAP TechED instead and you’ll see me standing in the middle of the conference, waiving my petition into the air. IdeaPlace doesn’t seem to be working for the Solution Manager category so I’ll have to stress the point in another way.
The fact of the matter is that nearly all if not all system administrators are bypassing the maintenance transaction and are either using a function module to directly approve downloads or they keep a maintenance transaction open just to approve download basket items. The message is clear: It’s not working and it does not serve a good purpose! Please get rid of it. I’m asking nicely here.
Please vote up the idea to remove download basket approvals: