Annons

Svensken som utvecklar en ny molnbaserad PLM-plattform: Nu har Per Johnsson världen i siktet

Begreppet ”microservices” (MSA) är alltså en nyckel i sammanhanget, men vad är det och vad betyder det? Per Johnsson förklarar att det ska ses som en programvaru- och designarkitektur, en variant av SOA (Service-Oriented Architecture), där lösningen består av flera små, lätta och individuella moduler. Realt betyder detta att en applikation delas upp i mindre delar, där varje del har en specifik funktion i applikationen. Applikationen är därmed modulär till skillnad från en monolitisk, som har all funktionalitet i en och samma modul. Dessa mindre moduler är i sin tur byggda för att vara självförsörjande, i hög grad oberoende, men ändå ihopkopplade tjänster där var och en av dem ansvarar för sina egna processer.

Vad får man ut av upplägget med ”microservices”?
En monolitisk applikation har oftast användargränssnitt, databasaccess, lätta och tunga funktioner (avkodning/beräkningar), etc i samma applikation; en applikation som bygger på ”microservices-principen” delar alltså upp de olika funktionerna i moduler där varje modul hanterar sin specifika del, t ex databasaccess eller det grafiska gränssnittet. Man brukar benämna varje modul som en egen tjänst. En modul som levererar en specifik funktion med tydligt definierade regler.
Men om man nu vill konkretisera värdet av detta – vad får man ut av mikroserviceupplägget?
– En hel del, säger Per Johnsson. I princip innebär upplägget att varje microservice kan ha sin egen livscykel och utformning. I det senare fallet för att varje ”mikrotjänst” kan välja programmeringsspråk och underliggande databas för implementera funktionen som MSA skall utföra så bra som möjligt. I vårt exempel använder vi mySQL, MongoDB, Neo4J, Casandra och ”time series-databaser” i olika tjänster, beroende på vilka funktioner de utför. I det förra fallet, när det gäller livscykeln, för att en service är frikopplad från en annan. Den har ett ”eget liv”, vilket ger att varje service kan förbättras och uppgraderas oberoende av andra services. I alla fall så länge man inte ändrar på APIn som andra services använder. Sammantaget innebär detta att varje team kan arbeta oberoende av andra för att förbättra sina funktioner och man behöver inte koordinera och testa hela systemet tillsammans. Detta gör det möjligt att släppa ny kod (funktioner) på en daglig basis istället för månadsvis, som i många andra system.

Skillnaderna mellan JWI-plattformen
och de tradtionella PLM-lösningarna
Som nämndes inledningsvis är Per Johnsson en f d PTC-medarbetare. Han blev skickad till Kina i början på 2000-talet för att hjälpa till att styra upp bolagets affärer där och är sålunda välbekant med hur konkurrensen ser ut. Han är också väl medveten om hur det han har att slåss emot ser ut, vilka kapabiliteter som finns och därmed också klar över vad det är som differentierar hans nya JWI-plattform i den tuffa konkurrensen.
– Flera saker, säger han, och pekar framför allt på att de stora aktörerna, som PTC (Windchill heter deras PLM-plattform), Dassault (3DEXPERIENCE) och Siemens Digital Industries (Teamcenter), som alla i sina kärnsystem – alltså PLM databas och funktioner – fortfarande har det som kan beskrivas som monolitiska arkitekturer. Det betyder att de är skapade som en enda applikation där alla funktioner är integrerade i koden och alla pekar mot samma databas, som är certifierad av leverantören, förklarar Johnsson och fortsätter:

