Jmix · consulenza

Vendiamo licenze Jmix in Italia. Questa pagina parla di quando non comprarne una.

Dichiariamo prima il conflitto, perché decide come dovete leggere tutto quello che segue: Far Rainbow è il venditore delle licenze Jmix in Italia. Guadagniamo quando lo adottate. Guadagniamo molto di più, nel corso di diversi anni, quando la cosa che vi abbiamo aiutato a scegliere era quella giusta — ed è per questo che la conversazione più utile che abbiamo con i nuovi clienti è quella che finisce con "non questo".

Una revisione dell’architettura richiede da due a cinque giorni e risponde come si deve a una sola domanda: questa piattaforma è quella giusta per il sistema che state descrivendo, e quanto vi costerà scoprirlo nel modo difficile?

Idoneità

Il tipo di sistema per cui questa piattaforma è stata costruita

Jmix si ripaga sui sistemi aziendali interni con un modello di dominio ampio e un pubblico ristretto e noto. L’economia è semplice: la centesima schermata costa quasi nulla dopo la prima, perché il framework ne genera la maggior parte dal modello dei dati. Se il vostro sistema è fatto in gran parte di schermate su un dominio complicato, l’argomento è tutto qui.

Molte entità, molte schermate, pochi utenti. Back-office, operations, gestione dei sinistri, logistica, tesoreria. Il rapporto che conta è la complessità del dominio rispetto alla dimensione del pubblico, e deve essere alto.
Un controllo degli accessi che qualcuno verificherà. Permessi su entità, attributi e righe, applicati nel momento in cui i dati vengono caricati. Se il vostro modello di sicurezza è un requisito reale e non una casella da spuntare, è qui che la piattaforma è più forte.
Una vita lunga e un team di manutenzione. Java e Spring standard sotto il cofano significa che le persone che lo manterranno nel 2032 si possono assumere. È un argomento di procurement tanto quanto tecnico.
Sostituire qualcosa che nessuno riesce a mantenere. Oracle Forms, Delphi, PowerBuilder, un monolite Java EE che invecchia. Il database di solito sopravvive; l’applicazione che gli sta attorno no.

La parte che ci costa denaro

Cinque situazioni in cui diciamo no

Ognuna di queste è arrivata almeno una volta come richiesta che avremmo potuto accettare. Sono elencate perché una revisione che non può produrre un "no" non è una revisione, è una telefonata commerciale con un documento alla fine.

01 · L’interfaccia è il prodotto

Un prodotto rivolto al pubblico con un design system su misura — un marketplace, un’applicazione consumer, qualsiasi cosa di cui sia responsabile un designer. Combattereste il framework su ogni schermata, pagando per una macchina che state scavalcando. Costruitelo su uno stack convenzionale e tenete Jmix per la parte amministrativa, se vi serve.

02 · Il mobile è il punto

Jmix costruisce applicazioni web. Un’app nativa può dialogare con una di esse tramite la sua API REST, e lo facciamo esattamente altrove, ma se il prodotto è l’applicazione per telefono allora la piattaforma risponde a una domanda che non state facendo.

03 · Il team non è un team Java

La produttività viene dal fatto che gli sviluppatori Java qui sono più rapidi che altrove, non dall’evitare sviluppatori Java. Adottare una piattaforma Java per un solo sistema dentro un’organizzazione .NET o Node vi compra un problema permanente di personale in cambio di un guadagno temporaneo di delivery.

04 · Il sistema è davvero piccolo

Dieci entità, tre ruoli, nessuna integrazione, due anni di vita prevista. A quella dimensione una piattaforma è sovraccarico. A volte la raccomandazione onesta è un foglio di calcolo tenuto con disciplina, a volte uno strumento no-code, e di tanto in tanto due settimane di semplice Spring Boot.

05 · Nessuno è responsabile del processo

Il no più difficile, e quello che fa risparmiare di più. Se il flusso di lavoro che il sistema dovrebbe supportare non ha un responsabile dentro l’organizzazione, il software produrrà una registrazione accurata del lavoro che non viene fatto. Preferiamo definire un primo rilascio più piccolo che vendere una piattaforma in quella situazione.

E uno che non è un no

"Usiamo già un’altra piattaforma low-code." È un confronto, non un ostacolo — e di solito una conversazione sulle licenze per utente e su cosa succede quando l’applicazione ha successo. Va dentro la revisione.

L’incarico

Da due a cinque giorni, e un documento che potete portare dove volete

Una revisione è deliberatamente breve. Oltre i cinque giorni smettiamo di imparare cose che cambiano la raccomandazione e iniziamo a produrre pagine che la fanno sembrare costosa.

Cosa guarda:

Il dominio. Quante entità, come si relazionano, quanta della complessità è strutturale e quanta è accidentale.
Gli utenti e il modello di accesso. Chi vede cosa, e se è una frase o una gerarchia.
La superficie di integrazione. Con cosa deve dialogare il sistema, in quale direzione, e di chi è l’altro capo.
L’aspettativa sull’interfaccia. Se "deve avere un bell’aspetto" significa usabile e coerente, o significa un design che qualcuno approverà pixel per pixel. I costi delle due cose differiscono di un fattore.
Il team e il decennio. Chi lo mantiene dopo che ce ne siamo andati, e se è realistico.

