Myten om flere plattformer

Leverandørenes løfter om fredelig sameksistens mellom plattformene er en myte. Å kjøre en applikasjon på tvers av stormaskiner, Windows, DOS, Unix, OS/2 og Mac er i praksis nesten umulig.

AV ERICA KERWIEN, INFOWORLD (US) OVERSATT AV MORTEN SOLLI

Det er ingen enkel eller rask prosess å ta i bruk og holde i drift applikasjoner for flere plattformer. Uansett hva programvareleverandørene måtte love - dette tar måneder - noen ganger år - med forberedelser, pilot-testing og implementering. Og i mange tilfeller endrer planene om å implementere applikasjoner for flere plattformer med dempede forventninger og tilmålte kompromisser.

Det er rimelig å forvente en viss mangel på stabilitet mellom applikasjoner som kjører på flere plattformer: leverandører og utviklere forsøker å gjøre mest mulig ut av en plattforms særtrekk, mens de beholder kjernefunksjonene. Når man skal kjøre en enkelt applikasjon på flere typer maskinvare og flere operativsystem-plattformer, dreier problemene seg likevel om mer enn forskjellige menystiler. Implementeringen av funksjonene er gjerne vellykket på én plattform, men svak - eller umulig - på en annen. Leverandørenes vektlegging av en markedsdominerende plattform som Windows, kan bety at produkter beregnet på andre plattformer, f.eks. Unix eller OS/2, blir forsinket i lanseringen. Et av hovedmotivene for å bruke et enkelt program i hele virksomheten, er filkompabilitet, og da er det fortsatt mange programmer som mister aktualitet.

Uavhengig av hva som er plattformens rykte og hvor ivrige tilhengere den har, er det viktig å ta hensyn til organisasjonens behov, hvilken maskinvare man har fra før og hvilke systemkunnskaper som kreves for å satse på et produkt og den plattform produktet støtter.

Produsentenes løftegap

I dag er støtte for flere plattformer ofte ikke et valg, men en nødvendighet. En systemavdeling kan gjerne drømme om å standardisere på en enkelt plattform, men i virkeligheten vil forskjellige avdelinger og brukergrupper ha systemer som ikke er standard. Sett at markedsavdelingen går inn for Mac fordi den trenger gode desktop publishing-funksjoner til produksjon av et månedlig nyhetsbrev, mens den tekniske gruppen vil ha Unix arbeidsstasjoner og enkelte andre helst bruker OS/2.

Brukerne ønsker og trenger identiske funksjoner på alle plattformer, med få eller ingen krav til opplæring, og pålitelig teknisk støtte. Systemsjefene ser etter noe som er lett å ta i bruk, finne støtte for og administrere. Og det er rimelige forventninger, tatt i betraktning alle programvareprodusentene som for tiden fallbyr løfter om støtte for flere plattformer. Men ofte er det et gap mellom løftene og virkeligheten.

Et eksempel er Groupwise fra Novell Inc. Intervoice Inc., en leverandør fra Dallas av stemmeresponssystemer, kjører OS/2, DOS, Windows og Unix internt. Selskapet besluttet å bruke Groupwise for E-post- og arbeidsgruppe-applikasjoner, delvis fordi det ble beskrevet som et produkt for flere plattformer. Etter at valget av Groupwise sluttet imidlertid Intervoices OS/2-klient å materialisere seg. Som følge av dette måtte OS/2-brukerne heretter hente fram Groupwise gjennom en DOS/Windows-rute eller i OS/2 via Windows for OS/2. Men problemene var ikke over med dette. For tiden må Intervoices Unix-brukere ha en ekstra maskin på pultene sine, en 486 som kjører DOS slik at de også får tilgang til Groupwise.

- Vi har verken tid eller ressurser nok til å oppfylle de tekniske kravene (som å konfigurere Unix-domener) for å sette opp en meldingsutveksling mellom Unix-brukerne og resten av selskapet, forteller Greg Preston, nettverksadministrator hos Intervoice. - Vi har andre branner å slukke akkurat nå.