– Detta betyder mycket ifråga om bristande flexibilitet vad det gäller:
1. Vilken hårdvara, vilket operativsystem och vilken databas kunder kan använda: Våra JW-plattform-användare kan välja vilken hårdvara, mjukvara, operativsystem och databas som helst, medan traditionella system har ett fåtal ”certifierade” tredjeparts leverantörer och versioner som kan användas. Vi kan konfigurera våra lösningar på molnet och sedan installera dem på vilken cloud- eller server som helst, antingen på publika molnet, privata moln, on-premise (lokalt installerat) eller till och med på ”edge” som IPC (”industrial PC”). Samma logiska system kan till och med ha vissa tjänster installerade på ett moln och andra on-premise, men det hela fungerar fortfarande ihop som ett system.
2. Hur komplext det är att anpassa och införa nya funktioner som stöder användarna:. Vårt system är baserat på ”continous development och DevOps” vilket i princip innebär att du kontinuerligt kan releasa ny kod och nya funktioner.
3. Uppgradering av programvaran: MSA (mikrotjänster) kan uppgraderas veckovis utan att man behöver starta om systemet, medan traditionella system är väldigt komplexa att uppgradera och många gånger innebär att man måste stänga ner systemet i dagar för att kunna uppgradera. För att inte tala om testning etc.
4. Prestanda och skalabilitet: Resurser (processorkraft och hårdvara) kan allokeras i realtid till olika ”tjänstepaket” baserat på hur mycket last har och hur mycket de används. I traditionella system är prestanda och förmågan att skala upp systemen inbyggt i arkitekturen och är både svårt att göra och tar lång tid att adressera.
5. Nya teknologier, som kan appliceras direkt i vårt kärnsystem: I och med att plattformen är utvecklad ursprungligen för molnet, med molnteknologi, så finns det många teknologier som är anpassade för att användas i MSA, som till exempel: Databasteknologier, AI och ”Machine Learning”, RPA (”Robotic Process Automation”), ”Event processing”, ”Edge Technology”, etc. Alla dessa är svåra eller omöjliga att applicera på traditionella monolitiska system med traditionella relationsdatabaser.

JWI-chefen tillägger att vad konkurrenterna har gjort är att lägga på ett eller flera lager ovanpå sina PLM-system (PTC – Thingworks, Navigator; Siemens – Mendix; Dassault – 3DX) för att kunna få ut data från PLM systemen och göra mer flexibla och avancerade appar ”ovanpå” på de gamla systemen. Om man tittar på differentieringarna ovan så adresserar det bara punkt nummer II ovan.

JWIs Cloud Platform är utvecklad för ingenjörs- och tillverkningsrelaterade typer av applikationer där man har funktioner (”business services”) och integrationer till typiska produktutvecklings- och tillverkningssystem för att göra det enklare skapa applikationer.

En ny release i kvartalet
Med grundstrukturen på plats och med hittills en kund i bagaget har Per Johnsson och hans medarbetare som sagt stora planer för sin lösning. Han pekar på att JWI Clod Platform är en lösning där användare kan skapa och driftsätta applikationer.
– Vår plattform är gjord för ”Engineering-” och ”Manufacturing-typ” av applikationer där vi har funktioner (”business services”) och integrationer till typiska produktutvecklings- och tillverkningssystem för att göra det enklare skapa applikationer. Baserat på denna plattform, eller arkitektur om man så vill, har vi skapat vissa standardapplikationer som ”JWI DigitalPDM, JWI DigitalMPM, DeviceMate Industrial IOT” (digital twin-lösning för tillverkning), ”Quality Cloud TQM”.

JWI-basern säger vidare att ”JWI Cloud Platform” och applikationerna redan är under försäljning i Kina sedan mitten på 2019.
– Vi gör en större uppgraderingsrelease nu i december och sen kommer vi att kontinuerligt uppgradera med en ny release en gång per kvartal. Vi planerar också att släppa applikationer för PPM (Program Portfolio Management) och ”Design Navigator” under första kvartalet 2020.

Per Johnsson (i mitten) berättade under sin keynote på FiloProcess seminariedag i Stockholm om JWI-plattformen. På bilden tillsammans med FiloProcesschefen, Bengt Sareyko (t v) och Keith Parkhouse (t h), Alfa Laval – som hade en spännande presentation kring Alfa Lavals hantering och upplägg kring produktvariation vid ”configuration-to-order-processer”.

Det första fullt ut för molnet utvecklade systemet
På Filoprocessers event hävdade Per Johnsson att man har utvecklat ”det första fullt ut ’molnnativa’ PLM-systemet”. Nu finns det finns ju de som hävdar att deras system är det första som är helt utvecklat för molnet, typ Arena PLM eller PropelPLM. Vilken skillnaden mellan ert system och andra som hävdar att de är först med molnutvecklade system?
– Först och främst vill vara tydlig med att man inte ska blanda ihop ”molnutvecklad teknologi” (”Cloud Native Technology”/Arkitektur) och ”med molnanpassad och portad/hostad teknologi” (Cloud Hosting, typ att erbjuda ett system i ett publikt moln), säger han och fortsätter:
– När vi säger ”molnutvecklat” talar vi om ”cloud native Technology”. Detta innebär att allt vi gör är: 1) MSA, microservicebaserat, 2) ”container-baserat”, vilket innebär att vi kan paketera olika tjänster (”services”) och driftsätta dem i vilken miljö som helst, 3) satt i kontinuerlig utveckling – alltså att vi kan kontinuerligt utvecklar och driftsätter kod, och 4) jobbar med DevOps, det senare ett system för att utveckla, testa, driftsätta och underhålla systemet som en kontinuerlig process.
– Vi har heller inte, som vissa andra, använt oss av infrastrukturen (IaaS) hos någon molnleverantör som Amazon, Azur, Google etc, utan har en oberoende infrastruktur, som gör att vi kan driftsätta på vilket moln som helst; eller vilket privat moln som helst; eller i en server hos kunden.

