Actionable models

Because wording is important: it is the way to communicate a clear message. I have found to be useful to use the wording “computable models” to communicate those kind of precise models that can be used to drive software generation, that can be processed in order for example to be transformed, stored, searched. The message to drive is that there are type of models that are semantically rich.
A weak model is one that has been drawn with MSPaint or Powerpoint, even if drawn with a correct notation it's value is very limited because a software program can not 'decode' it, can not extract the semantics, its value is clear (and even partially) from a human being.
This is the effect I'm trying to deliver with the wording “computable model”. But I realize that this is not enough, a model drawn with PowerPoint is also computable because it can be transformed in pdf or in Open Office Impress, a more useful way to drive the message can be “actionable model”.
In this way we deliver a more efficient message, a model can be target of an action or drive actions, can perform something.

This goes beyond the property of being 'simply' computable: it's not a picture of button in a console, in a button that can be operated to deliver an action or perform a function.

Correlated Architectures

Enterprise Architecture are about visibility of information, including the processes, services, resources, data descriptions and rules and policies of government. They also describe government, how it works, its resources and services
These architectures, as an information, is often captured in different kinds of viewpoints, and most of the time as models.
Good Architectures make all the data more valuable by describing how they co-relate with other organization dimensions.
The most valuable architectures are models with a formal meta model or schema, e.g. TOGAF among others.
But currently – most models are not web data accessible, they are trapped in tools, files and worst then even images as pictures and theese odels are not linkable or linked across other models. There can be models for business processes, it portfolio management, organization structures, strategies and intents, data schemas, balance scorecards, soa interfaces...
Architecture models are just data, and as such they shall be federated, analysed, queried, linked and mashed up – data to be published.
As for information they can be unconnected, redundant and not usable outside their source.
There is the need to design and develop various tools, approaches and techniques for querying, viewing, federating and analysing the architectures of the organization as a whole, this can enable consistent visibility and collaboration, provide for external comments and input from stakeholders
Last but not least, having computable architectures, we can pretend to drive and affect the organizaitons from them, making it live, more then aligned with the business, they are the nervous system of the organization.

Spaghetti Modelling

The modelling based architectures, like MDA, MDE, MDD, enforce essentially a strong separation of concerns bewteen the business architecture and the technical architecture. By simply having models for defining the processes, the rules and the functional specification in general separated from the technicalities such as service binding, design pattern, deployment, state management ... is a great strategy to improve reuse, scalability, division of work across team, software life cycle, asset creation and so forth.
In essence, the application can be defined as a set of models; for example business processes, business entities class model, interfaces, UIs, business rules, component models, ... but this is not sufficient for a clear and neat model structure. The risk in ending with Spaghetti Modelling is still here; we will not end up with a comprehansible set of models of the application just because we are adopting a model driven approach.
Care must be taken in creating a proper model set that is comprehensible and that does not mix the various logical views. This risk can be reduced by adopting an application metamodel (call it application template if you wish) but it's not sufficient, in general there is the need for a good modelling practise that comes of course from the experience but also from the the good old motto "think before modelling" (aka "think before coding").
We will less an less write lines of programming language in the future (that is already here) but we will always abstract the problem space into a solution space, that is the same class of problem.

SQL NO, NoSQL

Yesss, finally a movement for SQL alternative for data persistence and retrieval! There 'can be' something better.
Why lumping SQL relational statements for searching data that are natively object oriented?
Why tables, inner-outer join, stored procedures, custering of relational tables? Data is to be managed in a language and approch in line with the way we manage them in memory.
Yes, we can do better then SQL and these guys have strategies, ideas and tools!
The issue is far too complex to be addressed by a Blog here, but the problem is real and new way to deal with data persistence and retrieval is here especially now with "cloud computing" and the need to manage Tera and Peta bytes. There is more then quey language and ORM (Object Relationak Mappings), RDBMS demostrate not to be able to scale, simply because the cost is exponential and the ability to spend in RDBMS clusters is not infinite.

Ingegnerizzare il software, una chimera?

Molti, quasi tutti direi, si ispirano ai processi ed a i metodi dell'ingegneria civile per strutturare e gestire il ciclo di vita di un progetto software: i metodi detti "ingegneristici" sono visti come un faro a cui tendere ed inquadrare finalmente in un'ottica di metodo e qualità lo sviluppo del software. Secondo me è una chimera e pure un rischio perché non si è capito che le due cose come fondamentalmente diverse ed incompatibili; non si può progettare e realizzare un software con i metodi con cui si progetta e realizza un punte. Perché? Seguiamo un ragionamento.
Nell'ingegnerie civile il costo di spostare un pilastro é un'ordine di magnitudine superiore al costo di costruirlo. Da millenni l'uomo prima di costruire una struttura o un edificio lo ha prima accuratemente progettato, dalle piramidi, ai ponti romani a San Pietro a Roma. L'istinto che abbiamo con questo tipo di costruzioni è: prima progetto e poi costruisco. Se dobbiamo costruire un'artefatto anche piccolo come un tavolo o una cassapanca prima di tutto facciamo un piano, un disegno, uno schema se non pure un prototipo, prima della sua costruzione. Perchè sappiamo ed abbiamo l'istinto che modificare in corso d'opera è estremamente costoso, buttiamo via materiale e tempo, c'è poca probabilità di riusare quello che è già stato fatto. In informatica abbiamo una anomalia particolarissima: il costo di modificare un artefatto software è una frazione del costo di realizzalo. Tutti noi all'inizio delle nostre esperienze informatiche abbiamo vissuto l'esperienza di realizzare subito e modificare dopo, perché "si fa prima", perché "tanto modifico dopo". L'istinto è di tutt'altra natura. Ho visto aziende mature e di successo con la stessa mentalità, partire a sviluppare senza piano o progetto o disegno perché tanto, si pensa, a modificare ci penso sopo. Questa è una anomalia in cui molti ci cascano, e debbo dire che pure li capisco. Una variabile si valorizza al volo, un software si duplica, si reinstalla, il valore di una tabella si cambia in un attimo. L'istinto di modellare, progettare, disegnare prima ed un anticipo non c'è ed il motivo è quello: modificare costa meno che fare. Poi aggiungiamo la fretta e l'agitazione di fare presto che permea l'informatico, allora abbiamo un bel quadro completo: ho visto "analisti" in piedi dietro un programmatore a dirgli cosa fare!