Cosa ottenete — due documenti, e la stessa disciplina che applichiamo a un audit tecnico:

Il risultato, con la sua base di evidenze. Una raccomandazione e il ragionamento che l’ha prodotta, non la conclusione del ragionamento. Dove un numero è stimato e non misurato, è scritto accanto al numero.
Un dimensionamento su cui potete discutere. Le ipotesi scritte accanto a ogni cifra, così la discussione riguarda un’ipotesi e non un totale che nessuno può scomporre.
Un elenco dei rischi ordinato per quello che farebbe davvero male, compresi i rischi di sicurezza delle informazioni che abbiamo notato passando, che ce li abbiate chiesti o no.
Una sezione sui limiti. Cosa lo studio non ha potuto stabilire, e perché — di solito perché i dati per stabilirlo non c’erano. Una revisione senza una sezione sui limiti o non ha guardato abbastanza a fondo o non vi sta dicendo qualcosa.
Se la risposta è sì: un’architettura scheletro e il perimetro del primo rilascio. Se è no: cosa al suo posto, e perché.

E un confine che sta nei nostri contratti, non solo su questa pagina

Una revisione produce risultati e istruzioni; non modifica i vostri sistemi. Quando l’incarico è un audit tecnico, il secondo documento è un’istruzione di implementazione scritta per i vostri ingegneri — passo per passo, componente per componente, con una procedura di verifica, una procedura di rollback, scenari di test e una checklist di accettazione — e sono le vostre persone o i vostri altri fornitori a eseguirla. Teniamo quella linea perché un auditor che implementa anche ha un interesse in quello che l’audit trova.

Domande adiacenti

Due revisioni che si assomigliano e non lo sono

Usate già CUBA Platform

Allora la domanda non è se la piattaforma sia adatta — lo era, la discendenza è la stessa, ed è arrivata a fine vita. Quella è una valutazione di migrazione, e pone domande diverse: cosa si sposta, cosa viene riscritto, cosa non ha un sostituto

State sostituendo qualcosa di più vecchio

Oracle Forms, Delphi, PowerBuilder, un monolite Java EE. La questione della piattaforma è secondaria rispetto a una più difficile: cosa fa davvero il sistema oggi, dato che nessuno lo ha messo per iscritto dal 2009. La revisione parte da lì.

Domande

Quelle che arrivano prima che qualcuno firmi

Le licenze le vendete voi. Perché il vostro consiglio dovrebbe valere qualcosa?

Perché la licenza è la cifra piccola. Una decisione di piattaforma vi impegna per diversi anni di ingegneria, assunzioni e manutenzione, e il costo di sbagliare è di un ordine di grandezza superiore a qualsiasi cosa guadagniamo sull’abbonamento. Preferiamo essere il fornitore che chiamate per il prossimo sistema piuttosto che quello che vi ha venduto una piattaforma non adatta a questo. Anche questo è interesse nostro — solo della specie a lunga scadenza.

Cosa vi serve davvero da noi per una revisione?

Meno di quanto si aspetti la gente. Una conversazione con chi conosce il dominio, una conversazione con chi manterrà il sistema e la documentazione che esiste — anche se è un foglio di calcolo e tre screenshot. Se esiste già un sistema, l’accesso in lettura allo schema del suo database vale più di qualsiasi specifica.

Esaminate solo decisioni su Jmix?

No. La domanda di solito è "su cosa va costruito questo", e Jmix è uno dei candidati fra diversi. Conosciamo meglio l’ecosistema Java e Spring, e lo diciamo invece di fingere una neutralità che non abbiamo. Se la risposta onesta è uno stack in cui non lavoriamo, resta comunque la risposta.

E se avessimo già acquistato le licenze?

Allora la revisione riguarda come usarle bene, oppure come limitare i danni — entrambi sono incarichi reali. Una piattaforma già pagata è un costo sommerso, e continuare a costruire su una scelta non adatta per questo motivo è l’errore costoso, non la licenza.

Si può fare a distanza?

Sì, e la maggior parte si fa così. Una giornata in sede aiuta quando il dominio è inusuale o quando le persone che lo capiscono non mettono nulla per iscritto — cosa comune e non una critica.

Quanto costa?

Una revisione è da due a cinque giorni del tempo di un ingegnere senior, preventivata a compenso fisso prima di iniziare. Se si trasforma in una realizzazione, è la prima fase di quella realizzazione e non un extra. Se si trasforma in "non fatelo", ha fatto il suo lavoro e vi è costata una frazione dello scoprirlo al nono mese.

Prossimo passo

Portate il sistema che state cercando di sostituire

Non il documento dei requisiti — la cosa che le persone usano davvero oggi, e la persona che sa perché funziona così.

Da due a cinque giorni

Revisione dell’architettura

Una raccomandazione, un dimensionamento con le sue ipotesi, un elenco dei rischi — e un "no" se è quella la risposta. Compenso fisso, concordato prima di iniziare.

Contesto

Che cos’è Jmix, senza la brochure

Il modello di licenza spiegato come si deve, il tipo di progetto a cui si adatta e quelli a cui non si adatta.