Architectuur voor een Content Management System

[Verwijderd]

Beste Architects,

Leuk om een forum over engineering & architecture te starten, daarom post ik maar eens een pittige architecture vraag...

Binnenkort start ik een project waarin een bestaand CMS een grote revisie moet ondergaan. Er zijn een aantal belangrijke kwaliteitsattributen die heroverwogen moeten worden, zoals maintainability, modifyability en portability. Het doel is om een assessment (ATAM) uit te voeren over de huidige architectuur en zodoende tot een nieuwe architectuur te komen die de kwaliteitseisen beter ondersteund. Uiteraard is het van belang dat de wijzigingen efficient doorgevoerd kunnen worden: met zo min mogelijk kosten een zo goed mogelijk resultaat te behalen (refactoring van code is het uitgangspunt).
Technieken die ik gebruik zijn afgeleid van Bass, Clements, Kazman en Kruchten; 4+1 views + viewpoints, explicit design decissions en quality tactics. Daarnaast moeten de nieuwe requirements geeliciteerd worden, daarvoor maak ik gebruik van technieken van Lauesen.

Momenteel ben ik me aan het verdiepen in het applicatiedomein van een CMS en daarover gaat ook mijn vraag:
- Waar vind ik architectuur beschrijvingen van CMS'en (feature beschrijvingen, views etc.) ter vergelijking?
- Daarnaast vroeg ik me af of er hier mensen zijn die met technieken hebben gewerkt van de eerder genoemde "beroemdheden" op dit gebied. Wat zijn de ervaringen?

Groetjes,

doktoranders

[Verwijderd]

Paar hits van Google:

http://www.cmssystemen.nl/
http://www.opensourcecms.com/
http://www.cmsreview.com/
http://www.cmswatch.com/

[Verwijderd]

Verwijderd schreef op zaterdag 11 maart 2006 @ 12:58:
flauwe opmerking..

Oja, als je niet snapt waar ik om vraag, reageer dan niet aub.

offtopic:
Natuurlijk heb ik op google etc gezocht en heb ik al het een en ander aan interessante info. Echter betreft het vrijwel altijd commerciele info en daar heb ik helaas niet zoveel aan (behalve dan feature beschrijvingen). Het doel van mijn vraag is eigenlijk om een soort van discussie te starten over de wijze waarop er nu met architecturen wordt omgegaan (wat leg je vast en hoe). Bij het zien van dit nieuwe forum was dit mijn verwachting. Als dat hier niet van de grond komt, no hard feelings, dan zoek ik mijn heil in de conventionele kanalen; de wetenschap.

[ Voor 60% gewijzigd door Verwijderd op 11-03-2006 13:16 ]

[Peter]

Verwijderd schreef op zaterdag 11 maart 2006 @ 13:02:
[...]


Oja, als je niet snapt waar ik om vraag, reageer dan niet aub.

De opmerking van Gangsteroo is in mijn ogen helemaal niet "flauw", juist toepasselijk. Dergelijke dingen zijn via Google te vinden, en met de links die hij je gegeven hebt zul je ongetwijfeld een stuk verder kunnen komen.

[NMe]

Titelfix. Ondanks de Engelse forumnaam mogen topictitels gewoon in het Nederlands.

[Verwijderd]

Het was helemaal niet flauw bedoeld, mijn excuses als het zo overkwam, maar je vroeg naar feature beschrijvingen enzo, die kan je op die websites wel vinden. Ook met de andere dingen waar je naar zoekt zul je met deze websites vrij ver komen. Op http://www.opensourcecms.com/ kun je ook enkele Demo's vinden waar je zelf een een ander kan uitproberen

[eamelink]

Het zou handig zijn als je eerst eens uitlegt wat je onder 'CMS' verstaat. Tegenwoordig wordt het eerste het beste scriptje waarmee je een waarde kan aanpassen al onder die noemer geschaard; waardoor het zoekgebied ook enorm groot wordt.

Wat zijn globaal de eisen die je zelf al op tafel hebt liggen?

[RedRose]

Verwijderd schreef op zaterdag 11 maart 2006 @ 12:53:
Beste Architects,

Leuk om een forum over engineering & architecture te starten, daarom post ik maar eens een pittige architecture vraag...