Lotus Developments Notes groupware-produktet fanget oppmerksomheten til J.P. Morgan and Co. Inc. for flere år siden, delvis grunnet produktets støtte til flere plattformer. I dag bruker Morgan Notes i hele selskapet - rundt 16 000 ansatte med Windows, Macintosh, Unix og OS/2 som klientplattformer.

Likevel er ikke plattformene helt på likefot når det gjelder funksjoner, bemerker Eric Gottesman, som arbeider i Morgans gruppe for E-post og informasjonsutveksling. For eksempel finnes det for tiden ikke noe API for Macintoshene. Dermed kan ikke selskapet ta i bruk brukertilpassede løsninger for alle plattformene. Lotus planlegger å ha klart et Macintosh-API med Release 4 mot slutten av året.

Enda mer grunnleggende er font-støtte. Ved Morgan blir ikke fontene framstilt likt på de forskjellige plattformene, og selv på samme plattform kan en font bli vist forskjellig avhengig av brukerens monitortype (selskapet har 20-tommers skjermer på mange arbeidsstasjoner).

Morgans løsning på fontproblemet var å standardisere på fire fonter som fungerer bra på alle de fire klientplattformene. Som en løsning på vanskelighetene med forskjellige skjermer, bruker selskapet et minste felles multiplum for skjermoppløsning, 640x480 bildeelementer.

Morgan er ikke den eneste som bekymrer seg for kvaliteten på Macintosh-støtten, selv fra såkalte fler-plattforms-applikasjoner. Mange av kildene til denne artikkelen avslo å bli sitert på kritikk av sine programvare-utgiveres implementering av Macintosh-programmer. Imidlertid framgikk det at en rekke Macintosh-programmer ikke kunne matche sine Windows-fettere når det gjaldt funksjoner eller pålitelighet.

Da Microsoft slapp Word 6.0 for Macintosh etter en vellykket lansering av Word 6.0 for Windows, hevet Macintosh-brukerne røsten. Versjonen var den første demonstrasjonen på Microsofts strategi for en felles kodebase, der 70 til 80 prosent av applikasjonskoden skulle være plattform-uavhengig, og tanken bak strategien var at Microsoft skulle slippe et program for flere plattformer innen kort tid. Et flott mål, men uvisst hvilken grunn var Word 6.0 for Macintosh full av programfeil, noe som fikk mange Macintosh-brukere til å spørre seg om ikke kodebasen var optimert for Windows.

Gjør valg

Stilt overfor klager på skuffende fler-plattform-støtter, vil nok mange leverandører svare at de er presset fra en rekke hold, både når det gjelder hvor mange plattformer de skal støtte og i hvilken grad. Viktigst er det om det finnes et marked for å støtte utviklingskostnadene, men tekniske vurderinger spiller også en rolle.

- Det er et sammensatt problem å levere produkter for flere plattformer, sier Jeff Papows, visedirektør i Lotus Communications Products Group. - Du har å gjøre med distinkte forskjeller mellom operativsystemer, for eksempel når det gjelder Notes.

- Det er forskjeller mellom API-ene for de grafiske brukergrensesnittene (GUI-ene) på hver plattform, iblant betydelige forskjeller, opplyser Len Kawell, en sentral utvikler hos Iris Associates Inc., som lager Notes. - Applikasjoner flest har mer til felles hva angår fil-I/U og minnestyring (GUI), så disse utviklingsområdene er ikke fullt så intensive. Og på dypnivå har de fleste operativsystemene en del til felles med Unix.

Iris' tilnærming til forskjellene i brukergrensesnitt var å bygge et ekstra isolasjonslag, et overbygg for de andre lagene. Utviklerne skriver til dette laget, som i sin tur arbeider med alle de øvre lagene. Dette isolasjonslaget, eller abstraksjonslaget, er til hjelp når utviklerne skal håndtere områder som dialogbokser, menykartlegging og tastaturoperasjoner som er spesifikke for Notes' GUI.

- Utviklere flest bygger for et delset av GUI-et, noe som gir et svakt GUI, istedenfor et overbygg. Og særlig på noen av plattformene er det visse funksjoner som egentlig ikke eksisterer, slik at vi må simulere dem, sier Kawell.

