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?
Landscape strategy
picture 1.0
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.
picture 1.1
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.
picture 1.2
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.
Landscape maintenance
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:
Hi Tom,
As usual a nice and meaty blog.
Ironic:
I think I have a sneaking suspicion of where your inspiration came from, I hope you didn't write this during your work hours? 😛
but seriously:
yes, the download basket approval is silly.
Even the entire concept of download "rights" on the marketplace is silly. It's reserved for basis profiles. Like as if no-one else would like to download the latest SAPGui versio, the tools for NW Neo, the business client or the NW Development Studio...
About the solution manager landscapes, I have some philosophical thoughts. You mention that you could connect development landscape to development solman. From the perspective of solman, aren't all systems to be considered as "productive"?
I mean, if someone calls in to say that ERP development is down, must this not be logged in the production Solman?
Aren't the development and acceptance solman instances intended for the internal functioning of the solman, rather than managing other systems?
Mind you, I see your point about the humongous landscape to be managed in one system, but I do think that, alas, that is how it is supposed to be. (although I'm hardly a sapadmin .)
Much rather than creating different solman instances for different landscapes, perhaps we simply have to reduce the number of environments, or find a better way to categorize and prioritize landscape domains?
What are your thoughts?
Hey Tom
Thanks!
The inspiration does come from the work that I'm doing 🙂 . That would be correct. The writing is reserved for before/after work hours 😀 but I do have an agreement to spend time on SCN during my work day 😉 . I actually work more than eight hours a day to compensate for time spent on SCN (might be useful information for others who are not allowed to spent time on SCN during their work day otherwise).
Yes, I would want to see alerting that a development system is down in the same overview as the alerting for acceptance or production. However that doesn't mean development has to be connected to production. The development Solution Manager could forward the alert to the productive Solution Manager or you could have a Netweaver Business Client or something as front-end and you might not even know where the alert is coming from (idea) but you would still be able to get an overview of all the alerts of all the different SAP systems.
In my opinion, the as is situation comes from the past where all customer had a maximum of one Solution Manager in place. Now, a number of years later this is no longer the case and the functional use-cases are much more prominent and are used a lot more often. Those functional use-cases actually require the SAP system landscape with at least two and preferably three SAP Solution Managers.
One of the problems is testing certain more technical or even functional use-cases that have certain technical prerequisites (diagnostics agent connected). You should be able to test it in development because when you do maintenance the functionality might be impacted. But which systems to you use for it then? If you connect a single landscape (dev - acc - prd) to your development Solution Manager you cannot connect the same landscape to your productive Solution Manager and you do want to have that landscape in your productive Solution Manager because you will want to use other functionality over there for this landscape.
What could be another solution or a workaround (name it like you want) is to have a more flexible way of changing the connection of the managed SAP system + diagnostics agents from one Solution Manager to another Solution Manager. Something like "Attach this landscape to the Development Solution Manager" which would switch it over and automatically connect that specific SAP system landscape to the development Solution Manager, allowing the system administrator to use it to test out functionality after a support package update for example and switch it back once the tests are done. At the moment, it's a real hassle to perform certain scenario tests.
Another option could be to allow a diagnostics agent to connect / send data to two Solution Managers although it would not be my favorite option as you would create double data and so on.
For the functional use-cases you will still need a three SAP system landscape to develop, test and place it into production so reducing the number of environments isn't really a good solution I think.
The problem is that some functionality doesn't require a full landscape to be connected to a single Solution Manager and other functionality does. Most often there is no in between, it's a either this or that situation.
What is also done sometimes is size the development or acceptance environment to almost match the productive environment so the development or acceptance environment can be used for fail-over purposes. This can be very interesting but of course it's less interesting if production is a monster compared to development and acceptance. Wouldn't production always be larger? Yes but does it have to be exponentially larger?
Kind regards
Tom
There can never be a discussion on Diagnostics without TC's name and work being mentioned.
Awesome read, Hats off once again.
Cheers!
Your #1 Fan
That must be a coincidence 🙂
Thanks for your comment 😉
This is the best posting I've ever read on SCN! Ever! Although you are using much nicer words than I would be. About time someone questioned the Solution Manager tax on implementations and customers. Yes, it's a tax.
LMDB is an unnecessary monstrosity that only adds to problems. Migration from SMSY is an unmitigated disaster unless someone is working full time on Solution Manager and only on Solution Manager. Some larger companies have enough staff to have some people full time for the Solution Manager runaround but most places have no such setup, hence constant overruns in budget and time.
The endless checks all over the place would be fine if they actually checked things correctly.
The constant insane stream of correction notes is another evidence that Solution Manager software quality is scandalously low.
Hi Mikhail
Thanks for your comment.
If a company really starts using Solution Manager, it's best to have someone dedicated to Solution Manager. There are a lot of neat features, a lot of new features but in general it does need attention and reviewing and so on.
Solution Manager is heading in the right direction but it's not there yet, there still is a lot of functionality that is being released that isn't "stable" enough.
This blog post isn't me ranting against Solution Manager, it's me making a case for SAP that they should rethink a number of things and not just look at each feature on it's own (isolated somehow).
Best regards
Tom
Hi Tom,
Today only had time to read this, I got impressed with your deep analysis on each funtionality of solman,
But I would like to share my experience on LMDB which is most positive go for it.
Lets take if you have SLD, SMSY :yes it is good, very easy, but SMSY is only for keeping the landscape data, you cant get more functionality out of smsy.
starting from defining system in smsy to configuration of SLD sync all are manual here. and if any where if you define wrong or missing info, you only come to know when you execute MOPZ , more over smsy is used only for storing landscape data .
but if you come to LMDB, it is created for own purpose. 1st it automatically reads your sld data, and more effective auto sinc with SLD is posible.I had 90 systems in my landscape. I connected solman to SLD, and during intial system configuration I maintain central SLD details, this picks the entire details of my landscape and product information
2) while managed system configuration also faces lots of improvements like agent automatically collect the host details, and in SP05 you had auto landscape verification , it is almost replace the Landscape verification tool.
3) hope you aware that in SM 7.1 creation of Local SLD is only an option, since LMDB itself based on CIM features and provide efficient functions for managing technical system, eventually it replaces your local sld,
4) yes, I accpet inside you have 2 or 3 wizards for each purpose, but it is again one time effort and also verified against the correct config,and .
5) LMDB is the one sending inputs to the other operation functions like RCA, MOPz and monitoring. so it helps to trouble shoot in single place, most of the time all are interconnected,( Ex: While configuring Technical monitoring we auto directed to LMDB for reconfiguration)
6) Once you have active LMDB, except product instance, all the other landscape maintenance functions only available via LMDB, again in sp05 sap introduced improvement in this place also.
7) and another good thing I liked in LMDB its fresh UI look and clear definition for all activity, and description of each and every content ( Example dual stack and single system scenario)
I didnt feel that such big enhancement from SAP is totally odd or problamatic, It is good innovation, still needs little bit tuning.
you can get more info on Note 1679673 - LMDB System Landscape Product System: Comparison with SMSY
and as Mikhail Alterman said above "Implement SAP BASIC NOTES " is not all necessary, even after sp05 relased also at step 1.3 you need to downloand the basic correction notes and implement again, why so 🙁 🙁
Hope all the drawbacks stated above ( Specially MOPZ approval) will clear soon.
Thanks again for sharing.
Regards.
Jansi
Hi Jansi
Thanks for your comments 🙂
1) It starts already with upgrading from 7.0 to 7.1. The users used in the RFC connections differ which means you should redo all the connections in order to use the "new" user-id's. That's rework needed to be done.
Many customers don't have diagnostics and host agents installed by default on their managed SAP systems so that's already adding to the cost really. You need to install those agents to get your managed SAP systems in properly.
Once you have gotten everything right, you might think it stops there but it doesn't.
Once you start moving your SAP systems about the "system" fails dramatically. It's not properly geared towards handling fully virtualized environment and customers that move SAP systems about frequently. I have experienced this first hand. At the moment we are handling over two-hundred SAP systems.
There is a lack of intelligence in the system landscape maintenance. For example it would very neat if LMDB could detect that you moved a SAP system about and actually came inquiring about it to check what happened to the SAP system. Was it copied, was it moved... If it could do that, a lot of additional maintenance could be avoided. Or even having to remove the SAP system from the Solution Manager and reinserting it could be avoided.
2) The landscape verification isn't without faults so I doubt it will be bullet proof this time around in SP5. I'll be the first to state it if it is 🙂 . Pre SP5 I've seen green lights on the verification and then red lights in the managed system setup ... which should not be the case in my opinion.
It's not the only place where green lights are shown which shouldn't be green 🙂 . When you maintain the RFC destinations for a managed SAP system, the RFC destinations on top can get a green light while the users created for the connection SM_<SolMan SID> and SMTM<SolManSID> did not get any roles assigned. The result is the connection is there (green light) but it fails (resulting in short dumps in the managed SAP system). The logging of the action (bottom of screen) does show that no roles are assigned but right after the execution is performed (creation) to screen focusses on the top which makes the end-user see a green light. To see the error, you would have to go back down and scroll through the logging of the action.
This might be something small, simple but it's things like this that in the end make the features look "unfinished".
3) Eventually it might but it's not the case at the moment. That's exactly my point though. You have more than one repository that holds the same data, why? That doesn't make sense. Hopefully in the future SAP will use a single source of truth and make SLD, SMSY absolete for that matter. Why not only use LMDB, right?
4) It's not clear enough what goes where and what do you adjust where. A survey amongst system administrators would definitely show that the system landscape maintenance score badly at the moment. I'll set one up to see to what extent this is true.
5) Agreed, it does have it's benefits as well and it's positive that more data is captured (increasing the intelligence of other Solution Manager scenario's because of what they know through data available in LMDB). On the other hand, it does require Diagnostics and Host Agent as well so there are more prerequisites to get it right.
6) Agree again, SP5 further moves LMDB up front which is positive and which is what SAP has been saying since SAP TechED Madrid 2011. Progress is rather slow though if you ask me. I wonder how long it will take to get things right.
7) Yes, the UI is an improvement (but that's in general for Solution Manager) although it could still be improved in many cases. The need to hit a save button on top of the wizard for example is something I personally dislike.
MOPZ has been enhanced some time ago to also be able to include Java patches. But if you have the system select the java patches automatically, what do you see? It gives a warning that if you include these java patches into the XML file, you are responsible for the consistency of the XML file yourself. That doesn't make sense at all. They should have just left out the integration into the XML file in this case.
It's like shipping a product to someone and saying: "If it's broken due to the shipment, it's not our problem".
Being positive matters to me. This blog post is not meant to harm Solution Manager in any way. I like Solution Manager but I see a lot of room for improvements. I will dedicate about 50% of my time on Solution Manager soon (taking a small vacation first in August). This means that I believe Solution Manager holds value and can provide added value but I also do believe that in order to use Solution Manager to it's full extent you need to threat it like a business system much like you do with a ERP SAP system and put one or more resources on it instead of doing "single shot projects" to keep it maintained properly.
I hope SAP reads these blog posts and acts upon them.The idea (concept) of LMDB is good but so far it has been too messy.
I'm very much willing to help provide feedback to SAP on managing SAP system landscapes since I have been managing a lot of SAP systems through Solution
Manager in the field.
Best regards
Tom
Hello Jansi
Poll has been created:
http://scn.sap.com/polls/1409
Best regards
Tom
Hi Tom,
Thanks..... I voted!!!
LMDB is good, but needs to be only better in al the way !!!!! , got some more information from your above reply. Thanks for the time taken.... and I really enjoyed this blog!! 🙂
Regards.
Jansi
Hi Tom,
I really appreciate this blog, glad to know that someone feels the way I do about Solman( I am currently fighting with SOLMAN 7.01 (and without any SAP training it is hard )).
We really hate Download Approval and for now we have found the Function Module "/TMWFLOW/MO_UI_BASKET_AUTHORIZ" that at least permit a direct access to Download approval
So We have write the below micro report and attached a transaction to it :
REPORT Z_CONFIRM_BASKET.
CALL FUNCTION '/TMWFLOW/MO_UI_BASKET_AUTHORIZ'.
I Hope this could help someone
Regards
Jean-Louis