Binnenkort start ik een project waarin een bestaand CMS een grote revisie moet ondergaan. Er zijn een aantal belangrijke kwaliteitsattributen die heroverwogen moeten worden, zoals maintainability, modifyability en portability. Het doel is om een assessment (ATAM) uit te voeren over de huidige architectuur en zodoende tot een nieuwe architectuur te komen die de kwaliteitseisen beter ondersteund. Uiteraard is het van belang dat de wijzigingen efficient doorgevoerd kunnen worden: met zo min mogelijk kosten een zo goed mogelijk resultaat te behalen (refactoring van code is het uitgangspunt).
Technieken die ik gebruik zijn afgeleid van Bass, Clements, Kazman en Kruchten; 4+1 views + viewpoints, explicit design decissions en quality tactics. Daarnaast moeten de nieuwe requirements geeliciteerd worden, daarvoor maak ik gebruik van technieken van Lauesen.

Dat klinkt allemaal heel pompeus, maar praktisch gezien heb je (en wij ook niet) daar helemaal niks aan. Dat je al de termen kent, well great. Maar daarmee heb je in feite nog geen enkel (architectonisch) denkwerk gedaan.

Waar zet je wat in ? De belangrijkste fout die vrijwel iedereen maakt, is dat men een CMS ziet als één monolitisch geheel ziet, terwijl dat eigenlijk helemaal niet zo is. Over het algemeen gezien zijn er 1900 CMSsen in de wereld en wordt er per CMS een focus gelegd op bepaalde features binnen het CMS-gebeuren. Sommige hebben een geweldige texteditor, maar een brak datamodel of brakke 'output'-mogelijkheden, terwijl andere een repository hebben die JSR-170 compliant is, maar voor de rest niks out-of-the-box doet.

Over refactoring: je moet je afvragen of het echt nuttig is om je bestaande CMS te gaan refactoren. Als jij (en je team) genoeg tijd en geld hebben om dat te gaan _en_ je CMS heeft hele specifieke wensen, dan _zou_ je het kunnen overwegen. Over het algemeen gezien is heden ten dage refactoren duurder en duurt dat veel langer dan een bestaand, goed werkend, CMS aan te schaffen of te downloaden en daar eventueel uitbreidingen op te maken.

Bovenstaande zeg ik ook omdat je nu niet alleen moet nadenken over een nieuwe code-architectuur (wat al een hele klus is), maar ook over een eventuele nieuwe informatie-architectuur _en_ de content-flow. Het hele CMS-gebeuren is niet zozeer een software-engineering issue (er zijn al een hoop generieke proven technologies) als wel het begrijpen van de stroom van de content (informatie) en hoe je dat generiek het beste kan ontwerpen _en_ hoe je dat het beste kan gaan inzetten in je organisatie.

Dus is mijn vraag aan jou: kan je ongeveer beschrijven wat je bestaande code-architectuur is (doe maar UML ) en wat de dingen zijn die verbeterd moeten worden?

Als ik je verhaal zo lees, lijkt het erop alsof je met een hele nieuwe architectuur op de proppen wil komen. Dat in combinatie met 'refactoren' werkt natuurlijk niet. Mochten de eisen heel exotisch zijn, begin dan gewoon overnieuw. Pak anders een al bestaande content-repository en bouw daar dingen naar eigen wens omheen.

De volgende vraag is: op welk niveau werk je? Is het enterprise-class en heb je daardoor dingen als workflow, solide usermanagement etc nodig?

Momenteel ben ik me aan het verdiepen in het applicatiedomein van een CMS en daarover gaat ook mijn vraag:
- Waar vind ik architectuur beschrijvingen van CMS'en (feature beschrijvingen, views etc.) ter vergelijking?

Architectuur beschrijvingen van commerciele CMS'en zal je nergens publiek vinden, om logische redenen. Van OS-CMS'en weet ik eigenlijk niet of de architectuur te vinden zijn, maar met die CMS'en kan je natuulijk gewoon in de source kijken, als die ergens beschikbaar is.

- Daarnaast vroeg ik me af of er hier mensen zijn die met technieken hebben gewerkt van de eerder genoemde "beroemdheden" op dit gebied. Wat zijn de ervaringen?

Technieken maken niet zoveel uit. Ze helpen je denken op een 'proven' manier. Voor de rest moet je het denkwerk voor jouw situatie allemaal zelf doen.

