Wednesday, July 20, 2005
Highly Configurable Applications are Languages Too
In the past few months I've been consulting for a company trying to redesign a payroll system, mostly targeted at the public administration (my Italian readers will probably understand the almost unbearable complexity of that :-)). They already have a working system, highly configurable to handle the peculiarities of the different institutions.
Highly configurable applications are both a boon and a hindrance. They can save enormous development time in the long run. But they can be easily misused; they can easily get out of control; it's often hard to understand why the application is misbehaving, or even why is it working properly :-).
Back to the payroll: when they first tried to improve over the existing version by using object technology, it seemed like objects didn't work so well. They could see no advantages in using objects to mimic tables or queries, basically writing the same code in Java instead of using PL/SQL. In fact, there were no advantages.
It was necessary to rethink the system from a different perspective, from where objects could be actually quite useful. The system we are designing now is basically built on the idea that we need a very powerful language to define rules and formulas, and that most of the business knowledge must go into the language, not into the formulas, so that all our configurations will be simple to write, simple to read, simple to maintain.
In fact, all highly configurable applications are languages. They're simply not designed that way. That's why they become so brittle. I can think of several industrial applications where adding (e.g.) a sensor requires the editing of a few (obscure) XML or INI files, perhaps some changes into a database through custom programs, and so on. Make a single mistake, and you'll break the integrity of the system, with unpredictable consequences.
You may have never thought of those configurations as a language - but that's what they are. Unfortunately, it's often a composite language, growth out of needs, not from careful design, and it usually shows. One of my customers is suffering configuration problems almost every day, in plants all around the planet. I guess our next highly configurable application will be significantly different from the past :-)
Highly configurable applications are both a boon and a hindrance. They can save enormous development time in the long run. But they can be easily misused; they can easily get out of control; it's often hard to understand why the application is misbehaving, or even why is it working properly :-).
Back to the payroll: when they first tried to improve over the existing version by using object technology, it seemed like objects didn't work so well. They could see no advantages in using objects to mimic tables or queries, basically writing the same code in Java instead of using PL/SQL. In fact, there were no advantages.
It was necessary to rethink the system from a different perspective, from where objects could be actually quite useful. The system we are designing now is basically built on the idea that we need a very powerful language to define rules and formulas, and that most of the business knowledge must go into the language, not into the formulas, so that all our configurations will be simple to write, simple to read, simple to maintain.
In fact, all highly configurable applications are languages. They're simply not designed that way. That's why they become so brittle. I can think of several industrial applications where adding (e.g.) a sensor requires the editing of a few (obscure) XML or INI files, perhaps some changes into a database through custom programs, and so on. Make a single mistake, and you'll break the integrity of the system, with unpredictable consequences.
You may have never thought of those configurations as a language - but that's what they are. Unfortunately, it's often a composite language, growth out of needs, not from careful design, and it usually shows. One of my customers is suffering configuration problems almost every day, in plants all around the planet. I guess our next highly configurable application will be significantly different from the past :-)
Comments:
<< Home
Ma cosa intendi esattamente con: "all highly configurable applications are languages"?
Forse che รจ possibile portare al limite estremo la pratica di avere un file di configurazione che viene utilizzato all'inizio dell'applicazione per creare e collegare le giuste istanze delle classi principali del sistema? Quindi invece di avere un file .ini o xml utilizzare un vero e proprio linguaggio che consenta di creare, collegare e configurare istanze di classi che stanno dentro librerie a caricamento dinamico?
Forse che รจ possibile portare al limite estremo la pratica di avere un file di configurazione che viene utilizzato all'inizio dell'applicazione per creare e collegare le giuste istanze delle classi principali del sistema? Quindi invece di avere un file .ini o xml utilizzare un vero e proprio linguaggio che consenta di creare, collegare e configurare istanze di classi che stanno dentro librerie a caricamento dinamico?
# posted by 
: 10:19 PM
: 10:19 PM
Intendo una cosa piu' radicale: che anche se la nostra configurazione nasce in modo "espediente" e non pianificato, e che quindi si ritrova sparsa in uno o piu' file / database di vario tipo, e' comunque un linguaggio. Solo che ovviamente diventa un linguaggio difficile da usare, perche' non progettato. Conseguenze comuni sono:
- la ridondanza di concetti, che rende necessaria la modifica "incrociata" di piu' file / sezioni / ecc.
- la difficolta' di capire quali sono le reali interazioni di N parametri di configurazione.
- la difficolta' di capire quali sono i reali effetti di un parametro, ovvero quali porzioni di codice finisce realmente per influenzare.
Il punto e' quindi doppio:
- Non importa come gestisci la configurazione, un linguaggio lo hai comunque, magari molto eterogeneo e sparpagliato. Due INI, un XML, una tavola di DB relazionale formano un linguaggio non esattamente idilliaco.
- Se, come accade piuttosto spesso, la configurazione e' un elemento centrale dell'applicazione, e' meglio che non sia un linguaggio nato a caso, ma che venga progettato come parte integrante dell'applicazione.
Poi, per arrivare a quanto dici, a volte mi basta un XML o addirittura un INI, a volte mi serve un linguaggio di espressioni (con molta logica di business dentro, non nelle espressioni) con un opportuno interprete dentro l'applicazione, ecc ecc.
Post a Comment
- la ridondanza di concetti, che rende necessaria la modifica "incrociata" di piu' file / sezioni / ecc.
- la difficolta' di capire quali sono le reali interazioni di N parametri di configurazione.
- la difficolta' di capire quali sono i reali effetti di un parametro, ovvero quali porzioni di codice finisce realmente per influenzare.
Il punto e' quindi doppio:
- Non importa come gestisci la configurazione, un linguaggio lo hai comunque, magari molto eterogeneo e sparpagliato. Due INI, un XML, una tavola di DB relazionale formano un linguaggio non esattamente idilliaco.
- Se, come accade piuttosto spesso, la configurazione e' un elemento centrale dell'applicazione, e' meglio che non sia un linguaggio nato a caso, ma che venga progettato come parte integrante dell'applicazione.
Poi, per arrivare a quanto dici, a volte mi basta un XML o addirittura un INI, a volte mi serve un linguaggio di espressioni (con molta logica di business dentro, non nelle espressioni) con un opportuno interprete dentro l'applicazione, ecc ecc.
<< Home
