domenica 28 febbraio 2010

Filiera Editoriale - verso la Definizione dei Requisiti del Profilo OSE

Continuo in questo post il discorso iniziato la settimana scorsa in cui ho illustrato le ragioni per cui, per un migliore Modello di Filiera, credo sia più opportuno fare riferimento alla profilazione OSE. Anche per meglio interiorizzare alcuni concetti, vi propongo di seguito alcune fondamentali definizioni [per adesso pescate su Wikipedia]. Quindi tornerò a servirmi del documento di Luigi.

Il Modello OSE si basa essenzialmente su tre entità:
[1] Application Software: dati, documenti e programmi

[2] Application Platform: componenti hardware e software che garantiscono le generiche applicazioni e i servizi

[3] Platform External Environment: insieme degli elementi esterni alle applicazioni software e alle relative piattaforme (per esempio servizi forniti da altre piattaforme/periferiche)
Quanto alle interfacce, il Modello ne prevede due classi:
[1] Application Program Interface (API): Interfaccia tra Application Software e Application Platform che viene categorizzata in dipendenza dei tipi di servizio accessibili grazie alle API stesse [Human/computer, Information interchange, Communication, Internal system]

[2] External Environment Interface (EEI): Interfaccia che supporta il trasferimento delle informazioni tra la Piattaforma e l'Esterno e tra le Applicazioni residenti sulle Piattaforme stesse. Le EEI sono classificate in accordo al tipo di servizio di trasferimento informazioni; un tale servizio può avere luogo tra umani, data store e altri applicativi

Prima di iniziare il cammino, come ultima definizione, fornisco quella di Profilo. Sempre da Wikipedia [lascio la definizione in inglese perchè molto efficace]:

An OSE profile is composed of a selected list of open (public), consensus-based standards and specifications that define services in the OSE/RM. Restricting a profile to a specific domain or group of domains that are of interest to an individual organization results in the definition of an organizational profile.

Torna ora utile Luigi dal quale prendo in prestito la descrizione del processo da utilizzare per la definizione di un tale Profilo e, nello snocciolare le azioni da compiere per una buona profilazione OSE, comincio ad introdurre qualche elemento relativo all'oggetto da modellare: la Filiera Editoriale.

Come avevo già fatto per il Modello ISO/OSI, anche con questo approccio OSE-oriented, distinguerò il Modello di Filiera del Cartaceo e quello del Web. Alla fine della progettazione dovranno essere ricavate indicazioni su un vincente Modello Editoriale di Business. Ma andiamo con ordine.

Il processo di generazione di un Profilo OSE è fatto di quattro fasi:

[Fase 1] Selezione dello scopo per cui il profilo OSE deve essere utilizzato
Lo scopo della definizione del profilo OSE mi sembra sia chiaro: modellare la Filiera Editoriale esplicitando sia il punto di vista del Generatore sia quello del Fruitore dei contenuti. L'uso di questi termini [a dir la verità nemmeno troppo tecnici] non vuole in nessun modo rappresentare un distacco dal carattere di fondo che deve contraddistinguere l'Environment: il carattere Umano.

[Fase 2] Identificazione dei requisiti utente in termini di user functionality, attributes e constraints addizionali
In un approccio di tipo Top-Down [che metta, cioè, al centro il Fruitore] è normale che il profilo dovrà, del Frutirore, rispecchiarne le esigenze.

Dovendo, però, questo Modello OSE della Filiera Editoriale creare una base oggettiva e di partenza per definire il miglior Modello Editoriale di Business, non si può in nessun modo prescindere dalla logica materiale che inevitabilmente si cela [ma nemmeno troppo] dietro tale Sistema: il contenuto va venduto! Magari non sarà proprio il Fruitore a privarsi del soldo ma è fuori di dubbio che il sistema va, per prima cosa, tenuto in piedi dal punto di vista economico.