Verwijderd schreef op zaterdag 11 maart 2006 @ 13:02:
Oja, als je niet snapt waar ik om vraag, reageer dan niet aub.

offtopic:
Natuurlijk heb ik op google etc gezocht en heb ik al het een en ander aan interessante info. Echter betreft het vrijwel altijd commerciele info en daar heb ik helaas niet zoveel aan (behalve dan feature beschrijvingen). Het doel van mijn vraag is eigenlijk om een soort van discussie te starten over de wijze waarop er nu met architecturen wordt omgegaan (wat leg je vast en hoe). Bij het zien van dit nieuwe forum was dit mijn verwachting. Als dat hier niet van de grond komt, no hard feelings, dan zoek ik mijn heil in de conventionele kanalen; de wetenschap.

Dat je een dergelijk antwoord krijgt ligt in dit geval ook zeker aan de manier waarop je een vraag stelt. Jij als wetenschapper zou als geen ander moeten weten dat je je vraag moet inkaderen en specifiekere problemen moet aankaarten, om degelijke, gerichte antwoorden te kunnen krijgen. Vandaar ook mijn tegenvraag aan jou om een bestaande architectuurschets te geven. Dan kunnen wij ergens mee werken. Voor de rest: wetenschappelijke informatie over CMS'en op het snijvlak van software engineering en informatie-architectuur / management is vrij schaars binnen de conventionele kanalen en vaak voor dit specifieke domein nauwelijks bruikbaar. Dat komt mede doordat de meesten die er goede ideeen over hebben vaak commercieel gaan en ook (denk ik) doordat het echt goed gefundeerd nadenken over content management iets vrij nieuws is.

[PowerFlower]

Aan RedRose heb ik weinig toe te voegen, behalve:

Verwijderd schreef op zaterdag 11 maart 2006 @ 12:53:
- Waar vind ik architectuur beschrijvingen van CMS'en (feature beschrijvingen, views etc.) ter vergelijking?

Die vind je op de websites van de 1800+ verschillende systemen die er zijn (tenminste, die voorkomen in de listings, er zijn er ongetwijfeld meer). Vaak is dat goed zoeken op een website trouwens, als het er al staat. De vraag is natuurlijk: wat zou je daar aan hebben? Ik vermoed dat je op zoek bent naar een soort "best practices" in CMS architectuur. Zover zijn we helaas nog lang niet. Er zijn ontzettend veel verschillende invalshoeken en aanpakken van het probleem (wat eigenlijk meer een organisatieprobleem is, dat je wil ondersteunen door een systeem).

Om maar eens een voorbeeld te geven: wat is content eigenlijk? Eens in de zoveel maanden breekt er op de verschillende CMS maillists weer een discussie over uit en meestal eindigt die met "content is wat je in een CMS stopt" en veel scherper wordt de definitie niet. Laat staan dat er algemene idëeen zijn over hoe je dat zou managen.

Natuurlijk zal dit de komende jaren verder uitkristalliseren, maar tot die tijd zul je het moeten redden met heel veel (irl) discussiëren met anderen die zich hiermee bezig houden. Hopelijk zal daar een beetje een bruikbare consensus uit gaan ontstaan

[Verwijderd]

Bedankt voor jullie reacties, ik merk dat ik iets te nonchalant ben geweest in het formuleren van mijn openingspost. Ik zag dit nieuwe forum bij toeval en heb iets te enthousiast een complexe vraag op een onduidelijke wijze gepost... mijn excuses. Hierbij enkele reacties....

Het was helemaal niet flauw bedoeld, mijn excuses als het zo overkwam, maar je vroeg naar feature beschrijvingen enzo, die kan je op die websites wel vinden.

Ok, mijn excuses, ik had niet door dat je dat voor ogen had...

Maar daarmee heb je in feite nog geen enkel (architectonisch) denkwerk gedaan.

Nee klopt, het project is ook nog niet begonnen

Waar zet je wat in ? De belangrijkste fout die vrijwel iedereen maakt, is dat men een CMS ziet als één monolitisch geheel ziet, terwijl dat eigenlijk helemaal niet zo is. Over het algemeen gezien zijn er 1900 CMSsen in de wereld en wordt er per CMS een focus gelegd op bepaalde features binnen het CMS-gebeuren. Sommige hebben een geweldige texteditor, maar een brak datamodel of brakke 'output'-mogelijkheden, terwijl andere een repository hebben die JSR-170 compliant is, maar voor de rest niks out-of-the-box doet.

