What is our primary use case?
I am developing applications in Archer from RSA (Rivest, Shamir, and Adelman). It is quite easy to implement the application. You just configure the workflow, define the forms and how the data is processed in the application. Everything can be configured without coding. You can use a code also to create special functionalities, but it is easy to do almost everything without coding at all.
How has it helped my organization?
It gives me the opportunity to create custom security applications easily.
What is most valuable?
The most valuable part of the product is the ease-of-use.
What needs improvement?
I am currently using an older version of the product so my installation is not current. There have already been two new versions of Archer released after the version I have. I use 6.5 and 6.6 and 6.7 have been released. These two are minor releases. They are not really affecting the inner workings of how to do tasks but improving certain features like the interface. When I am creating applications I like to have what I know is a stable and familiar version of the product, so I do not automatically upgrade to the newest versions available.
Because I have not upgraded, the graphical user interface is not the current one. It is not very modern and as user-friendly as it could be. I heard that the new versions have improved the graphical interface very much in this respect, and it should no longer be a problem at all. So, for now, I have some issues with the interface for this version but it may already be repaired and simplified in the new versions that exist.
One thing I might like added is the ability to record a workflow in another application. It is really a sort of very technical thing and it is possible to do it in other ways, but adding this to the product could really help with the simplification of creating new workflows. This could make it easier, to implement some technical things.
For how long have I used the solution?
I have been using RSA Archer for one year.
What do I think about the stability of the solution?
I have not experienced any problems with the stability of the product. It works as expected in accordance with the resources and feedback I received from my IT department. It can use a SQL server, a web server, or whatever I need. There is no problem with lag or overuse of resources on the server.
What do I think about the scalability of the solution?
The product is flexible and scalable. The processes that are created with the product are going to be used by every manager in this company. That is a total of about forty to sixty people right now.
As far as how extensively I will use RSA Archer in development, everything I develop is per request. When somebody requests functionality, I am the one responsible for implementing it. It is not really possible to predict how often or how many requests come in or how complicated they will be. Usually, I am using it at least a few days every month. But I may be asked to implement an application that the other employees may use daily.
How are customer service and technical support?
I had a few problems initially understanding the sample they showed for the implementation. Once I contacted support they told me a few things to try and sent me links to additional documentation. When I read about it, I was able to easily resolve the issues I was having. When I was then also introduced to the community, I was able to continue to quickly solve any problems I had. There is a huge community of users that is quite active and can help other users to solve issues. It is great when others who have already solved similar problems in real life share their knowledge about how to solve those problems in your own environment.
But in general, from my experiences, I would rate the support at RSA as very good.
Another benefit is that — although there are many features already — you can propose new features directly to the company. There is a place in the user community to propose those features where they can be discussed. If they are popular features with users, they are implemented. So you can ask for anything and if you have an idea which is good — something which is required by others — it is usually implemented. I have recommended about four or five features that are in the process of being considered. It is a really good way for the company to guide their efforts in improving the product.
Which solution did I use previously and why did I switch?
A similar product that we used before RSA Archer was LDRPS (Living Disaster Recovery Planning System). We had to move from LDRPS to the RSA product because LDRPS went to the cloud. The security requirements of our management and of our customers are generally that they do not want to have very critical information on the cloud. In some cases, they can not have it there at all. We have to use a tool that is possible to install on-premises. When we were evaluating solutions, I was testing several of the products. I chose RSA Archer because it met this requirement and other needs we had for flexibility.
I chose RSA Archer because I was tasked to find a tool that could implement business continuity planning. Archer can implement more processes in many ways, so it not difficult to implement anything from incident management to business continuity, to change management. Anything somebody asks me to do, they provide the requirements and it is really easy to implement it in this. On top of that, it is easy to customize.
So this is the reason why we chose Archer. It is easy to implement, it is easy to change the workflow, and it is easy to customize the processes.
How was the initial setup?
Archer can be set up for use in very small environments and you can use one tool for several installations. It can be installed on several servers concurrently, so every server might be configured to have special features and styles and the instances of the installations cooperate together to provide the functionality of the tool. So the complexity of the setup depends on how large an environment you have. At this moment, I have experience only with very small environments, running the product on one computer. But the product also has great documentation. Just using the documentation alone I was able to install the product really easily and get it up and running on the one server.
It took me a little more than one day to install. The deployment really depends on the use case. The use case is processing or the kind of process you are creating. For example, processing may need to analyze requirements supplied by customers. The more requirements and more processes you need in Archer the more complex the setup will be. Usually, it takes a few days to create a process. I would say on average that processes are implemented in five days. The options and features that the tool has are really quite vast. There are lots of features and every company only chooses to use some of them, which they license and use separately. It can be compared to something like Jira.
What about the implementation team?
I did not have to consider using an outside vendor for the installation and I was able to complete the install by myself with the help of the documentation.
Which other solutions did I evaluate?
Many tools that I tested had processes wired into the application without any option to change them. When I needed to fill requirements that differed even slightly from what was already implanted in the tool I would need to make a workaround or need to implement another tool. This would not have been the best way to go about what I would need to accomplish regularly.
What other advice do I have?
For people considering this product, they have to be sure that it is a product that could really do what they need it to do. Mostly any workflow can be implemented in the process in the application if they want to build it. The best thing would probably be that they should just try it and see. I would definitely recommend this product, but it may not be the tool everyone likes the best.
On a scale from one to ten where one is the worst and ten is the best, I would rate RSA Archer as a nine-out-of-ten.
Which deployment model are you using for this solution?