How do I deploy CogTL, PeopleRisk or Pilot in my environment?

CogTL is delivered as Docker containers, orchestrable with Kubernetes. We can provide you the basic deployment YAML files to speed up the process. For the persistence, you can either use your own MongoDB database, or use our own Docker image, deployed as another container.

Is there an easier way to test the application than deploying multiple containers?

Yes! For test purposes, we have packaged a standalone CogTL container, that includes both the database, the server, and our end-user admin interface. And it's pretty easy to connect PeopleRisk or CogTL Pilot directly to this standalone server.

Is CogTL a cloud solution (SaaS) or on-premises

We can offer both architectures, although our clients generally prefer to deploy CogTL directly on premises as a set of Kubernetes containers. If you choose a cloud solution, we have to deploy a lightweight CogTL agent (also a Docker container) in your infrastructure, that will take care of the connection with your tools and data. You will stay in control and won't have to expose anything to our cloud, our agent will initiate all the communications.

What are the technical requirement to run CogTL containers?

The final numbers definitely depend on the quantity of data that will be acquired by the CogTL server. But in general, a complete environment can be run with as few as 8Gb of RAM, 20Gb of storage, and 2 CPU cores. For a production-grade system, we recommend to have 16 Gb of RAM, 100 Gb of storage and 4 CPU cores. We can obviously provide you with the resources allocation details.

What is the licensing model?

Our licensing model is based on the quantity of data (nodes) that CogTL keeps in its central knowledge graph. It does not depend on the number of connected systems, rules, or anything else. To ba able to use PeopleRisk and CogTL Pilot applications, you have to add a (small) flat added fee to the yearly licence.

Do I have to develop code to integrate a custom/home made system?

No, there is no code to develop to integrate any third party system. With all the standard connectors that we have, we always find a way to gather data. Should the system have an API (REST, SOAP, or even any other text-based data), we can connect, handling multiple authentication schemes, gather the data and parse it. If there is no API, we can connect to multiple database systems (relational or non-relational) and perform queries. And if it is not possible neither, your system may be able to export data as a file, that we can also consume.

I have a system that is completely isolated in my IT environment, how will CogTL get data from it?

There are two possibilities. We can either deploy a CogTL agent in the same isolated zone, taking care of the connection and pushing the data to our central CogTL server. Or we can also accept incoming data directly from your system, if this one is able to perform REST connections to our server.

How long is it to integrate CogTL in a company? It must be an expansive project!

The initial setup of our platform is performed in a few minutes only, thanks to its standard usage of Docker/Kubernetes. Then we usually propose to start an iterative process, where we identify one use case, connect the 1-2 necessary sources (e.g. Active Directory and HR referential), and visually create a first rule. All that process can be done in a day and its outcome is immediate, and lasting in time. Then we iterate: identify a new use case, potentially add the required source(s), and design the new rules, etc. Hence we are able to demonstrate, even during a Proof-of-value project, that we you can get a quick return on investment.

How do the users authenticate in CogTL? Is it possible to implement SSO?

Users in CogTL can be either created in our system, or dynamically created when a SSO login is made. We support OpenID Connect for SSO, and we can also handle username/password authencation against a LDAP directory.

Do CogTL, PeopleRisk and Pilot implement access rights?

Obviously, our applications completely implement a role-based access control. Roles can optionally be bound to an external source (like Active Directory groups), and they are used to modulate everything a user can see and do in our applications.

A quick presentation is worth thousand words

Don't try to read between the lines or compare it with an existing product - our approach is completely new and slightly different. Contact us to see our products in action!

Contact us!