dit zie ik als eisen die aan het CMS gesteld worden, aan de hand van de belangrijkste eisen zal uitgemaakt worden in hoeverre het huidige CMS voldoet. Die eisen moet ik nog boven tafel krijgen.

Dus is mijn vraag aan jou: kan je ongeveer beschrijven wat je bestaande code-architectuur is (doe maar UML ) en wat de dingen zijn die verbeterd moeten worden?

Euh, het project moet nog starten? De vragen die je stelt zijn heel goed, maar die ga ik nou juist tijdens het project proberen te beantwoorden. Ik weet nog weinig over de bestaande architectuur, dit komt aan het begin van het project aan bod.


Over refactoring: het is inderdaad nog maar te bezien of met refactoren het juiste resultaat behaald wordt. Dat is een moeilijke keuze en die hoop ik dmv het beschrijven van de architectuur met daarin de belangrijkste eisen te kunnen beantwoorden. Dit komt dus ook tijdens het project naar voren. Daarnaast is in mijn ogen refactoren beter dan opnieuw bouwen, aangezien je nu al werkende functionaliteit hebt en feitelijk onder de motorkap veranderingen gaat aanbrengen. Als je opnieuw begint bestaat de kans dat problemen die nu al zijn opgelost opnieuw optreden met alle gevolgen van dien. Wel vind ik de mogelijkheid om een COTS systeem te implementeren reeel, gezien het ruime aanbod ervan.

Waar ben ik dan naar opzoek? PowerFlower zei het eigenlijk al: een soort "Best practices"/ "architectural patterns" voor CMS architectuur, zoals workflow management, template structuur e.d. Maar ook voor kwaliteitsattributen zoals performance en scalability. Eigenlijk om een indruk te krijgen van het applicatie domein en de "algemeen bekende problemen-oplossingen". Voor maintainance bijvoorbeeld gebruik ik best practices van McConnell over code leesbaarheid, loose coupling, modularisatie etc.

Ik merk dat er inderdaad veel discussie bestaat over de "CMS inhoudelijke" onderwerpen, maar ik ben nu nog niet zover om echt inhoudelijk hierop in te gaan (zoals de vraag "wat is content eigenlijk").

Er zijn ontzettend veel verschillende invalshoeken en aanpakken van het probleem (wat eigenlijk meer een organisatieprobleem is, dat je wil ondersteunen door een systeem).

Precies, ik ben dus eigenlijk op zoek naar die discussies/info en die ben ik tot nu toe nog niet echt tegengekomen... Niet zozeer om dit 1 op 1 toe te passen, maar meer om het probleem gebied goed te overzien.

[Verwijderd]

PowerFlower schreef op zondag 12 maart 2006 @ 14:15:
CMS maillists

Misschien is dit dan weer en te simpele vraag; welke mailinglists zijn dat?

[F_J_K]

Anders dan vwb. wensen en eisen en implementaties van std CMS'en ken ik geen patterns voor CMS'en. Maar juist die inhoudelijke vragen over het soort content, of WF nodig is, etc. zijn erg belangrijk voor de gehele opzet van een CMS en dus ook voor het bouwen ervan. De structuur van een simpel 1-persoons web content mgt systeempje is heel erg anders dan die van Filenet.

PowerFlower zegt het al: denk eerst goed na over wat je organisatie nu eigenlijk nodig heeft. Ga dan pas over de functionele eisen nadenken, laat staan de specifieke inrichting middels zelfbouw. Andersom klinkt me eerlijk gezegd in de oren als het begin van een mislukt project.
Als je om een bepaalde reden perse voor zelfbouw moet/wilt gaan ipv. implementatie van een standaardapplicatie, dan nog moet je goed voor ogen hebben wat je nu precies wilt om de juiste architectuur te gebruiken

Niet dat ik als niet-devver dan kan helpen trouwens, maar moest bovenstaande even kwijt

[Steven]