Teknologi som är född och utvecklad i molnet: Vad är potentialen och hur påverkar det dig? Så här ser Per Johnssons vy över detta ut.

Arenas och PropelPLMs PLM-modeller
Per Johnsson hävdar i detta att exempelvis Arena utvecklades långt före MSA, Container, DevOps uppfanns och är därmed baserad på en traditionell arkitektur.
– Andra liknande aktörer är, som PropelPLM, som i och för sig är utvecklat och ”hostat” på Salesforce cloud (force.com). Men varken Arena eller PropelPLM kan flyttas till ett annat moln eller kan användas ”on-premise”, lokalt installerat.
Givet att ovanstående är Per Johnssons synpunkter ska noteras att Arena är en SaaS som driftas på Arena’s egna molninfrastruktur. Det finns även en alternativ lösning för kunder inom amerikansk försvarssektor som vill ha en ITAR certified miljö och för dem erbjuds Arena PLM på AWS.gov infrastrukturen.

När det gäller de traditionella stora leverantörerna, PTC, Siemens och Dassault, menar JWI-chefen att också de ”hostar” också sina lösningar på publika moln, men med sina traditionella monolitiska system.
– Det innebär i och för sig mindre tid för installation och underhåll för kunderna, men det löser inga problem med anpassningar, uppgradering, prestanda och användning av ny teknologi, säger Johnsson avslutningsvis.

Autodesk funderar och utvecklar i samma spår som Per Johnssons JWI
Så, hur ser konkurrensläget ut för Per Johnsson? Och hur är det med sånt som ”microservices” och DevOps?
Klart är att de här bitarna är stadda i rörelse och kommer alltmer. Vi har i PLM&ERP News t ex berättat om hur svensk-kinesiska CEVT med PLM-basen Erik Gräns i spetsen använt sig av DevOps-vinkeln i sitt jobb med att skapa världsledande BOM- och konfigurationshantering inom det av Geelykoncernen ägda dotterbolaget, som tar fram grundläggande plattformar, ”bottenplattor”, för fordonsutveckling av nya modeller inom koncernen. Det hela har varit mycket framgångsrikt.

Susanna Holt, Autodesk.

Men det finns som sagt fler som tänker i i de här termerna: PLM- och CAD-utrvecklaren Autodesk är en av dom. Under det nyligen genomförda Autodesk University i Las Vegas talade sig bolagets VP och chef för Autodesks molnplattform, Forge, varm för de tre grundelementen i denna: ”microservices”, webb-APIer och DevOps. Dessa bitar är grunden i arkitekturen. Detta har stor betydelse i kontexten, Per Johnssons JWI-plattform inkluderad. Autodesk Forge är en växande plattform för molntjänster, som kan användas till en hel del, som visualisering, samverkan och automatisering av saker. Här lägger man nu kontinuerligt till nya tjänster och plattformen blir mer stabil, skalbar och pålitlig.
Konklusionen är att om Autodesk ger in i detta så har det betydelse för hur området kommer att utvecklas, inte minst i kraft av den amerikanska PLM- och CAD-utvecklarens storlek och utvecklingsresurser. Därmed innebär det att pionjärer som Per Johnsson får skjuts i sitt utvecklingsspår.
JWI är kort sagt inne på en intressant och i många stycken lovande väg och Autodesk är inget dåligt sällskap i sammanhanget.

Print Friendly, PDF & Email

Success Stories

Industriellt

Success Stories

Intressant på PLM TV News

PLM TV News

PLM TV News

PLM TV News

PLM TV News

PLM TV News

Aktuell ANALYS

Aktuell Analys

Aktuell Analys

3D-printing

Block title