Detto questo, tale Modello dovrà mettere al centro della sua definizione tre aspetti essenziali:
  1. la funzione che deve essere svolta per l'utente dal Sistema modellato dal profilo [ho parlato di funzione ma si potrebbe parlare anche di servizio]: forse un pò impropriamente la funzione/servizio è quella di fare informazione/approfondimento [in effetti fare l'una o l'altra cosa possono cambiare il Profilo in modo anche abbastanza radicale; se si contempla, poi, una loro coesistenza il Profilo da usare può avere ulteriori sfumature]
  2. le caratteristiche essenziali distintive di tale funzione/servizio: una delle caratteristiche della funzione/servizio potrebbe essere la gratuità per il Fruitore [per il Fruitore e non in generale per l'Environment in cui il Sistema è immerso]; un'altra, per esempio, potrebbe essere la possibilità di ricevere e dare feedback
  3. eventuali condizioni al contorno o, forse meglio, limiti imposti dall'Environment in cui il profilo dell'Open System va definito: beh, il constraint che individuo è l'essenza stessa del Modello di Business ed è rappresentato dalla sostenibilità economica della Filiera

[Fase 3] Descrizione dell'architettura del profilo
Tenendo presente come linea guida l'architettura tipo del profilo, cioè considerando la struttura base del Modello OSE, verrà costruito il miglior modello della realtà attuale [Filiera del Cartaceo] per poter poi evolvere, tenendo presente tutti i constraint, verso il Modello della Filiera Web e, quindi in un Modello, eventualmente ibrido, rappresentativo [si spera] di un buon Modello di Business.

[Fase 4] Specifiche del profilo
Per creare, infine, una base comune si darà vita ad una vera e propria specifica del Modello. La specifica del Modello costituisce l'obiettivo della mia ricerca.

Nei prossimi tempi, che spero siano i più brevi possibile, mi dedicherò allo studio, considerando di fondamentale importanza le fonti che, anche in questi tempi di silenzi più o meno forzati, non ho mai smesso di consultare. Alcune altre ne ho individuate. Insomma c'è da lavorare!

Se pensate ci siano elementi da definire meglio prima della partenza ditelo adesso o tacete per sempre :)

7 commenti:

LB ha detto...

Da definire/capire meglio, ma dubito che sia possibile: l'impatto della metafora sociale sul lavoro che ti proponi di fare.

La Figura 2 dell'articolo NON scientifico che ho contribuito a scrivere (riportato in questo tuo post) me la sono inventata per tentare di catturare il bisogno di un processo di riconciliazione tra le attività di tre contesti di lavoro o framework:
1) lo sviluppo degli standard
2) la specifica degli user requirement
3) l'integrazione di componentistica tecnologica

Oggi taglierei corto e direi che serve URGENTEMENTE un processo di riconcilazione tra la logica del business e le esigenze degli utenti.

Ci vuole un altro tipo d'interfaccia. Non credo la si possa rappresentare in uno schema a blocchi.

Forse, per riuscire a percepire un nuovo tipo d'interfaccia, ci si deve immaginare di sostituire Application Software con User e Application Platform con Web.

Adesso posso tacere per sempre ;-)

LB ha detto...

PS - Per farsi seriamente qualche domanda e cercare delle risposte collettive

Marco Dal Pozzo ha detto...

Luigi,
tu dici: Oggi taglierei corto e direi che serve URGENTEMENTE un processo di riconcilazione tra la logica del business e le esigenze degli utenti.

Su questo almeno siamo d'accordo. E' questa la linea guida. Tradotta in altri termini la cosa potrebbe dirsi come: identificazione di un servizio che sia rispondente alle necessità ed esigenze delle Persone e sostenibile economicamente!

Tutto qui! Adesso si lavora :)))

P.S. dopo lo spavento delle 19.27 di ieri in cui dicevi che avresti taciuto per sempre, mi rincuora ritrovarti dopo meno di 12 ore :D

LB ha detto...

Tutto qui?

Hai detto niente!

L'espressione Tutto qui! è riduzionista.

La cosina semplice e pulita che hai descritto .. identificazione di un servizio che sia rispondente alle necessità ed esigenze delle Persone e sostenibile economicamente! .. è motivata da una logica di business, non da una logica di bisogno.

La profilazione OSE ha tra i suoi obiettivi l'interoperabilità.

Gigi Cogo ci ha mostrato un annuncio, sull'inteoperabilità, che mostra quanto gli approcci proposti siano lontani dal coinvolgimento dell'utente .. lasciato a valle .. di attività che lo mantengono in attesa di soluzioni prefabbricate.

Se ti deprime quello che dico mi ripropongo di tacere per sempre .. eh .. eh :-)

Marco Dal Pozzo ha detto...

Luigi,
non sono d'accordo! Il bisogno di essere informati c'e' e c'e' anche chi tenta di erogare servizi che soddisfino questo bisogno.

L'erogazione di un servizio ha i suoi costi e chi ne beneficia deve accettare di sostenerli.

Logica di Business, puo' darsi...ma la vedo cosi'!

Quello che mi dici non mi deprime affatto...il mancato coinvolgimento dell'Utente [lasciami dire, delle persone quando non addirittura di tutti gli attori in gioco: lettori, autori, giornalisti] e' il problema! E' un problema di interoperabilita'? Forse! Magari lo scopriro'...

Ma non diciamo che non ci sia di mezzo un business perche' mentiremmo a noi stessi! Non credi?

:)

Anonimo ha detto...

Write more, thats all I have to say. Literally, it seems as though
you relied on the video to make your point. You clearly know what youre talking about, why waste your intelligence on just posting
videos to your site when you could be giving us something enlightening to read?


Also visit my web-site :: voyance par telephone

Anonimo ha detto...

Howdy! This is my first visit to your blog! We are a team of volunteers and starting a new project in a community in the
same niche. Your blog provided us useful information to work on.
You have done a marvellous job!

Also visit my homepage voyance