Posted to SAG-L this email concerning a posting under the webMethods folders.
For a while, it’s been really nice to be able to point people to a public site at http://techcommunity.softwareag.com/ecosystem/documentation, but for some reason, it looks like SAG is doing away with this and only providing the documentation inside Empower. This means only those with Empower id’s will be able to access any of it.
This isn’t practical in my opinion as I don’t want all programmers to be support contacts in Empower nor is it worthwhile to manage dozens of id’s that are documentation-only id’s (if they even still support that concept). As we’ve moved into the EntireX realm recently and developers using the CONNX SQL engine, this explodes to not just include developers but the SOA infrastructure team, developers of C++ and others. Now I won’t be able to just provide a link to the relevant pages anymore to those who need access to the information.
I think this is a mistake. Sure, there is probably documentation that should be secured, but on the other hand, there is plenty of useful documentation needs to be made available.
Guess I can take those CD’s and try to copy the contents to a share-able site inside the enterprise but what a pain!
-Brian
Original post:
With the goal of providing Software AG’s product documentation in a single secure and centralized location, as well as ensuring that the most up-to-date documentation is currently available for the exclusive use of our customers, Software AG will be centralizing access to its product documentation in Empower, Software AG’s global extranet. Empower is located at https://empower.softwareag.com/.
The target date for completion of this change is April 15, 2013. If you currently access Software AG’s documentation using the site http://techcommunity.softwareag.com/ecosystem/documentation, you will be redirected to Software AG’s Empower site. You will need an Empower username and password to log in. If you do not have access to Empower, please contact the Empower team at empower@softwareag.com or click Here for more information about registering for Empower.
I think Brian is ABSOLUTELY right, and I can`t disagree less with him However, I assume there is some of “big politics” behind of this Software AG decision (which is a pity of course). Well, such is life…
We realize that this move provides inconvenience to many of you, especially users who consume the documentation directly online, and we sympathize with their annoyance.
The main reason for this step was that Software AG has compliance and legal requirements which imply that a certain portion of our documentation is accessible only for customers after authentication. It seemed that having parts of the documentation in Empower and parts in public not to be an option since it could be very confusing for customers.
In order to help to improve this situation we would like to get your feedback on:
• What information do you most commonly look for in the documentation and might be of benefit being provided via the Tech Community?
• Where can we improve with the quality of the documentation (Re: Comment of the at SAG-L discussion thread) ?
Thanks for the reply and hopefully reconsideration of how this change is implemented. As I just now posted on SAG-L your response and implored people to respond here, hopefully we can have meaningful discussion and come to a solution that is not so painful to the customer base.
First, when things like this come up where you need to make a change for legal compliance, you have user group leadership in Europe and North America who can help you to meet your needs while minimizing the negative reactions by the user community by causing less pain and by having us help communicate the need for change (e.g., legal compliance factors which were not mentioned on the post I found in the webMethods topic group). Then, while there still could be negative reaction, it would be more like “that’s painful, but guess it had to be done” than “what a boneheaded move by SAG”. Just knowing now this wasn’t a move just made for the convenience of having one site instead of two as the message was phrased makes a huge difference.
Moving forward, I think the European and North American user group leaders need to be brought into a discussion so you can explain to us what the legal drivers are and what level of compliance is needed, and if there is room to leave some kinds of documentation public while others are put under lock & key by necessity. We can help you identify docs we prefer be kept public based on our use of them. We can understand if you have no choice but to lock up certain ones and hope, based on the fact that having public documentation is not uncommon among software vendors, that we can come to a better solution.
I think the smart thing to do for SAG would be:
a) as Brian says communicate the real reasons in the first place to avoid misunderstanding.
b) get the contractual stuff sorted with your partners so you can get out of this legal mess.
c) realise there are an awful lot of consultants out there evangelising SAG Products who may
not be customers but need access to documentation (& products) to spread the word effectively.
I for one regularly access Natural, Adabas & Predict docs online.
By the way, I spent my morning extolling the (very obvious) virtues of NaturalONE to a
SAG customer where Adabas & Natural are no longer strategic. I’m sure I’m not the only
one out there doing so, and we need SAG’s backing in the uphill fight against stoneage
technology like Cobol & a couple of DB’s I won’t name here, compared to which Adabas
is vastly superior.
Thanks Bryan. I think it’s a great idea to first collect the feedback on documentation needs from SAG-L & this discussion here. Next we could share it with the user group leadership teams and discuss what could be done to improve the current solution.
I will take the initiative to sync with the responsible people as Software AG to see how this could be accomplished.
Many thanks for the response. I eagerly await your suggestions and proposal to solve this issue and to help along with the other user group leaders worldwide in ensuring the implementation is as accommodating to the customers as possible while meeting your legal obligations that drove the change.
I feel and request the SAG documentation site should be wide available and its a great help especially for the people who are trying to acquire new skills in the changing software trends and technology challenges…This will also allow more and more associates having with SAG product suite skills in the future growth aspects.
Based on the feedback we got from the user community the decision was made to postpone the move of Documentation to Empower. We will continue to listen, collect and analyse your feedback to consider your special access and usage scenarios.
Read the full announcement here [url]http://techcommunity.softwareag.com/ecosystem/documentation/[/url].
that makes it even more worse for me. Imagine a user asking a special question about the EXAMINE statement. It’s impossible to post a link to documentation. So I would answer him with a copy+paste out of empower’s documentation. → Now I got the legal problem.
So from this point of view I agree with David Law:
that’s a very relevant point there from Matthias, so it’s nice to hear from Gerd that SAG are taking the community seriously.
Once again I’d like to point out that there are an awful lot of non-customers out there who believe in these products & invest time to spread the word. I hope SAG will keep that in mind & won’t leave them “in the rain”.
It will be OK to send a deep link to the documentation, e.g. to the EXAMINE statement. The link will take the user directly to that part of the doc after prompted login to Empower.
We are gathering information on legitimate use cases where an Empower login is not available so that we may develop acceptable solutions.
This is why we need your specific feedback on your use case scenarios which you can provide here [url]http://tech.forums.softwareag.com/techjforum/posts/list/51351.page[/url].
Many thanks, Gerd, for postponing this move in order to reach an understanding of how to satisfy the drivers requiring the change while allowing us as customer product admins to serve our user base. I think the comment about still locking up specific statement syntax, though, concerns me as that is the kind of thing we would want in the public sphere as none of the 30-or-so developers would have Empower logons, nor should they, but we often refer them to documentation pages such as Natural statement syntax.
But with your feedback page and subsequent discussion forthcoming, I am hopeful we can work out some kind of solution that we can all accept.
About 99% of my documentation uses involve the syntac of statements in Natural. One of my favorites is the location of the IGNORE clause in the SEPARATE statement. Putting that in the wrong place can be problematic. I see no reason why the syntax for Natural should not be publically available.
However, I assume there is some of “big politics” behind of this Software AG decision (which is a pity of course). Well, such is life…