Systemsjefer som går for en strategi for flere plattformer, må vurdere en rekke faktorer når de skal velge programvare. Først må man finne ut om et program støtter nøkkelfunksjon i alle plattformene. Et sykehus i St. Louis, Children's Hospital, valgte Groupwise for sine data- og meldingsapplikasjoner, primært fordi dette programmet støtter Sun OS server og alle andre klientplattformer på sykehuset - deriblant Windows, Motif og Unix IIe tegnbaserte terminaler - i tillegg til at programmet byr på utvidelsesmuligheter.

GUI og tekstgrensesnitt er helt avgjørende, fordi Children's Hospital er en forskningsinstitusjon, forteller Dave Schulz, en av sykehusets systemansvarlige. - Vi har svært mange terminaler, og kan ikke ignorere brukerbasen.

Et annet eksempel er det regionale telefonselskapet US West, som valgte Claris Corp.s Filemaker Pro som databasesystem på klientsiden til innsamling av kundeinformasjon i Macintosh- og Windows-formater, opplyser Eric Gustafson, ansvarlig for US West-laboratoriet Advanced Intelligent Network. Ved hjelp av Filemakers programutviklingsverktøy, kan US West tilby kundene en Macintosh- eller DOS-formatert diskett som inneholder en run-time-versjon av Filemaker Pro samt en spesiallaget US West-applikasjon.

Kundene, blant annet Pizza Hut, legger inn data på denne disketten, f.eks. om telefonnumre til forskjellige butikker og om hvilke områder i den aktuelle byen som hver butikk har ansvar for, og returnerer disketten til US West. Telefonselskapet eksporterer dataene fra Filemaker Pro som komma-delte tekstfiler, og transporterer dataene via File Transfer Protocol til sitt IBM RISC-baserte Unix-system til bruk i telefon-svitsjing. Straks dataene er på plass, kan US West rute henvendelser fra kunder til butikken som er nærmest kunden.

Selv om applikasjonen fungerer bra, bemerker Gustafson at det er enklere å støtte Macintosh-brukere: - Brukerne merker seg at Windows-versjonen har lenger reaksjonstid.

Brukere og systemansvarlige anser gjerne brukergrensesnittet som en indikator på hvor akseptabel klienten er som applikasjon for flere plattformer. Ofte er meningene delt i to leirer, når klienten skal bedømmes etter GUI-et: fra ett hold hevdes det at klienten bør samsvare med GUI-standarder som er spesifikke for plattformen, mens andre synes GUI-et bør være identisk overalt i en løsning med én programvare.

Dersom en applikasjons-GUI ikke virker på samme måte eller ser lik ut på alle plattformer, blir det et spørsmål om støtte, sier Gottesman, og fortsetter: - Alle på alle plattformer må kunne bruke grensesnittet på samme måte, ellers blir opplæringen og brukerstøtten lett et mareritt.

Uansett klientproblemer og preferanser, vil de systemansvarlige være ute etter en serverplattform som er pålitelig, gir gode administrerings- og sikkerhetsverktøy, er skalerbar og kan støtte et stort antall brukere som arbeider samtidig, uten at systemet rystes i grunnvollene.

- Vi har oppdaget at NT gir bedre ytelse og skalerbarhet og er mer pålitelig enn OS/2, sier Rick Hopfer, ansvarlig for post- og meldingsteknologi ved Bankers Trust Co., i New York. Bankers Trust migrerer nå sin Notes server fra OS/2 til Windows NT.

Ettersom Bankers Trust har 180 Notes servere som kjører på NetBIOS og IPX nettverksprotokoller, er det selvfølgelig et krav at serverplattformen kan benytte disse protokollene. Bankers Trust har planer om å migrere til Internet Protocol (IP) på servere og klienter som et ledd i en skaleringsprosess.

Bytte?

I enkelte tilfeller må en organisasjon endre applikasjoner for å få tak i en funksjon eller muliggjøre plattformstøtte.

