Security tool

[BPConnor]

I have implemented both tools. While both are significantly better at implementing a strong security model than standard JDE, there are differences. I agree with everyone that has said to bring in both companies and see what they can do for your company.
As has been said a few times, Qsoftware adds a few tables and applications to your system and security is defined outside of the F00950 before you 'build' it and overwrite the records. One feature to be careful of is the BuildAll button as that will replace everything in your F00950. We ended up disabling that particular button.
AOS is a much thinner footprint and is more of a toolset than an application. It is quite easy to setup and you can easily convert all of your custom menus to security records in a couple of days at most. You have the option of how deep you take your exits when you do this so you can control just how much ancillary access is available to your users.

One thing to keep in mind is that JDE still has role heirarchy issues so the security you think you're giving a user with standard security isn't necessarily what they are getting. AOS has a couple of cool ways around this either through aggregating the multiple roles into a super role, or by using an process to determine the security that should take precedence in the event of a conflict. This way your users can still utilize multiple roles and you don't have to worry about what they can access.

The AOS SOD module is really easy to use and you can select which modules or rules to implement from those that are delivered. In addition you have the option of putting in place preventative rules so you don't accidentally grant access that will violate your SOD.

Both are effective but I do think AOS has the upper hand with ease of use and ability to get a lot of things done very quickly not to mention a very competitive price point.

 

[Luke Phillips]

I think the point here is that prospective clients should look at both solutions before making a decision rather than listening exclusively to what either I (who work for ALLOut) or JohnAdams/Lewis (who work for Q) or consultants with a vested interest (although obviously many consultants have worked with both products.)

I can also say however (I have programmed and designed both – and the fundamental file structure of Q version 4 is the same as Q version 2 that I developed before multiple security roles were available) that the products do not attempt to do quite the same thing.

As a rule of thumb, I would suggest that since ALLOut was designed post Xe with both roles and *groups in mind, it has extra functionality that could not easily be replicated within an external file structure.

ALLOut attempts to complement the functionality that is already existent in JDE whilst Q (with external tables) replaces JDE and if nothing else complicates the file structure.

From a consultancy and implementation point of view, Q is more involved during the implementation phase because the building block is the external ‘component’ rather than the internal ‘role’.

Lastly, we both have very large and very small clients (and I am not aware that the pricing is necessarily so different) so I do not agree that either product is better suited to either larger or smaller clients – the important factor is which methodology they consider meets their needs most effectively.

 

[lrh]

Luke,

I have to take issue with your comments, and I really do advise that you of all people be careful with what you say.
While I do agree with letting people review solutions on offer I need to clear up this nonsense. Q Software like any other company does not want customers making decisions based on untruths.

Let’s clarify 'external files' - Q Software's products are written using the JD Edwards toolset, we do not change the underlying architecture of JD Edwards so security gets written to the F00950 just like the P00950 and Allout do.

What we have is a process that allows you to group security together into components or write directly to the Roles in the F00950. These components could be a menu/task, a business process an entire role or the entire contents of the F00950. We have customers who use these components in many ways, including the same way that Allout's customers can implement security. Our 'Best Practise' always talks about having components at a 'Task Level' so that if you have 20 roles that can update the address book you have one component with all the security for this task attached to the 20 Roles. When you need to make a change, you simply change the Component and all 20 Roles get updated. This has had benefits at customers of all sizes, the point is you are not left using the native complexities of line after line of security to maintain.

If you don’t want to use it that way - don't! Our implementations have been as short or as granular as can be - that is the customer’s choice. By linking a Component to a User or Role makes the idea of having to use an 'external component rather than an internal Role' a lie.

As for multi role checking, it is misleading to state that because the Allout product was built for XE and multi role it has extra functionality that cannot be replicated in an external file structure. We have Role and SoD conflict resolution that solves the issues 100%, and it is using the native files in JD Edwards, not our own.

Lastly John Adams does not work for Q Software - I don’t know who he is but like many others who testify thanks for their input. Lets get back to the facts and maintain some integrity when customer's come to this forum for answers.

If anyone is in doubt about Q Software's approach or want details of our research into implementation times, best practises or anything else please get in touch.

Thanks,