Je hebt het over een ATAM procedure. Een erg goed - maar niet uitputtend! - middel om een architectuur te verifieren en verbeteren, maar het nadeel is dat je dan wel een architectuur moet hebben (en bij voorkeur de architecten).
Ik neem aan dat je geen architectuur hebt, waar je nu dus mee bezig bent is de SA Reconstructen. Zie hoofdstuk 10 van Software Architecture in Practice - 2nd edition van Bass, Clements en Kazman. Het nadeel daarvan alleen is dat je moet gaan gissen naar de Design Decisions. Volgens mij ben je op dit moment een compleet nieuw CMS aan het maken, terwijl het doel is om een ATAM procedure te doorlopen?!? Dus of je zit al in de laatste stap van ATAM, of je bent met dingen bezig waar je helemaal niet mee bezig zou moeten zijn.

[PowerFlower]

Verwijderd schreef op zondag 12 maart 2006 @ 17:58:
[...]
Misschien is dit dan weer en te simpele vraag; welke mailinglists zijn dat?

M.n. de open CMS list, de list van CM Professionals is wat beter maar dan moet je daar eerst lid van worden.

Het grote probleem met die lists is alleen dat met regelmaat dezelfde vragen weer aan de orde komen. Het wordt tijd om daar goede samenvattingen van te gaan maken voor de mensen die er wat later in vallen. Van een paar dingen kunnen de veteranen in 2 zinnen zeggen wat de definitie/oplossing is; bijv. Ann Rockley die al sinds begin jaren '80 met SGML en daarna XML bezig is, die je zo de verschillende soorten van content re-use en repurposing uit kan leggen. Maar het "grotere geheel" is iedereen nog steeds volstrekt onduidelijk en die discussies gaan on-line meestal altijd dezelfde (zinloze) kant op; het hele vakgebied zit nog op het punt dat eigenlijk alles een groot experiment is, en je bijna elke CMS implementatie bij wijze van spreken over 3 jaar weer weg kunt gooien door voortschrijdende inzichten.

Het probleem zit hem namelijk nog steeds, zelfs als je het in de goede volgorde doet:
• wat wil mijn organisatie met de website bereiken (doel)
• wie wil mijn organisatie met de website bereiken (target audiences, persona's, scenario's)
• hoe organiseren we dat (centrale/decentrale auteurs, hergebruik van content)
• hoe zorgen we er voor dat de auteurs dat begrijpen en gaan doen en blijven doen zoals de bedoeling is (dat is bijna meer een soort change management)
• hoe zorgen we er voor dat ze alles actueel houden (m.n. bij grote groepen decentrale auteurs)

Dan een hele tijd niets... en dan ga je het hebben over je content (definiëer de verschillende informatietypes die je wil gebruiken), workflow (hoe ondersteunen we de organisatie die opgezet is met de techniek) etc.

En daarna pas ga je kijken naar welke techniek/systeem/architectuur je daarvoor kunt gebruiken.

Door schade en schande wijs geworden weet ik dat elke poging om die volgorde te veranderen gedoemd is te mislukken. Been there Maar zelfs als je antwoorden weet te krijgen op bovenstaande vragen, en het goed uit weet te voeren, en daarna goed in het systeem weet te ondersteunen, is het zoals gezegd nog steeds één groot experiment. De life cycle van een CMS implementatie is daardoor nog steeds maar een paar jaar. Maar goed, dat is wel wat het spannend houdt

De enige manier om op het moment aan goede best practices, use cases etc. te komen is door veel mensen van heel verschillende organisaties te spreken over hun oplossingen, de problemen daarbij, wat ze de volgende keer anders zouden doen. Kijk dan ook niet alleen horizontaal maar ook verticaal; d.w.z., men is genijgd te denken in termen van "industry" ("wij zijn een Universiteit, hoe heeft die Hogeschool dat opgelost") terwijl in de praktijk het leidende principe is: waar hebben ze een vergelijkbaar doel met het web, en een vergelijkbare organisatiestructuur. Om een voorbeeld te geven: ik werk bij een Universiteit, maar onze implementatie blijkt uiteindelijk het meeste te lijken op die van Renault!

En ik ga wat lang door (ben dan ook echt gefascineerd door deze materie), maar ik kan het niet vaak genoeg zeggen. Content management wordt nog steeds opgestart ofwel vanuit de IT afdeling ("wat is het beste systeem qua architectuur") ofwel vanuit Marcom ("we willen klanten trekken met de website"). Beiden hebben maar zicht op een kwart van wat nodig is om dat te bereiken. Je hebt mensen nodig die over de grenzen kunnen kijken van design, architectuur, marketing/communicatie, usability, organisatiestructuur, beheer, en dan de bezoekers van de site centraal houden.