For eksempel bruker Intervoice for tiden en Microsoft Foxpro database, men Foxpro gir ikke tilstrekkelig datasikkerhet, forteller Jim Basler, ansvarlig for systemdata for Intervoice.

Basler har til vurdering den Unix-baserte Oracle som en klient/tjener-løsning, som erstatning for Foxpro-databasen. Oracles Unix-server gir bedre sikkerhet samt bedre beskyttelse mot brudd på serveren, ved at den opprettholder «roll-back»- og «roll-forward»-logger.

Dessuten består en Oracle-applikasjon av én fil, mens en Foxpro-applikasjon er sammensatt av flere filer, slik at Foxpro-filene må beskyttes på katalog-for-katalog-basis i Novell nettverksoperativsystem.

Som resultat av dette, må Intervoice gi brukere større katalogtilgang enn Basler setter pris på, for at brukerne skal kunne produsere Foxpro-rapporter. Når Oracle kjører på Unix, kan Intervoice-brukere produsere rapporter og systemavdelingen opprettholde den nødvendige sikkerhet og data-integritet.

Når nye produkter dukker opp, er det lett for sluttbrukere og systemsjefer å bli fristet til å kjøpe dem. Men det synes å være en rådende oppfatning blant systemansvarlige at når en driftsstandard først er etablert, bør ikke organisasjonene straks finjustere konfigurasjonmatrisen til den nyeste og største plattformløsningen.

Morgan har standardisert med OS/2 som plattfrom for sin Notes-server, og er følgelig ikke spesielt ivrig etter å forandre på det nå som OS/2 Notes endelig er blitt pålitelig.

Bankers Trust standardiserer med Windows og Windows NT i den hensikt å utnytte kunnskaper og ferdigheter til fulle og holde nede omkostningene forbundet med bruk av flere teknologier. Ved å bruke både Microsoft Office og Lotus Notes, "holder vi oss med kun få leverandører og teknologier, mens vi bidrar til å gjøre leverandørene konkurransedyktige", forklarer Hopfer.

Om det er vanskelig å ta i bruk og støtte kommersielle applikasjoner i et miljø med flere plattformer, kan det å lage egne applikasjoner for flere plattformer kreve nesten-mirakler og iallfall ekstreme evner til å holde tunga rett i munnen.

- Vi holder oss unna utviklingen med flere plattformer i Groupwise-miljøet, fordi vi føler at det ennå ikke er gjort nok erfaringer med denne typen bruk, sier Schulz fra Children's Hospital i St. Louis. - Vi er heldige som har fått satt systemet igang, og dessuten vært borti utviklingssiden av miljøet.

Sykehuset vil gjerne utforske Groupwises InForms-funksjon og flytte til driftsssiden. Schulz er imidlertid nødt til å få InForms til å fungere både på Windows- Unix-plattformene. Novell tilbyr nå InForms design-miljø til bruk for Windows, og en utfyllingsklient for InForms for Windows-, Macintosh- og DOS-plattformer - men ikke Unix.

Likevel er utvikling for flere plattformer igang i enkelte organisasjoner. Ettersom Morgan støtter et bredt utvalg plattformer og utviklingsinnsatsen er spredt på forskjellige bedriftsenheter, har IT-teamet utarbeidet en fem-punkts kvalitetssikringsprosess (QA - quality assurance) som utviklere skal følge når de lager Notes-applikasjoner ment for flere plattformer, opplyser Gottesman.

Først fyller utviklergruppen ut et spørreskjema (i form av en Notes database) som er ment å klarlegge hvorvidt konseptet vil fungere som en Notes-applikasjon.

På dette stadiet skal utviklerne "kjøre applikasjonene hardt for å se om det de holder på med er noe for Notes," forteller Gottesman. Dersom konseptet deres baserer seg på funksjoner som ikke holder mål i alle målplattformene, må utviklerne gå gjennom designet og konseptet på nytt.

Deretter måler QA-personalet applikasjonen opp mot JP Morgans standarder og retningslinjer. Punkt 3 går ut på at en fra QA-personalet kjører en kontroll på stedet for å forsikre seg om at applikasjonen tjener sitt formål.

