Kahden ohjelman välillä siirtyvän tiedon maksimimäärä on niiden molempien ymmärtämän informaation määrä.
Ennen oli läjä paperia. Paperitötteröiden luova kaaos, joka vain paheni kopioiden halventuessa ja lisääntyessä. Papereita arkistoitiin hyllyihin, kaappeihin ja piirustuslaatikostoihin.
Sitten tulivat tiedostot – kaikenlaiset tiedostot – etenkin DWG- ja DXF-tiedostot. Tiedostoja oli etenkin alkuaikoina siellä täällä. Jokaisen koneella oli eri versioita eri piirustuksista. Lerput ja korput arkistoitiin hyllyihin, kassakaappeihin ja pöytälaatikoihin.
Pahinta tiedostoissa oli niiden epäyhteensopivuus. Yhdellä ohjelmalla luotua tiedostoa ei pystynyt toisella avaamaan. Joskus edes saman ohjelman vanhemmilla versioilla tehtyjä tiedostoja ei pystynyt avaamaan (eikä pysty aina vieläkään).
Joskus tiedonsiirto onnistui osittain. Silloin osa tiedosta siirtyi oikein, osa kenties väärin ja osa mahdollisesti ei laisinkaan. Tässä tarvittiin rinnalla paperidokumenttia, jotta voitaisiin tarkistaa mitä tietoa siirtyi ja mitä ei. Kuulostaa hankalalta – ja sitähän se oli.
Autodeskin tuotteet tukivat omaa ulkopuolisiin yhteyksiin tarkoitettua DXF-standardiaan. Käytännössä DXF oli AutoCADin sisäistä DWG:tä vastaava, mutta joskus vajavaisempi tai hiukan jäljessä laahaava tiedostomuotoa.
DXF myös muuttui uusien AutoCAD-versioiden myötä, mikä käytännössä teki muiden ohjelmien yhteensopivuuden uusimpaan AutoCADiin hankalaksi. Samalla suunnitteluohjelmien maailma kehittyi ohi 2D-piirtämisen, mikä teki DXF:stä vanhanaikaisen.
Kaikkea tätä ratkaisemaan kehitettiin IFC-standardi. IFC syntyi kansainvälisessä konsensuksessa tarpeesta synnyttää puolueeton tiedostomuoto rakennuksen tietosisällön esittämiseen.
Ensimmäiset versiot IFC:stä olivat varsin alkeellisia, mutta lupaavia. IFC-standardia kehitettiin ja kehitetään edelleen. Kansainvälinen järjestötyö on hidasta ja kallista, eivätkä kaikki ohjelmistotalot vielä seiso IFC:n takana.
Muuttuiko maailma IFC:n tulon myötä? Eipä juuri. Tilanne on jotakuinkin sama kuin DXF:n kanssa kymmenen vuotta aikaisemmin. Standardi muuttuu. Eri ohjelmat ovat eriverran ja eritavoin yhteensopivia standardin kanssa. Edelleen tiedostoja siirrellään suunnittelijalta toiselle – tosin internetin avulla nopeasti sähköpostiliitteinä tai fiksummissa organisaatioissa projektipankkien kautta.
Pahimmassa ja yleisimmässä tapauksessa suunnitelmasta on edelleen eri versioita eri suunnittelijoilla. Ainoa ero menneeseen on, että IFC on kolmiulotteinen ja sisältää tietoa rakennuksen komponenteista.
Rakennusala on yksi niistä harvoista aloista, joilla eri osapuolet ovat tietoteknisesti lähes täysin irrallaan toisistaan. Tietoa siirtyy korkeintaan sen verran kuin molempien ymmärtämää tietosisältöä on. (kuva 1)
Kahden ohjelman välillä siirtyvän tiedon maksimimäärä on niiden molempien ymmärtämän informaation määrä.
Nykyään lähes kaikki suunnitteluohjelmat tukevat ryhmätyötä, mikä usein ratkaisee ongelman organisaation sisällä, mutta harvoin organisaatioiden välillä.
Perusratkaisumalleja on kaksi. Yleisemmässä käytetään yhteisiä viitetiedostoja. Näitä viitetiedostoja linkitetään omaan piirustukseen, jolloin ne näkyvät ikään kuin osana omaa piirustusta. Malli on toimiva ja sopii suunnitteluprosesseihin, joissa työ on tällä tavoin hierarkisesti jaettavissa itsenäisiin kokonaisuuksiin. Ongelmia voivat olla viitetiedostojen päivittyminen ja toimivan tiedostohierarkian suunnittelu.
Toinen malli on ArchiCADin esittelemä tiimityö, jossa useampi suunnittelija näennäisesti käsittelee samaa tiedostoa samanaikaisesti. Suunnittelija varaa käyttöoikeuden osaan suunnitelmasta itselleen ja voi vapaasti toimia varauksensa puitteissa. Mallin vahvuus on suurempi joustavuus. ArchiCADin käytännöntoteutuksessa pullonkaulana on hitaus suurten siirreltävien tietomäärien vuoksi.
Näitä kahta mallia voi käyttää myös rinnakkain, mikä antaa jo lähes rajattoman määrän mahdollisuuksia jakaa työ mielekkäimmällä mahdollisella tavalla.
Vaikka samanaikainen suunnittelu ja vuorovaikutus tiimissä saman organisaation sisällä onnistuu, ei se kuitenkaan käytännössä suju organisaatioiden välillä. Tämä johtuu jälleen epäyhteensopivista ohjelmistoista.
Periaatteessa yhtä ohjelmistoa, esimerkiksi ArchiCADiä, käyttäen suunnittelua voitaisiin tehdä rinnakkain eri organisaatioissa. ArchiCAD on kuitenkin ensisijaisesti arkkitehdin työkalu, eikä sopivia sovelluksia esimerkiksi LVIS-suunnitteluun ainakaan vielä ole. Ja vaikka ArchiCAD-yhteensopivia sovelluksia esimerkiksi rakennesuunniteluun on, niin todennäköisesti muilla perusteilla valittu rakennesuunnittelija ei sellaista käytä.
Ongelmaa voidaan hieman kiertää tuomalla muilla ohjelmilla tehdyt suunnitelmat ArchiCADiin joko viitetiedostoina tai tiimityön avulla, joko arkkitehtitoimistossa tai toisessa organisaatiossa internetin lävitse.
ArchiCADin tiimityötä rasittaa myös hitaus, jonka vuoksi tavallinen laajakaistayhteys on suurissa projekteissa ehdottomasti liian hidas – etenkin jos malli sisältää kaikkien suunnitteluosapuolten tuottaman tiedon.
Elämä kaaoksessa jatkuu kunnes IFC tai joku muu tietomallistandardi täyttää tiedon tuottajien vaatimukset ja kaikelle tuotetulle tiedolle löytyy yksi yhteinen sijoituspaikka eli yhteinen malli.
Tälle tavoitteelle olen antanut nimen "1TnD1P" eli yksi totuus ännässä dimensiossa yhdessä paikassa. Tästä ideaalitilanteesta tulee myös M.A.D.in käyttämä mainosslogan "Yksi totuus", jota ArchiCAD itsessään toteuttaa – ainakin suurin piirtein.
Vaikka kukaan ei väitä tätä visiota vastaan – tai ehkä juuri siksi – minusta tuntuu, että organisaatiot, toimijat, ohjelmistotalot ja suunnittelijat eivät sitä ole vielä sisäistäneet. Pääsemme kaikki nopeammin tähän ideaaliin, jos me kaikki aamuisin lausumme mielessämme "1TnD1P" ja otamme pieniä askelia samaan suuntaan. (kuva 2)
Nykytilanteessa suunnitteluosapuolet elävät omissa maailmoissaan siirtävät tietoa maailmojen välillä ristiin rastiin.
Ideaalitilanteessa suunnitelijat ova jatkuvassa yhteydessä yhteiseen tietoon ja elävät samassa todellisuudessa.
Teksti on kirjoitettu alunperin kolumniksi Etelä-Korealaiseen rakennuslehteen. Sittemmin se on julkaistu ArchiMAD-lehdessä 4/2008.
Please, send any comments to Severi@mad.fi