Kortom, ik ben enigszins bevreesd dat je van de verkeerde kant begint, en dat is niet vreemd (...been there) maar je bent je wel in aan het schepen op de Titanic

Om dit topic weer wat on-topic te brengen: je zou dus eigenlijk moeten vragen naar de (heel erg abstracte) architectuur voor een CMS voor een veel gespecificeerder situatie (zie bovenstaande vragen), en dáárna pas kijken naar het platform, en daarna heeft het pas zin te kijken naar "maintainability, modifyability en portability". 3 topics de komende maanden dus

Het is heel makkelijk te verzanden in de quasi-objectieve schijnzekerheden. Mid-2004 stonden wij voor precies hetzelfde probleem (hoe gaan we het bestaande CMS aanpassen aan de nieuwe eisen en beter inbedden in de organisatie?) maar gelukkig hebben we het toen omgedraaid. Waardoor de nieuwe implementatie een stuk beter in de richting zit dan wat we toen bedacht hadden

Kortom, ga eens IRL praten met mensen die in hetzelfde schuitje zitten, dan hoef je niet opnieuw het wiel uit te vinden, maar concrete oplossingen zijn er helaas ook nog niet! En als laatste dooddoener en flink chargerend: de technische infrastructuur is daarbij vrij irrelevant _{zolang je daar maar goeie mensen voor hebt}

[PowerFlower]

Bescheiden kickje: TS volledig afgeschrikt door bovenstaande, of juist druk aan het inlezen?

[Verwijderd]

nee ik ben niet afgeschrikt, bedankt voor je zeer uitgebreide respons!

Ik zal later wat uitgebreider reageren, maar ik wil alvast het volgende kwijt;
Het CMS bestaat al en wordt als ASP dienst aangeboden aan diverse klanten. Voor deze klanten worden relatief kort lopende (marketing) websites ontwikkeld, die in het CMS worden gehangen. Er is dus sprake van meerdere typen gebruikersorganisaties (niet 1 organisatie met uitgebreide publishing etc, maar gebruikers uit eigen organisatie, gebruikers uit klantorganisaties, bezoekers van de website van de klant etc.). De betreffende eigenaar wil dit CMS voorlopig blijven gebruiken en wil investeren in het CMS om de kwaliteit te verbeteren (het kan best zijn dat ik adviseer om een COTS product aan te schaffen, als blijkt dat dit beter aansluit bij de business goals).

Mede om deze redenen (het CMS bestaat al!) vind ik het geen slecht idee om vanuit het reeds bestaande platform, de bestaande code, de opgebouwde kennis en de (deels) bekende design decission + rationale naar het systeem te kijken. Daar leg ik dan de requirements naast en kijk in hoeverre de huidige implementatie aan de eisen voldoet en waar de meeste winst behaald kan worden (in een later stadium wordt hier o.a. ATAM/ALMA voor gebruikt). De architectuur bestaat dus ook al, alleen is deze niet als zodanig gedocumenteerd. Met het oog op maintenance, scalability, portability etc. denk ik met het documenteren van deze zaken al een heel eind aan de behoefte van de ontwikkelclub te voorzien; namelijk het inzichtelijk maken van beslissingen die ten grondslag liggen aan de architectuur, zodat wijzigingen en uitbreidingen beter doorgevoerd kunnen worden. Uiteraard is het van belang dat de bedrijfsdoelstellingen (wat wil men met het CMS) expliciet worden gemaakt (die deels weer voortkomen uit wensen van de klanten: de reden om een CMS te gebruiken....).

Hopelijk is duidelijk dat ik nog niet echt inhoudelijk op veel van de bovenstaande punten kan ingaan vanwege het feit dat ik nog moet starten. Maar jullie feedback is zeer welkom en hopelijk maak ik niet dezelfde fouten die al die anderen voor mij maakten (uiteraard gaat dit wel gebeuren )

[reddog33hummer]

voor de studievereging Inter-actief (Informatica utwente) is er een architectuur/ontwerp beschikbaar van een CMS systeem. Je moet een beetje door de communicatie bla bla heen lezen maar dan krijg je teminste wel een idee. http://wwwhome.cs.utwente.nl/~huismanrlr/inter-actief/