I Punkt 4 gjennomføres ytelsestester. Oppdager QA-teamet ytelsesavvik på klientplattformer, blir applikasjonen endret, og om nødvendig reduseres antallet funksjoner brukt på alle plattformene. Punkt 5 er en gjennomgåelse av applikasjonen i den sentrale Notes-gruppen.

Fremtiden

Ifølge leverandørene vil arbeidet med å støtte miljøer med flere plattformer bli enklere takket være teknologier som Opendoc, OLE og arkitekturen Common Object Request Broker. Likevel vil de fleste systemansvarlige stille seg avventende til disse mulige løsningene. Og i mellomtiden vil plattform-krigene blusse opp gjen.

Microsoft setter alt inn på å sørge for at Windows 95 kaprer Windows 3.x-brukere. Apple kjemper for å holde stillingen mens selskapet gjør klart for System 8 (kodenavn Copland). Og for IBM er trusselen at markedsmaskineriet bak Windows 95 skal stjele all oppmerksomhet rundt OS/2 Warp.

Uansett er det opplagt at behovet for støtte til flere plattformer ikke forsvinner med det første. I klient/tjener-verdenen betyr dette ikke nødvendigvis at man må tilpasse seg standarder, men man er nødt til å ta inn over seg brukernes preferanser.

Erica Kerwien er forfatter av Lotus Notes Application Development Handbook (IDG Books), og arbeider med en bok om Notes Version 4.


                    	Å velge applikasjon for flere
plattformer

Når du skal velge en applikasjon for flere plattformer, bør du ta hensyn til følgende faktorer:


                    * Tilgjengelighet. Er programvaren tilgjengelig
for alle datamaskin-plattformer i din organisasjon (både tjener- og
klientplattformer)? 

* Leverandørstøtte. Hvor god er leverandørens støtte til plattformene du har
valgt?

* Stabilitet. Er alle funksjonene som brukerne ønsker og trenger tilgjengelige
for alle plattformene i dag? Vær forsiktig med å basere beslutninger som
forutsetter funksjoner eller plattformstøtte som leverandøren gir løfter om å
innarbeide til en senere versjon, særlig dersom den bebudede funksjonen er helt
vesentlig for din bruk av applikasjonen.

* Tilgangsmulighet. Dersom programmet er avhengig av LAN/WAN-kommunikasjon, hva
kreves da for at alle datamaskin-plattformene skal få en knirkefri tilgang? Her
må man ta hensyn til den gjeldende konfigurasjonen av nettverksprotokoller. For
eksempel vil det å sette opp en Unix-server for Unix-klienter kreve mer arbeid,
teknisk ekspertise og tid enn forventet dersom ekspertisen ikke finnes på
huset.

* Standardisering. Hvor standardisert er ditt datamiljø? Vurder hvilke
plattformer du kanskje vil migrere senere.

* Støtte på huset. Besitter ditt personale den ekspertise som det aktuelle
produktet vil kreve? Hvilke ressurser vil du trenge for evt. å opparbeide eller
foredle de nødvendige kunnskapene?

* Skalerbarhet. Er programmet skalerbart? Programvare som fungerer bra hos en
enkelt klient, virker ikke nødvendigvis like godt når applikasjonen
distribuereres videre.



     Utbredte plattformer: Funksjon og egenskaper

Plattform Funksjon Egenskaper

Unix Server Sikkerhets- og kontrollfunksjoner, skalerbarhet og IP, WAN-kapasiteter

OS/2 Server Preemptiv fleroppgavekjøring, DOS- og Windows-klient, alternativer

Windows 3.x Klient 16-bits applikasjonshåndtering, grafisk DOS-basert brukergrensesnitt

Windows 95 Klient 32- bits applikasjonshåndtering, fleroppgavekjøring

Windows Server Preemptiv NT Server fleroppgavekjøring, 32-bits applikasjonshåndtering, høy ytelse

Macintosh Klient Grafisk brukergrensesnitt, bruksvennlighet, plug-and-play-kapasiteter