Integraatioprosessia voi lähestyä monesta näkökulmasta, joten aluksi on tärkeää tietää millaisia ominaisuuksia integroitavilla kokonaisuuksilla on, ja mitä rajapintoja voidaan käyttää. Mutta ennen sitä voidaan todeta jotakin yleistä niistä olosuhteista, joissa tälläisiä projekteja suoritetaan.
Käytettävissä oleva informaatio on rajallista. Nykyään käytämme niin hienostuneita työkaluja asioiden tekemiseen, ettei meidän tarvitse, emmekä usein voi täysin ymmärtää toteutusalustaa. Näin on myös Microjournalin kohdalla, vaikka kaikki Symfonyn päälle kirjoittamamme koodi onkin tunnettua, on kyse silti enemmän tai vähemmän ns. "mustan laatikon" skriptauksesta. Lähtökohtana projektissa toimii jokin kaikille osallistujille intuitiivinen idea. Tätä ideaa pyritään noudattamaan teknisellä toteutuksella. Toisaalta teknisellä toteutuksella myös jalostetaan alkuperäistä ideaa. Toimivalla prototyypillä voidaan löytää uusia mahdollisuuksia ja käyttöskenaariota alkuperäiselle idealle. Tyypillistä on myös, että käytettävät työkalut ovat rajautuneet ulkopuolisten tai sattumallisten syiden vuoksi.
Suunnitteluprosessi sai alkusysäyksensä Googlen ostettua Etherpad-palvelun. Koska Googlella oli jo omasta mielestään samoja funktioita toteuttava palvelu (Google Wave) Etherpad aiottiin yksinkertaisesti lakkauttaa ja sen ohjelmoijat siirtää kehittämään Googlen omaa palvelua. Etherpadin käyttäjäkunta ei ollut asiassa samoilla linjoilla, ja pienen hapuilun jälkeen Etherpadin lähdekoodi vapautettiin. Syntyi ajatus, että tätä vapautunutta Etherpadia pitäisi jotenkin hyödyntää Microjournal-projektissa. Tässä on huomattavaa, että idea esitettiin täysin konseptuaalisista, ei-teknisistä lähtökohdista. Idean toteuttamiseksi olisi voitu karkeasti ottaen tehdä jotakin seuraavista:
- muokata etherpadin avointa koodia uudeksi palveluksi
- pitää palvelut erillään ja kehittää ainoastaan palvelun kuvausta ja käyttäjäkokemusta
- muokata microjournalin koodia etherpad-maisiin toimintoihin
- luoda jonkinlainen yhdistelmä etherpadista ja microjournalista
Vaihtoehto 4 vaikuttaa vastaavan mataliin resursseihin Etherpadin-suhteen, sekä Etherpadin teknologian edistyneisyyteen. Nopeasti Etherpadista voitiin tietää integroinnin kannalta keskeisistä asioista seuraavaa:
- toteutettu java-ohjelmointikielellä
- paketoitu yhteen oman web-serverin kanssa
- tietokantana Mysql
Näistä havainnoista 2 ensimmäistä on projektimme kannalta negatiivisia. Microjournal on rakennettu PHP-kielellä, joten siltä suunnalta yhteensopivuutta ei löytynyt. Paketointi oman web-serverin kanssa ei kuulosta hyvältä, ja se käytännössä osoittautuikin hankalaksi asiaksi. Tietokantana Etherpad käyttää hyvin yleistä Mysql-tietokantaa, jota oli aiemmin käytetty myös Microjournalissa.
Koska tietokantaan oli resursseja(aiempaa osaamista ja tuntemusta) päätettiin sitä käyttää keskeisenä rajapintana tässä vaiheessa suunnittelua. Microjournalista voitaisiin suorittaa kyselyitä Etherpadin tietokantaan ja näin välttyä toimimasta Etherpadin koodissa. SQL-kieli on tässä tilanteessa Microjournalin ja Etherpadin yhteinen kieli, sillä datakyselyn lähetys, sekä vastaanotto onnistuvat ilman alustakohtaisia ratkaisuja.
Toiseksi rajapinnaksi otettiin visuaalinen tila, jossa Etherpad sijoitettaisiin Microjournalin käyttöliittymän "sisälle". Käytännössä tämä tapahtuisi iframe-upotuksella, sekä Etherpadin css-tiedostojen editoinnilla. Näin ei saavutettaisi täysin yhtenäistä käyttöliittymää, mutta ratkaisua puolustaa se että Etherpadilla on brändiarvoa, sekä se, että loppukäyttäjät ovat varsin tottuneita visuaalisesti erilaiseen "editointitilaan". Viimeinen kohta johtuu pitkälti siitä, että siinä missä sovelluksia harvoin toteutetaan kokonaan javascriptillä, ovat editorit lähes poikkeuksetta sitä.