I processi di ingegneria hanno milleni di esperienza e si sono adattati al fatto che i requisiti di un ponte o di un edificio sono statici come la struttura che deve essere relalizzata, c'è molto poco spazio per gestire i cambiamenti. Spesso se i requisiti cambiamo, un ponte non basta più. si butta giù e si rifà. Ad un ingegnere civile non si chiede di allungare un ponte, o di spostarlo o tanto meno di costruire un altro piano mentre sotto il traffico scorre ancora. In informatica non ci meravigliamo di queste richieste, sono una conseguenza della natura effimera (soft) appunto di questa strana scienza (oddio..scienza, ho esagerato, l'informarica pare più essere un'opinione).

Consideriamo per un attimo anche gli strumenti di sviluppo. Per fare una casa servono degli strumenti costosi e complessi come delle gru, scavatrici e betoniere solo per dirne alcuni. Nessuno di noi pensa che per farsi una casa in un terreno che abbiamo basta fare un corso di "gru" o di "scavatrice". Sappiamo che lo strumento non basta, non serve neppure essere un bravo operatore. Ci sono processi, altri strumenti, tecnologia, scienza, progetti. Questi strumenti sono innanzi tutto costosi da ottenere, voluminosi ed una volta ottenuti non siamo in grado di usarli. Il nostro istinto è di andare dai professionisti! Il nostro istinti è quello di andare da un geometra o da un architetto che poi invocano un ingegnere per la fattibilità che poi chiama un'impresa edile: ogni uno
sa cosa fare ed ha un ruolo ben specifico.

Ah, ma in informatica i tool si possono scaricare da Internet, e sono spesso free a partire dai data base, agli IDE, UML editor, application server, GUI framework, linguaggi, VM, middleware ... tutto freee, tutto scaricabile. E tutti ci sentiamo in grado di metterci ad usarli, tutti credono e hanno il diabolico istinto di poter creare di poter realizzare un software solo perché hanno gli strumenti a portata di un click! Vedo nelle librerie libri contitoli come "XML in 24 ore", "Impare EJB in 2 giorni","Diventa un webmaster", e li vediamo e magari ci facciamo pure il pensierino di prenderli che qualcosa magari insegnano pure. Fate un salto nella sezione "Medicina" e cercate "Diventa un chirurgo del cervello in 24 ore", "Fai fa te: il trapianto di fegato in 24 ore", "Chirurgia vascolare in 48 ore". Se vi fa ridere allora dovete trovare il modo ri ridere anche per quei titoli informatici. Assurdamente ritengo che se i tool pesassero 10kg a Megabyte, se occupassero 1m^3 a Mbyte avremmo meno problemi: dove li mettiamo? Questa manna di tool free e potenti a disposizione non hanno bene all'informatica secondo me, avremmo contrastato questa mania di onnipotenza, poter realizzare qualunque cosa solo perché abbiamo accesso agli strumenti. Pensate a quanti disastri avremmo fatto se possedere una ruspa o una scavartrice fosse facile e economico come comprare una levigatrice.

Mettiamo assieme le due cose:

costa meno modificare che fare
gli strumenti sono accessibili a tutti
e vediamo che viene rivoluzionata una buona fetta di quegli elementi propri dell'ingegnerie civile, quello che resta è il knowhow ed i processi che finiscono sottostimati e sono la causa principale del fallimento dei progetti IT.

Comunque, non mi si fraintenda: in informatica quando si realizza del software c'è ovviamente bisogno di progettare e molto! Serve "pensare" a priori prima di scrivere un "main", ma non per gestire la complessità della realizzazione del prodotto software, non per la sua realizzazione ma per ottenerne la scalabilità e la manutenibilità, per poterlo gestire nel suo ciclo di vita. Il software è quasi un essere biologico, non è immutabile. Sono aspetti che nell'ingegneria civile non sono gestiti. E' un aspetto non intuitivo che il cliente innanzi tutto non chiede per primo (lo vuole dopo, assume "dopo" che avrebbe potuto scalare sulla tecnologia 'x' a costi '0'), ma lo vede solamente l'informatico, l'architetto che può dire "ne ho viste di cose che voi umani non potete nemmeno immaginari", ho visto progetti perfetti fallire per non aver gestito un requisito, per non aver saputo scalare il numero di utenti, per non essere stati in grado di supportate l'estensione delle funzionalità, per essere stato in grado di supportare una diversa piattaforma...pare che siamo anche incapaci di imparare.

Del famoso Tacoma bridge, non metto neppure un URL qui, trovatevelo è un caso famosissimo, è stato studiato a fondo per evitare che si ripetano tali errori: in informatica pare non si faccia lo stesso, un'analisi post mortem di un progetto è sempre da assegnare ad un “capro espiatorio”, spesso erroneamente alla tecnologia “X”, pare che in informatica non si possa imparare dagli errori.

Alla via così.