10 Slides to convince a CIO

Communication
#1

I need to convince some software development colleagues from Tryton. While I can put together quite some good reasons at the business level (focused on our business need), I’d be eager to have more points why Tyton (core) is better than some “self-developed django application”. So much like a feature-fact-sheet for technicians, mentioning e.g. optimized DB access, authentication, LDAP, sendmail, …

Is there some recent presentation, slides or documentation describing this?

(I’m aware of Tryton - Presentations & Papers, but the the slides I checked do not provide this kind of information.)

Thanks in advance

#2

I don’t know such a presentation. It could be interesting to have it, but it will become extensive. In the presentation I would show and discuss two modules. One introducing base conceptions and another one which extends it. There I would explain the main architecture like databases, trytond server, module, model, field, button, wizard, own ORM, transaction, domain, pyson, pythonsql, clients: views, sao, gtk, proteus, etc…

#3

Thanks, Anyhox, what I’m sseking is more like the presentation (10 slides max) you show to a CIO on why Tryton is superior to a self-developed solution (and maybe some competitors like ERPnext, adempier, dolibar). What are the highlights of elaborated technique Tryton implemented in the 12 years of its existence?! All these “little” things another application would need to implement, while in Tryton it’s already there.

Some background: Some CSAs (community supported agriculture, Solidarische Landwirtschaft) are seeking software solution for their processes. Some of the group are just starting, others are in business already and need a better solution. There is already quite a list of CSA solutions, AFAIK none of which is modular and each one focusing on different aspects. One of the bigger German CSA has a quite sophisticated solution, tailored to their needs. The developer of this solution (1 person plus a helper) is about to reimplement its solution from scratch. IMHO this will end up in another CSA-solution, reinventing wheel over wheel as requirements of CSAs differ. So my aim is to convince the developer to drop its backend and use Tryton instead., leveraging all the sophisticated features and maturity Tryton already implements.

Here are some point I’ve already found to give you an impression of the direction:

  • Optimized for distributed transactions
    • What exactly does this mean? conflict handling?, low latency?, …?)
  • Caching
  • Authentication incl. LDAP integration, 2FA (password + SMS), …
  • Authorization (RBAC) for Models, single Fields and even single Actions
  • Workflows
  • Scheduled Actions
  • Email notifications and integrated E-mail “client” (← better term?)
  • Sending Noifications to connected Clients
  • Uses Postgresql
    • for tests and development no DBMS is required, sqlite can be used
  • Modular architecture (1 module for 1 concept) eases understanding and extending/customization
  • works on lines, not on documents ← why is this a feature?
  • data historization: if required, just enable for a Model
  • Built-in automatic migration mechanism
  • International support: Several concurrences, languages, OUMs, … (← not strictly technical, but “core”)

Point I would be interested to learn about:

  • Ease of using custom WebUIs, aiming to remove complexity for the users and provide views and workflows more tailored to the user’s tasks.
  • Ease of integrating GraphQL-based front-ends (this is what the 1 developer has in mind)
1 Like
#4

You’re probably referring to our implementation of the two-phase commit protocol. Which is inspired by Zope’s implementation. For example, it’s a way to ensure that you send an email only if the transaction succeed (ie: no rollback).

Working on the more refined level allows for greater flexibility. Working on the whole documents adds a layer of complexity that would result in more convoluted design.

You can build your API using tryton and then interact with those in any way you would (pure HTML, a Single Page Application using vue.js, etc) just like you would with django.

There is the autentication mechanism of user_application that is quite handy when doing so (for example Chronos allows to encode timesheet in your tryton instance using those principles).

BTW it looks like your writing this “10 Slides to convince a CIO” document, would you agree to share it afterwards? :smiley:

1 Like
#5

I would tell him that I am doing something else for the time being, as long as he is developing an ERP, and that he should call me in a few years when he is ready to develop specialist modules. :wink:

#6

For me, the most important argument is that basic concepts are already implemented and I don’t have to worry about them. Developing standardised processes again is a waste of time. In my opinion, the goal of a CIO of a non-technical company should be to put core processes on a secure basis and to focus development on topics in which business processes are mapped more effectively than those of the competition. In short: clear structures that enable innovation at the corporate level without having to spend too much time on technical planning.

#7

I will argue about two principal benefits:

  • Tryton has some of the base features (i.e: all the accounting stuff) already implemented
  • Tryton as a famework allow to rapidly create all the interface user by reusing standard components and allowing the developer to just focus on the program logic.

Also the tryton comunity is one of the most amazing resources we have. There are always somebody that wants to help on this forum.

If do you think he has enought interest on the Project but he wants to resolve additional questions he can contact directly to the developers and we will be happy to answer them.

#8

As an CIO I would challenge you:

Well, our in-house development has most of the features we need already implemented, too. What technical benefit do we get by switching to Tryton?
Why are the features provided by Tryton superior to the system we already developed in-house?

(For the later question please imaging some average ERP system you have seen at customers or customers might have.)

Basically, this is the question about Trytons USPs (unique selling points): Why should I choose Tryton over some other solution?

#9
  1. You will get a team of developers sharing efforts to improve Tryton while your in-house development keeps improving in a slower pace.
  2. The maintenace cost are also reduced thanks to sharing the code with all the community.
  3. Tryton has a strong focus on security. Once an issue is reported it is notpublicity disclosed until a fix for all supported versions is released.
  4. We maintain a set of packages (and also a production ready docker image), which are updated regularly with bug fixes.
  5. We try to improve our framework every release. We always work on generic improvements that benefit all custom code using our framework without the need of modifying custom code.
  6. Tryton has a very powerfull set of test tools that ease the development but also reduce the maintenance needs. For example, we have a scripting client that can we use on tests scenarios to ensure all the business logic is always working asexpected.
  7. We have a fixed release scheduled and a maitenance plan for each released series which avoids allows developers to upgrade to newer series when it’s better for its needs.
  8. Tryton has a set of modules (i think we are near 150 now) that can be reused on your custom solution. This modules can be activated deending on the users needs. Altought you may just use a small set on the start once you have your development based on tryton you will have them for free. For example if your solution needs to send marketing emails we already implemented in a module. So your solution gains this new features for free.
  9. Tryton is a business solution, a framework for developing but also a community, this means tha anyone can share it’s doubts here and we will provide our best advices or even help solving custom development errors.
  10. We are open minded and accept contributions from everyone. So if your features are generic enought and you want to fill our quality requirements some of your solutions can be part of tryon and mantained by the full community.

Here are 10 reasons for the slides :wink:

It’s hard to answer without knowing any details of the system you developed on house. What is the functional area of you system? How is technically organized? Which components are you using? If you give more details about the requirements I can give more reasons to choose Tryton.

2 Likes
#10

I am surprised that you want to convince someone who is satisfied. A change of system is always associated with costs, and then the approach is to weigh the costs against the advantages.
A technical advantage can only be worked out by comparison. To list advantages without knowing the other system is not helpful, perhaps even frivolous. I would not want to present a list where my counterpart says for every point: “My system can do that too.”
It is also essential to ask whether only the CIO is satisfied with the solution, but the various groups may not be.
The 10 slides should simply include why you would choose Tryton in the role of a CIO. If you don’t know that yourself, I would leave it alone. If you were to ask me, for example, my counter-question would be why not to use Tryton. I’m quick to develop, I don’t miss any features, and if I do, I find a way to solve the problem without too much effort. I work with a lot of Python frameworks and have to say that technically they are all getting closer and closer.The crucial difference is what they are made for - and in my opinion Tryton is the cleanest solution to build an individual ERP solution on top of it.

1 Like