Voordat ik bovenstaande titel gaproberen uit te leggen eerste een vraag: Via welke bedrijfsapplicaties heeft Utoegang tot ongestructureerde data (content) en waar wordt die content beheerd? Grote kans dat het aantal applicaties en het aantal beheeromgevingen in dezelfdeordegrote zitten. Met alle gevolgen van dien: hoge beheerskosten, multiplicatievan autenticatie- en autorisatiestructuren, content zoeken, terugvinden enkoppelen gaat moeizaam. Door de explosieve groei van content binnenorganisaties en de doelen die organisaties zich stellen zoals betere service, kortere “time-to-market”, lagere kosten, meer groei, end. wordt content alsproductiefactor steeds belangrijker. Door gebrekaan open standaarden en gesloten ECM systemen zijn door de jaren heen veel content silo’s ontstaan.
Meer CaaS kan helpen die situatie te verbeteren. Vooral Enterpise 2.0 initiatieven eigenen zich hiervoor. CaaS staatvoor Content-as-a-Service en kan op twee manieren worden geïnterpreteerd. Ten eerste als een (web) service die via open standaarden en API’s als een opencontent repository voor applicaties of andere services kan dienen. BasicContent Services, zoals Gartner ze noemt, zijn voor de meeste applicaties voldoende. Een tweede interpretatie van CaaS is als een SaaS (Software-as-a-Service) applicatie. In "Software uit de kraan leidt tot stroomversnelling ECM" is al aangegeven dat veel ECM systemen een afgebakendeoplossing zijn. Om de in dat artikel genoemde grootste valkuil te vermijden dient de eerste interpretatie van CaaS werkelijkheid te zijn. Zonder CaaS geen goede SaaS.
Extranets faciliteren de eisen van de gebruiker en organisatie om content ook buiten de organisatiegrenzen te delenen met andere partijen samen te werken. Doordat de meeste organisaties eenextranet hebben ontstaat de discussie: gaan we jouw of mijn extranet gebruiken? Los van de discussie wordt pijnlijk duidelijk dat de processen geïntegreerd gaan worden richting Extended Enterprise, maar dat de onderliggende contentinfrastructuur daar geen eenvoudige oplossing voor biedt.
Naast SOA zien we dat met Web 2.0 en Enterprise 2.0 met succes mashups worden gebruikt om verschillende applicatiesen content met elkaar te integreren. Door openheid en open standaarden kan de content uit meerdere repositories op een voor de organisatie gewenste wijze worden samengebracht. Applicatiecomponenten en content kunnen op een lichtgewicht manier (vaak mbv REST) met elkaar geïntegreerd worden. Het succesvan veel Web 2.0 sites is hieraan te danken. Verschillende content services kunnen door gebruikers zelf samengevoegd worden. Dus content managementservices als hapklare brokken aanbieden die iedereen eenvoudig kan consumeren. Blokjes CaaS uit het vuistje.
Meer CaaS uit het vuistje maakt hetmogelijk om met betrekkelijk weinig inspanning de organisatorische (maar ookandere) grenzen van ECM te doorbreken. CaaS als content infrastructuur en CaaS als applicatie- (integratie) componenten vragen beide het ECM “suite denken” tedoorbreken. CaaS dient een betrouwbare, schaalbare, open commodity content servicete zijn die door meerdere applicaties zowel binnen als buiten de organisatiegebruikt kan worden. Veiligheid is natuurlijk ook hier een belangrijk punt.Enkele jaren geleden was beveiliging bij SOA nog een zwak punt en nu wordt ditook als een minpunt van Web 2.0 gezien en vooral als het over Enterprise 2.0 gaat. SMash gaat als eerste dit probleem structureel aanpakken. SMash is een open-source initiatief van IBM voor Secure Mashups.Enterprise 2.0 wordt als belangrijk middel gezien om organisatiedoelen te bereiken, volgens een onderzoek van Market IQ, terwijl leidinggevenden niet blij zijn met Web 2.0, volgens het Computable artikel van 28-3-08. CaaS kan een bijdrage leveren aan hetbehalen van die doelen en helpen een brug te slaan tussen ECM en Enterprise 2.0.AIIM’s definitie van Enterprise 2.0 is: “A system of web-basedtechnologies that provide rapid and agile collaboration, information sharing,emergence and integration capabilities in the extended enterprise.” Dit sluit naadloos aan bij het CaaS-denken waarbij hetsucces van Web2.0 en vooral de onderliggende technologieën als basis dienen. Mijn advies is daarom: Meer CaaS uit het vuistje, minder ECM “suite-denken”en begin daar waar bestaande content-applicaties, of gebrek aan applicaties, samenwerken onvoldoende heeft kunnen ondersteunen.
Ik ben het helemaal met je eens Paul! CaaS is een uitstekende manier om content beschikbaar te maken ‘over de silo’s heen’. Maar, zoals je ook al aangeeft, blijft beveiliging een lastig punt. Los van technisch georienteerde initiatieven zoals Smash moeten op organisatorisch niveau de beveiligings- en intellectuele rechten policies goed worden ingericht. Het voorkomen dus van een gaten-CaaS op dat gebied is geen geringe klus.Ik zie daarom meer in CaaS binnen de organisatie, waarmee het mogelijk wordt content centraal te beheren en op transparante wijze beschikbaar te maken binnen de diverse bedrijfsapplicaties. Daarmee is al veel gewonnen ten opzichte van de huidige stand van zaken bij veel bedrijven, waar de ECM suite een van de vele content silo’s vormt. Natuurlijk kan CaaS ook in bedrijfs extranetten en mashups worden ingezet, maar dan wel in een enigszins gecontroleerde omgeving.Eigenlijk ligt daar de uitdaging voor ECM leveranciers: zij moeten de (CaaS) applicaties gaan leveren die het aan de ene kant mogelijk maken om vrijelijk samen te werken op een veilige manier (“Making Candy safe”) en aan de andere kant er impliciet en op transparante wijze voor zorgen dat risico’s en verlies van bedrijfsinformatie vermeden wordt (“Making Aspirin fun”).Ik zal zodra de nieuwe site in de lucht is daar een whitepaper over posten en hoor dan graag jouw reactie daarop.PS. Trouwens, voor bedrijven is “Contant as a Service” natuurlijk het mooiste dat bestaat, wie maakt zich nog druk over “Content as a Service” als het geld vanzelf en ongehinderd binnenrolt? 🙂
Caas uit het vuistje zowel consumerend als beherend. Ik ga in op de consumerende kant, in dit geval de meest krachtige en technisch meest eenvoudige van de twee.Security, infrastructuur, open standaarden, geslotenheid, feitelijk allemaal techniek. Niet altijd even eenvoudig maar ze doen onder voor het functionele probleem; de juiste content vinden. Vinden van content doen we door te zoeken, via meta informatie. Locatie gebonden informatie via googlemaps mashups kan prachtig werken. Een praktische navigatie variatie die content toegankelijk maakt via geografische meta-informatie. De content moet zich er wel voor lenen. Geef meta-informatie, retourneer content. Geef een locatie, afdeling, productgroep, thema, etc. Een webservices, dynamische webpagina, rss feed of een xml retourneert de content. Webtechnologie stelt je in staat dat snel te realiseren. Metadata goed koppelen aan content en het vinden van goede navigatie structuur om ze samen te combineren in een mashup. De eerste is werk waar regelmatig te weinig aandacht aan besteed wordt. De tweede meer van creativiteit en techniek welke voor veel content een grote uitdaging zal zijn. Qua combineren nog een aardige tip; http://pipes.yahoo.com. Qua minder ECM “suite-denken” moest ik echter aan iets anders denken, daar zal ik eerdaags een discussie over starten.
CaaS op het gebied van digitaal samenwerken en document management bestaat reeds. Denk aan Google Apps en Sharepoint live workspace. Projectruimten zijn al een aantal jaren op internet te maken.
Wat deze online initiatieven missen is recordsmanagement. Voor iedere organisatie is het van belang om vast te leggen welke communicatie er in het verleden is geweest en hoe besluiten tot stand zijn gekomen. Soms vanuit het perspectief van compliancy (archiefwet, SOX), andere keren vanuit kennismanagement of risico-management.
Zonder te toevoeging van recordsmanagement blijft Caas een hulpmiddel om in kleine homogene groepen samen te werken en een gemeenschappelijke plek te hebben om documenten te delen. En, inderdaad, zonder dat ECM suites open worden, meer gericht zijn op structuur dan creativiteit en onafhankelijk van plaats en tijd toegankelijk zijn, zullen deze een marginale rol blijven spelen.
De grote vraag is dus: welke leverancier komt hier met een complete CaaS-oplossing?
Een interessant en prikkelend stuk. Toch denk ik dat er een zeer belangrijk aspect onderbelicht is omtrent CaaS dat ik in mijn bijdrage zal toelichten.
Volgens mij kan content niet zomaar als hapklare brok ter consumptie van een ieder worden beschikbaar gesteld, afgezien van technische, juridische of anders procedurele uitdagingen.
Content wordt door Paul omschreven als ongestructureerde data, terwijl ik denk dat content ongestructureerde informatie is. Dit is een belangrijk verschil, omdat data zich veel beter context onafhankelijk laat interpreteren dan informatie.
Bijvoorbeeld: 5 graden celcius is data. Valt moeilijk over te twisten. 5 graden celcius is koud, is informatie. Stel ik lees deze iformatie in de lente in Nederland, dan zal ik de informatie als geldig kwalificeren. Als je deze informatie interpreteert in hartje winter op de Noordpool, dan is deze totaal niet juist.
De betekenis en juistheid van de informatie wordt niet alleen bepaald door lokatie, maar ook door andere factoren zoals cultuur. Een begrip als zedelijkheid zal in een Hollywood anders worden uitgelegd dan in Staphorst.
Een andere belangrijke reden waarom CaaS niet zomaar moet worden toegepast, komt door het feit dat het bronsysteem waarin de content wordt aangemaakt ook betekenis toevoegd aan de informatie. Informatie aangemaakt op Wikipedia wordt toch anders gewaardeerd dan dezezelfde informatie die is aangemaakt op een weblog. Dit geldt ook binnen de organisatie, nieuws van de CEO krijgt een ander belang toegekend dan hetzelfde nieuwsitem in de nieuwsbrief van de afdeling.
Tagging, rating, ranking, reputaties en bronvermelding helpen natuurlijk om Content bij bijvoorbeeld Social bookmarking goed te kunnen plaatsen, maar toch kan uniforme interpretatie niet worden geborgd als het via CaaS wordt ontsloten. Kent de consument van de content wel de bron, de cultuur en de achtergrond van de content?
Daarom suggereer ik ook dat CaaS uitermate zorgvuldig en gecontroleerd moet worden toegepast, bedenk wat mogelijk gevolgen zijn als bepaalde content in een ander daglicht mogelijk een andere betekenis krijgt!
Paul ik onderschrijf je constatering volledig, de huidige bedrijfstoepassingen negeren CONTENT. Ik ben een voorstander van CaaS, ?content als infrastructuur? maar ik zie de relatie niet met het doorbreken van ECM ?suite? denken. Kan een ECM Suite niet de content services leveren die je nodig heb?
Je spreekt over het beschikbaar maken van content via nieuwe Technologies zoals Web 2.0 en mashups. Ik zou een stap verder willen gaan door te stellen dat content binnen de context van een bedrijfsproces gemanaged moet worden. Dit in tegenstelling tot wat nu gebruikelijk is namelijk de content zelf onder proces controle plaatsen. Laat ik dit illustreren met de vraag ?is er zonder content sprake van een (bedrijfs)proces??.
Een bedrijfsproces begint vaak met het ontvangen van een klacht, factuur, bestelling, aanvraag voor hypotheek, verzoekt tot verblijfsvergunning, verzoek tot kinderbijslag, openen of sluiten van een bankrekening. Evenzo zal er tijdens de uitvoering van het bedrijfsproces er meerdere contact momenten zijn met de klant of prospect en uiteindelijk zal het bedrijfsproces eindigen met communicatie naar de betrokkenen.
Voor een kwalitatieve en efficiente uitvoering van het bedrijfsproces is het volgens mij essentieel dat de ?lus tussen inbound en outbound? gesloten kan worden en dat content zijn centrale plaats krijgt in het proces die het verdient. CaaS kan zeer zeker hieraan een bijdrage leveren door o.a. het leveren van diensten voor scanning, capturing, document management, archiving, records management, document output creatie, en document delivery.
Het is dan ook fnuikend om te moeten constateren dat de meeste bedrijfstoepassingen zich concentreren op de efficiency van het proces door het vastleggen van transacties en daarmee nagenoeg negeren waarmee het meestal begint en eindigt namelijk CONTENT. Dit met als gevolg dat grote maatwerk projecten gestart moeten worden om bijvoorbeeld SIEBEL te integreren met een document management product een capturing product, een workflow product, een archiving product en een document output product. Vaak kosten deze implementaties vele malen meer dan de licenties en leveren ze uiteindeijk niet datgene wat nodig is om het bedrijfsproces effectief en efficient te laten verlopen. Waarom, omdat de basis vaak gevormd wordt door transactioneel gerichte systemen zoals in dit geval Siebel (p.s. geldt ook voor Salesforce of ieder ander CRM systeem).
Ook het introduceren van SOA en BPM tools zal hierin niets veranderen (zie discussies op het SOA topic).
Volgens mij is dus niet het probleem dat de ECM?suites? gesloten zijn, volgens mij is het probleem dat de huidige (verticale) toepassingen zich niet bewust zijn van het belang van content. Gartner heeft een paar jaar geleden de term CEVA geintroduceerd. CEVA staat voor Content Enabled Vertical/Value Applications. Ik zeg niet dat het gemakkelijk is om op de huidige ECM producten (want echte suites zijn op 1 hand te tellen) CEVA?s te bouwen maar het wordt gedaan (en met succes) en we zullen gaan zien dat de traditionele producten voor CRM, Campaign Management, Contact Centers, HR, Claim handling en meer specifieke toepassingen voor ondermeer Service organisaties (hypotheek verstrekkers, notarissen, advocaten) zware concurrentie gaan krijgen van nieuwe spelers op de markt die wel in staat zijn om hun toepassingen te bouwen rondom CONTENT en dus gebruik maken van CAAS als content (communicatie) infrastructuur.
Dus in plaats te spreken over Web 2.0 zouden we moeten spreken over CRM 2.0, waar de content en de klant centraal staan en niet de interne processen.
In de reacties zijn al veel zaken zijn aangedragen, waar ik het mee eens kan zijn. Toch wil ik nog een stukje toevoegen.
Hoewel er altijd over definities en betekenissen gediscussieerd kan worden, ben ik bang dat zonder een goed begrip daarvan de CaaS-discussie verwarrend kan worden. We hebben namelijk te maken met ruwe data, de metadata en de context. Content – want daar draait het gegeven het acroniem om in CaaS – is ongestructureerde data die is gekwalificeerd met beschrijvende data. Informatie is het gebruik van content in een bepaalde context.
Om het voorbeeld van temperatuur te extrapoleren, 5 graden is data. Eenheid (celcius), locatie en tijdstip is metadata. De kwalificatie koud kan alleen gegeven worden door de context en die is in dit geval het historisch besef van gemiddelde temperaturen op een bepaald tijdstip in een bepaalde locatie. Voor CaaS is ‘koud’ niet relevant. Want stel nu dat ik als wetenschapper in Lapland die 5 graden Celsius in maart in De Bilt gebruik als norm voor ‘normaal voor de tijd van het jaar in een gematigd zeeklimaat’. Dan heb ik niets aan een content service die me ‘koud’ levert.
De content moet dus gaan over de ruwe data en haar metadata.
De context is het gebruik van de content zoals die door een stukje CaaS wordt geleverd en is van doorslaggevende betekenis bij het vaststellen van de (waarde van de) informatie. Deze context wordt vaak gecreeerd door een bedrijfsproces. In de afhandeling van een schadeclaim heeft een factuur waarop de aankoop van een bepaald goed is vastgelegd, een andere waarde dan deze zelfde content in het verkoop proces en weer een andere dan in processen ter handhaving van fiscale wetgeving. Drie verschillende contexten en dus drie verschillende stukken informatie. Potentieel een service.
Het aspect ‘service’ zou naar SOA kunnen neigen maar ik neem aan dat het in algemene zin, een herbruikbare request-response functionaliteit is, die content ter beschikking stelt aan de hand van gespecificeerde kenmerken van de content. Het zou dus net zo goed een old-fashioned COBOL copybook kunnen zijn. Dit is van belang omdat de beperking tot SOA-achtige technologie, CaaS tot een kansloze missie maakt. SOA is nog steeds niet van de grond gekomen, kampt nog steeds met management problemen en levert nog steeds niet hetgeen er beloofd is. De SOA-discussie wordt reeds elders gevoerd, maar het is relevant omdat de de-facto keuze voor ‘service’ hedentendage een keuze voor op zijn minst webservices en veelal SOA zal zijn.
De vraag wordt nu: wat voegt CaaS toe aan het reeds bestaande spectrum van mogelijkheden om content op basis van een beschrijving van haar metadata uit een repository te krijgen? Alle zich wel respecterende ECM suites hebben een mogelijkheid om middels webservices of een API content aan het systeem te onttrekken.
Is het de bedoeling om vanuit een context (bijvoorbeeld een CEVA) vanuit verschillende repositories content op te vragen via een service? Hoe moet dat werken met verschillende documenttypen en de daarop vastgelegde metadata? Kan dat uniform? Wanneer CaaS een content broker wordt natuurlijk wel. Maar zonder deze EAI/SOA-gedachte? Ik denk van niet.
Is het de bedoeling om vanuit alle repositories dezelfde (soort van ‘one size fits all’) service aan te bieden voor het geval er ooit een CEVA komt die er gebruik van gaat maken? Ik zie het niet gebeuren.
Dit alles neigt naar de SOA-utopie waarbij we denken service generiek en herbruikbaar te kunnen definieren en implementeren. De SOA praktijk heeft al aangetoond dat het niet zo werkt.
Vanuit de gedachte dat er zonder proces geen content is en zonder content geen proces en met de wetenschap dat er altijd maar een bedrijfsproces is dat eigenaar van de data is, is CaaS opeens niet zo heel belangrijk meer. De CEVA die dat bedrijfsproces realiseert zit al bovenop de content. Het is heel aannemelijk dat alle andere CEVA’s gebruikers van deze content zijn en kunnen werken met een standaard interface naar deze content.
Basic Content Services veranderen daar niets aan. De bedoeling daarvan is, om de meest basale functionaliteiten van document management op een voor de eindgebruiker volledig transparante manier op te nemen in de dagelijkse handelingen. Dus je slaat je MS Word bestand op, op een file-share en ongemerkt wordt er versie-beheer toegepast.
Hoe zou het dan werken met mashups? Dat is – neem me niet kwalijk – qua content niet veel meer dan oude wijn in een nieuwe zak. Dit keer wel een gelikte zak. 10 jaar geleden ontwikkelde we al componenten die nieuwsberichten van providers als Reuters en Lexus Nexus samenvoegde met interne nieuwsfeeds tot een gecombineerde XML content provider waaruit applicaties de voor hen relevante berichten uit konden halen en tonen in hun context. Tegenwoordig zou je daarvoor RSS inzetten. De hype van de mashup zit hem er in dat het nu de eindgebruiker is, die meerdere bronnen samenvoegt tot een persoonlijke context.
Maar laat ik positief eindigen. Het doorbreken van de ‘ECM suites’ gedachte is meer dan ooit nodig. Vanuit een technisch oogpunt is het nodig omdat de ‘suite’ niet meer is dan een verzameling aan elkaar geplakte applicaties. Vanuit het oogpunt van een bedrijfsproces is het nodig omdat het daar gaat om de CEVA die van de juiste en volledige content gebruik maakt. Hiermee verdwijnt de ‘suite’ onder water en uit het zicht.
Je stelt dat CaaS als content infrastructuur en CaaS als applicatie- (integratie) componenten vragen om het ECM “suite denken” te doorbreken.
Daar zit wel wat in. Deze suites zijn veel te veel gericht op technisch ontsluiten van hun eigen gesloten omgeving, of zijn gericht op de verpakking van de content (documentmanagement, records management etcetera)
Informatie gebruikers hebben het echter -meestal- niet meer over de content-DRAGER (document, e-mail, etc.) maar veel meer over de INFORMATIE die in deze content zit.
Dat deze informatie essentieel is voor hun processen, en daarmee hun toegevoegde waarde.Dat ze snel, compleet toegang tot de juiste informatie willen hebben. Dat de informatie die in de content staat juist de aanleiding is voor hun (verdere) acties.
Informatie (ver)werkers vinden huidige ECM suites ook nog veel te veel denken in de ‘verpakking’ van de informatie en dat zij – de klant – juist de inhoud belangrijk vindt.
Dat is grappig als je bedenkt dat content een ander woord is voor inhoud. Het verklaart m.i. ook mede het grote faalpercentage van ECM projecten!
Dus ik werd getriggerd door de pakkende kop en je toelichting.
Als ik jouw betoog verder lees, zie ik- toch – een technische insteek, en zal de discussie met leveranciers van software altijd verzanden in de voors en tegens van web 2., SOA en al dit soort technologische varianten.
Het zal de informatie gebruiker toch uiteindelijk worst zijn in welke verpakking zijn informatie zit?
De GEBRUIKER van informatie wil dit op zijn afroep – compleet en overzichtelijk.
Een informatie gebruiker wil Content uit het Vuistje, daar ben ik het dus mee eens.
Ik geloof wel in CaaS uit het vuistje, maar dan als Content Architectuur, en niet als Content Infrastructuur, want dat is meer de focus van IT afdelingen en archivarissen!