[PowerFlower]

Verwijderd schreef op dinsdag 28 maart 2006 @ 02:05:
Ik zal later wat uitgebreider reageren, maar ik wil alvast het volgende kwijt;
Het CMS bestaat al en wordt als ASP dienst aangeboden aan diverse klanten. Voor deze klanten worden relatief kort lopende (marketing) websites ontwikkeld, die in het CMS worden gehangen. Er is dus sprake van meerdere typen gebruikersorganisaties (niet 1 organisatie met uitgebreide publishing etc, maar gebruikers uit eigen organisatie, gebruikers uit klantorganisaties, bezoekers van de website van de klant etc.). De betreffende eigenaar wil dit CMS voorlopig blijven gebruiken en wil investeren in het CMS om de kwaliteit te verbeteren (het kan best zijn dat ik adviseer om een COTS product aan te schaffen, als blijkt dat dit beter aansluit bij de business goals).

Ah, een ASP dienst, dat is al een stuk duidelijker Dan nog zul je inderdaad een "grootste gemene deler" van het gebruik van het CMS moeten definiëren. En die tegen het CMS aan moeten houden. Maar vanuit die positie bezien is het niet vreemd eerst naar het bestaande CMS te kijken in ieder geval Het gaat om niet al te grote websites, vermoedt ik? Eén bepaald soort markt (ik ken bijvoorbeeld een CMS ASP die hotels bedient, en een die zich richt op architecten, dat zijn best leuke concepten want ze weten precies wat voor iets hun klanten nodig hebben)?

Maar jullie feedback is zeer welkom en hopelijk maak ik niet dezelfde fouten die al die anderen voor mij maakten (uiteraard gaat dit wel gebeuren )

Zolang je maar vertelt over de fouten die je maakt, zodat anderen er weer van kunnen leren

reddog33hummer schreef op vrijdag 31 maart 2006 @ 09:14:
voor de studievereging Inter-actief (Informatica utwente) is er een architectuur/ontwerp beschikbaar van een CMS systeem. Je moet een beetje door de communicatie bla bla heen lezen maar dan krijg je teminste wel een idee. http://wwwhome.cs.utwente.nl/~huismanrlr/inter-actief/

Ik zie alleen wat algemene schema's staan voor iemand die modules zou willen bouwen voor dat systeem Die docs zeggen me echt helemaal niets over hoe dat verder inelkaar zit, standaard architectuur plaatjes die ook op een boekhoudsysteem zouden kunnen slaan

[reddog33hummer]

PowerFlower schreef op vrijdag 31 maart 2006 @ 10:49:
Ik zie alleen wat algemene schema's staan voor iemand die modules zou willen bouwen voor dat systeem Die docs zeggen me echt helemaal niets over hoe dat verder inelkaar zit, standaard architectuur plaatjes die ook op een boekhoudsysteem zouden kunnen slaan

Architectuur != ontwerp.

Ontwerp is een bouwplan van het systeem, een architectuur is meer een conceptuele visie van hoe het systeem moet functioneren.
Die documenten zijn inderdaag geen ontwerpen. Daar is een ander document voor (zie hde mdl file maar met rational rose), dit is echt een architectuur. Dat er ook in staat hoe zo'n module gemaakt moet worden is meer om mensen te helpen.

Met andere woorden: wat bedoelt de TS met "Architectuur"

[PowerFlower]

reddog33hummer schreef op vrijdag 31 maart 2006 @ 11:14:
[...]

Architectuur != ontwerp.

Ontwerp is een bouwplan van het systeem, een architectuur is meer een conceptuele visie van hoe het systeem moet functioneren.

Ehm ja, het is me bekend wat het verschil is

Die documenten zijn inderdaag geen ontwerpen. Daar is een ander document voor (zie hde mdl file maar met rational rose), dit is echt een architectuur. Dat er ook in staat hoe zo'n module gemaakt moet worden is meer om mensen te helpen.

Hm... vind het allemaal wat te detailistische beschrijvingen van een heel specifiek CMS, er is niet echt uit te halen hoe dat inelkaar zit c.q. wat de gedachtes er achter zitten. Maar ik heb maar kort gekeken, misschien mis ik het gewoon

Met andere woorden: wat bedoelt de TS met "Architectuur"

Dat is dan wel weer een goede vraag