Author Archives: Fredrik Jönsson

About Fredrik Jönsson

Jag arbetar som chef över IT-arkitekturgruppen på IT-avdelningen på KTH.

IT på KTH i framtiden – Att göra val

Bruno Girin, CC BY-SA 2.0, https://goo.gl/N2ru2a

Jag började arbeta med IT-system på Ericsson 1995 för att sedan komma till KTH och Systemgruppen på Numerisk analys och datalogi (Nada) 1996. Vid den tiden kunde man fortfarande som IT-avdelning med rimliga resurser upprätthålla bilden av att klara allt. Vi kunde stödja alla relevanta operativsystem och i någon utsträckning stödja så gott som alla relevanta programvaror som fanns till dem.

Så är det inte längre. Det har inte varit så ganska länge nu.

Ändå kämpar vi fortfarande med förväntningarna att kunna klara detta, klara av allt, både från oss själva och från de som använder de system vi tillhandahåller. När vi inte uppnår det känner vi oss misslyckade. Vi känner det själva på IT-avdelningen. Vi säger det inte sällan till varandra i olika sammanhang. Vi får höra det av de omkring oss som liksom många av oss har vuxit upp med IT-systemen och fortfarande tror att det är rimligt att förvänta sig det. Och det tynger många av oss.

Men det är omöjligt. Ingen kan leva upp till dessa förväntningar.

Vi vill så gärna kunna klara av alla förväntningar, både våra egna och andras, men det är inte längre möjligt.

IT-avdelningen har begränsade resurser. Kanske blir de mer begränsade framöver eftersom man av naturliga skäl vill hålla nere administrativa kostnader på KTH och frigöra resurser för huvuduppgifterna, forskning, utbildning, samverkan. Oavsett det kommer resurserna definitivt att minska I förhållande till det ständigt ökade utbudet på IT-lösningar av olika slag, precis som de har gjort under många år, oavsett vilka pengar man skulle lägga på IT.

Istället behöver vi som avdelning, KTH som universitet, hitta en annan strategi, ett annat förhållningssätt för IT.

Baserar vi yrkesstoltheten på att klara allt bäddar vi för misslyckande, både inför oss själva och andra, för ingen kan klara det längre. Istället måste vi basera yrkesstolthet på att vara bra på det vi väljer att göra, och kunna släppa annat utan att det är ett stigma.

Vi kommer att behöva välja. Mycket mer och hårdare än vi gör idag, och vi är tvungna att välja bort.

Hur väljer vi? Det är det svåra. Om IT-avdelningen slutar att säga att vi klarar allt tar vi en risk. Gör vi fel val riskerar vi att stå på fel plats om KTH i övrigt rör sig i en annan riktning. Vi oroar oss för att bli irrelevanta som IT-avdelning. Kanske till och med att man hellre köper tjänsten av någon annan. Outsourcing.

Historiskt har vi stått ensamma med valen. Som AAE:n visade har verksamhetsföreträdare varit fria att ställa olika krav utan någon samordning och IT-avdelningen hamnar i ett problematiskt läge när vi säger nej till en begäran om något system, även om vi har ett annat snarlikt när det inte faller i smaken av olika skäl. Resultatet är många parallella lösningar på liknande problem, onödiga kostnader och en låg nivå av IT-stöd för alla system vi har. Här måste KTH gemensamt snäppa upp sig, kunna tala ihop sig och kompromissa runt gemensamma lösningar.

Ur AAE:n har det kommit sådana initiativ. Vi har t.ex. styrgruppen för utbildning sedan några år, liknande gruppering är på gång inom forskningsområdet. Förhoppningsvis får vi genom dessa en bättre samordning av verksamhetskrav och stöd i att välja rätt.

Till dess får vi göra som vanligt, så gott vi kan med den kunskap och erfarenhet vi besitter, och på en mer fundamental nivå i systemen är det trots allt IT-avdelningen som sitter på expertisen och behöver ta ansvar för de val som görs. Vi behöver då få så god acceptans för dessa vi kan och vi kan bara uppnå det genom att vara öppna och tydliga med de val som görs och på vilka grunder. Både för att få acceptans, men även för dialog och återkoppling som kan förbättra våra val.

Nästa vecka kommer jag återkomma med resonemang om vilka grunder jag tror att vi behöver basera våra val på och vad det kan medföra.

Uppdatering av KTH:s datorarbetsplats

IT-avdelningen håller som bäst på att uppdatera vår största datorarbetsplats, WIKS, till den senaste versionen av Windows. I denna uppdatering ingår även mer grundläggande förändringar i hur datorarbetsplatsen är uppbyggd och fungerar i relation till kringliggande system. I ett par inlägg tänker jag utveckla bakomliggande resonemang som inte är begränsade till just WIKS utan i mångt och mycket även gäller våra Linux- och Mac OS X-system. Syftet är att vara transparent med vart vi är på väg och öppna för diskussion.

Först ut är en återpublicering av ett dokument som har funnits internt på IT-avdelningen sedan i våras och fokuserar på hur data kommer att hanteras i datorarbetsplatsen framöver. I ett senare inlägg tänker jag utveckla grundläggande värderingar för, och vilken riktning jag tror att datorarbetsplatserna kommer att röra sig framgent mer allmänt, men vill ha denna text publicerad för att alla, såväl inom som utanför IT-avdelningen, ska ha tillgång till samma bakgrund.

TL;DR, men se det som en ursäkt att sitta ner med en glögg i soffan en stund och slippa ge sig ut i mellandagsrean när själva julafton passerat.


Om lagring av data i datorarbetsplatsen

Med bakgrund av teknikutvecklingen och behov av förändring i datorarbetsplatsen har vi diskuterat hur man ska se på den och dess förhållande till datalagring av olika slag.

Bakgrund

ITA har ursprungligen förvaltat en datorplats baserad på Windows. Den utvecklades till nuvarande WIKS med inblandning av andra utanför UF och en högre grad av flexibilitet infördes. Miljön är dock fortfarande fokuserad på stationära datorer i en kontrollerad miljö, såsom datorsalar och traditionell hårt kontrollerad miljö för administrativ personal.

Även om koncept som delad admin införts för att göra miljön användbar för en vidare krets är fortfarande basdesignen den ovanstående, med roaming profiles, enträgna försök att driva data till nätverksmonterade enheter som H: m.fl. Förutom prestandaproblem orsakade av att stora mängder data flyttas vid uppstart och inloggning fungerar detta dåligt i en kraftigt mobil miljö med bärbara datorer och där man vill komma åt samma information från en mängd olika enheter, datorer, mobiltelefoner, surfplattor osv.

Exekutiv summering

  • Skilj på delade datorer som datorsalsdatorer och enskilda datorer, framför allt mobila. Återanvänd gemensamma lösningar där det är lämpligt, men tvinga inte fram dem.
  • Håll det så enkelt som möjligt.
  • Se enskilda datorer som mobila enheter – spara data och inställningar lokalt, lokala profiler. Betrakta enheten som en konsument av tjänster i förhållande till övriga system, inte som en integrerad del av hela systemet.
  • Kryptera lokal hårddisk.
  • Använd Box för filsynkronisering och säkerhetskopiering av dokument och filer.
  • Använd ett system för säkerhetskopiering, där Box inte fyller hela behovet.

Värderingar

Vara ett stöd för användaren

Traditionellt har systemadministratörer en tendens att fokusera på att hindra användare från att göra fel, oftast med goda avsikter. Det leder dock till inflexibla system med fokus på spärrar och hinder där funktioner som användare behöver för att hantera den situation de befinner sig i är avstängda för att systemadministratören inte förutsåg eller värderade behovet på samma sätt som användaren. Inse att vi inte kan förutse alla behov alla användare har, även användare som inte är avancerade, i synnerhet i en mobil miljö. Hjälp användaren att göra rätt och se till att standardinställningar är rätt. Undvik att låsa funktioner för att förhindra användare att göra fel. Hjälp användare som tappat bort sig att komma tillbaka till standardinställningar.

Hjälp användaren att göra rätt, övervaka för att kunna följa upp när de gör fel, men hindra dem inte.

Systemadministratörer har traditionellt gärna självsvåldigt roffat åt sig av användarens resurser som CPU, tid och uppmärksamhet för att göra saker med enheten som är väsentliga för systemadministratören, men inte alltid för användaren. I alla fall inte just då. Minns att det är användarens dator, ofta inköpt med användarens forskningsmedel, för att fylla användarens behov, dina kommer i andra hand. Ingen säkerhetspatch är viktigare än att användaren just då kan genomföra sin presentation.

Det är användarens dator.

Tillgång till nätverk

Användare har ofta nät, ganska ofta har de till och med bra nät. Men de har i en mobil miljö också ofta dåligt nät eller inget nät alls. Det handlar t.ex om resor, mellanlandningsplatser och stationer på resor, hotellrum, restauranger, konferenslokaler och andra publika platser osv. Men även arbete bakom brandväggar på andra arbetsplatser och forskningsmiljöer. Vi kommer inte åt detta med olika former av VPN-lösningar. Datorarbetsplatsen får inte bygga på att användaren alltid eller ens oftast har tillgång till nätverk, i synnerhet inte bra sådant.

Till exempel måste användaren närsomhelst kunna starta om sin enhet vid problem och få tillbaka den till användbart skick så fort det alls är möjligt. Det är lätt att förutse den frustration en användare i en föreläsnings- eller presentationssituation upplever om den vid ett sådant tillfälle dessutom behöver vänta på olika timeouter, hantera felmeddelanden osv.

Datorarbetsplatsen kan inte bygga på att användaren alltid eller ens oftast har tillgång till nätverk, i synnerhet inte bra sådant.

Det betyder också t.ex att autentisering och auktorisation behöver ske mot centraliserade tjänster i den mån det går, men enheten behöver ha tillräckligt med information för att kunna hantera det själv när det inte finns tillgång till nät, även efter omstarter, och den behöver kunna detektera den situationen så snabbt som möjligt i så många situationer som möjligt. Enheten behöver sedan kunna hantera att den senare blir ansluten till nät på ett sätt som fungerar så bra för användaren som möjligt och vid behov hjälpa användaren att skaffa erforderliga tokens för tjänster (t.ex Kerberos-biljetter).

Transparens

Användaren måste kunna begripa hur datorarbetsplatsen fungerar, åtminstone beträffande de delar som direkt berör dess arbete, vilket framför allt handlar om den information som hanteras på enheten, dokument, mm. Tjänstemän på myndigheten KTH har ett stort eget ansvar för att hantera information korrekt enligt rådande regelverk. Det är den enskilda tjänstemannens ansvar, inte IT-avdelningens. Det måste gå att förstå vad som händer och var data hamnar för en användare med måttliga IT-kunskaper. Därför behöver det vara rimligt enkelt. Att kopiera data hit och dit under fötterna på användaren är inte transparent eller lätt att förstå.

Det måste gå att förstå vad som händer och i synnerhet var data hamnar för en användare med måttliga IT-kunskaper.

Bli inte förförd av tekniskt komplicerade lösningar. Håll det så enkelt som möjligt, men inte enklare.

Dog fooding

Vi måste komma till en nivå där datorarbetsplatsen är användbar för IT-avdelningen själv. Förbättringar kommer av feedback från användare. De användare som är överlägset närmast kommunikationsmässigt och dessutom är avancerade användare med goda kunskaper sitter på den egna avdelningen, en del kan till och med själva åtgärda den upplevda bristen direkt själv. Om vi väljer bort den datorarbetsplats vi levererar är det svårt att övertyga andra, i synnerhet avancerade användare, att de inte ska göra det. Väljer vi själva bort datorarbetsplatsen kommer andra också att göra det – ofta av samma skäl. Det eroderar grunden som IT-avdelningens verksamhet står på. Vi måste komma dit att miljön fungerar på ett sådant sätt att vi faktiskt vill använda den själv.

Väljer vi själva bort datorarbetsplatsen kommer andra också att göra det – ofta av samma skäl.

Datorsalar och delade datorer

Delade datorer i datorsalar och i andra sammanhang och bärbara datorer skiljer sig fundamentalt i hur de används och behöver olika lösningar. Det som går att återanvända mellan de olika miljöerna ska återanvändas, men det får inte ske på bekostnad av användbarhet för slutanvändaren. För att uppnå en väl fungerande datorarbetsplats behöver vi i högre grad än tidigare skilja lösningarna åt.

I datorsalar kan datorerna förutsättas vara mer lika varandra och det är mer rimligt att inställningar mm följer med användaren mellan dem i den mån det är genomförbart. Även här behöver in- och utloggning ske så snabbt som möjligt och dataöverföringen vid inloggning begränsas. Det är mer rimligt att spara data på nätverksenheter för att transparent komma åt informationen från olika datorer. Vi vet hur många klienter som finns och kan dimensionera bakomliggande system därefter. Dock behöver informationen vara tillgänglig från andra, även privata, enheter och de tjänster som används för att dela information i datorarbetsplatsen vara tillgängliga.

Tillämpning

Lokal disk, lokala inställningar

För att skapa en transparent miljö som fungerar utan tillgång till nätverk behöver enheten vara self contained, autonom, i hög grad. Användaren behöver ha tillgång till den information den behöver på den lokala enheten. När användaren sparar inställningar och data sparas dessa på den lokala enheten.

Det introducerar risk för förlust av information och att information hamnar i orätta händer om enheten förstörs eller går förlorad som behöver hanteras. Därför behöver den lokala lagringen säkerhetskopieras för att skydda mot förlust och krypteras för att skydda mot spridning. Säkerhetskopiering kan ske via filsynkroniseringstjänster och backup-system.

Filsynkronisering och delning – Box

Den tjänst vi använder för filsynkronisering mellan enheter och för att dela filer mellan användare är Box upphandlad via Sunet. Vi har avtal och funktioner i Box för att kunna spara all information dsom inte omfattas av sekretess där. För sekretessbelagd information behöver särskild bedömning göras och särskilda åtgärder vidtas vilket inte på något sätt är unikt för Box utan gäller alla system, även interna, av IT-avdelningen tillhandahållna. För att stödja användningen av box behöver vi:

  1. se till att lämplig klientprogramvara finnas tillgänglig i datorarbetsplatsen i den mån det går.
  2. verka för att vidga användningen och ge studenter tillgång till Box.
  3. undersöka möjligheter för att integrera Box bättre i KTH:s IT-miljö, t.ex provisionering av grupper från UG och integration med andra system och enheter.
  4. långsiktigt verka för en fungerande synkronisering i datorarbetsplatsen för Linux.
  5. undersöka hur vi hanterar Box bäst i datorsalar.

Box har bristen att det inte finns en bra klient att tillgå på Linux. Vi är medvetna om det men kan inte göra så mycket åt det. Det finns nödlösningar för att synkronisera över WebDAV. Det finns API:er som kan användas för att skriva en riktig synkroniseringstjänst för Linux, men inga kända initiativ för att göra det.

Säkerhetskopiering

Säkerhetskopiering av enheter behöver prioriteras och nödvändiga ändringar eller investeringar göras för att möta de behov som finns. Den nuvarande lösningen för att hantera säkerhetskopiering av bärbara datorer är Retrospect.

Säkerhetskopiering i en miljö där nätverk inte går att lita på är alltid best effort, men vi måste veta hur läget är.

Särskilda ansträngningar:

  1. Ha övervakning av säkerhetskopieringen så att vi vet vilka enheter som inte har säkerhetskopieras.
  2. Ha ett inventarium så att vi vet vem som använder vilken enhet, för att kunna:
  3. Ta ansvar för att informera användare vars information är utsatt för förhöjd risk pga utebliven säkerhetskopiering.

Andra tjänster

Det finns många andra tjänster som används för att dela information mellan enheter. Exempel på sådana är E-post och kalender (Exchange), Github Enterprise, Confluence, Social, Canvas. Uppseglade är Office 365, Skype for business, videokonferenser och andra lösningar för att underlätta distansarbete. Datorarbetsplatsen har ett ansvar för att integrera så väl med dessa som möjligt. Det kan handla om att sätta upp och konfigurera programvara, att autentisering fungerar på ett bra sätt mot tjänsten osv.

Särskilda ansträngningar:

  1. Se över webbautentisering på KTH.
    1. Stödja SPNEGO där det är relevant i tjänster (login.kth.se) och programvara i datorarbetsplatsen.
    2. Ta fram nya alternativ som Oauth2/OpenID Connect.
    3. Åter undersöka hur läget är för tvåfaktorautentisering för vissa tjänster.
  2. Särskilt göra en ansträngning på e-postklienter för Linux visavi Exchange (t.ex Evolution).
  3. På sikt se över hur vi använder KTH.SE och UG.KTH.SE-realmerna och vilka förändringar som behöver göras där för att det ska bli så bra för användaren som möjligt.

Traditionella filservrar

Lagring på filservrar kommer även fortsättningsvis att spela en roll, framför allt för datorsalar, befintliga data och processer samt för särskilda behov (projektareor). I första hand hänvisas dock till Box och andra dedicerade tjänster som GitHub. Anta inte att man har tillgång till filservrar. Var t.ex försiktig med automatisk anslutning till filservrar i login-skript om det kan påverkar inloggningen när inte nätverket finns där eller är bristfälligt.

Använd i första hand samma filservrar som Windows-miljön i andra miljöer. Andra lösningar när det konstaterats inte fungera.

Särskilda ansträngningar:

  1. Bi-directional trust KTH.SE – UG.KTH.SE.

Using Apache Camel with Azure Service Bus

We’ve been playing around with building an integration solution using components such as Docker, Azure Service Bus and Apache Camel. Since I was unable to find any real examples of using Camel with Service Bus and there are some pitfalls, I thought I might as well publish one once we got it working properly.

The complete source code for a simple Camel route reading from a Service Bus queue is available at https://github.com/KTH/integral-reader-test. There is also a runnable Docker image, see the README.

AMQP 1.0 in Camel

There are several versions of AMQP with less in common than one might expect, but beginning with Camel 2.17, the AMQP support is lifted to 1.0. Still, due to other issues I opted to force new versions of the underlying Apache Qpid library in pom.xml.

<dependency>
  <groupId>org.apache.qpid</groupId>
  <artifactId>qpid-jms-client</artifactId>
  <version>0.11.1</version>
</dependency>
<dependency>
  <groupId>org.apache.qpid</groupId>
  <artifactId>qpid-client</artifactId>
  <version>6.0.5</version>
</dependency>

There are numerous ways to set up the broker connection, and they are changing due to interface changes which makes it confusing. The AMQP 1.0 support in Service Bus is not complete and Qpid is an independent implementation, making it difficult to know what to expect when you run into problems, and where to start digging. Eventually I landed in this configuration of the amqp Camel bean. I’ll mention some of the particulars below.

<!-- Service Bus AMQP 1.0 connection --> 
<bean id="jmsConnectionFactory" class="org.apache.qpid.jms.JmsConnectionFactory">
  <!-- amqp.traceFrames=true turns on protocol debugging -->
  <!-- amqp.idleTimeout=120000 is minimum required by Service Bus -->
  <property name="remoteURI" value="amqps://${service_bus.uri}?amqp.idleTimeout=120000" />
  <property name="username" value="${service_bus.user}" />
  <property name="password" value="${service_bus.password}" />
  <!-- 
    Makes Service Bus connection behave reasonably. In particular this means that 
    the client is not sending drain=true packets which apparently Service Bus 
    doesn't currently support. /fjo 2016-11-18 
  -->
  <property name="receiveLocalOnly" value="true" />
</bean>
<bean id="jmsCachingConnectionFactory" 
    class="org.springframework.jms.connection.CachingConnectionFactory">
  <property name="targetConnectionFactory" ref="jmsConnectionFactory" />
</bean>
<bean id="jmsConfig" class="org.apache.camel.component.jms.JmsConfiguration" >
  <property name="connectionFactory" ref="jmsCachingConnectionFactory" />
  <property name="cacheLevelName" value="CACHE_AUTO" />
</bean>
<bean id="amqp" class="org.apache.camel.component.amqp.AMQPComponent">
  <property name="configuration" ref="jmsConfig" />
</bean>

Walk-through of my issues

There where a number of caveats along the way and I’ll briefly touch on these.

ampq.IdleTimeout=120000

This is actually well-known on the internetz. Service Bus simply doesn’t support any lower values, in particular the default set by Qpid. Just set it.

recieveLocalOnly

This, however, I’ve not found described anywhere. I’ve forgotten exactly where, but somewhere along the line the Camel JMS code causes the client to send requests with the protocol option drain set to true. (Yes, the amqp.traceFrames=true URL parameter mentioned in the comments in camel-context.xml did come in handy some times).

I could try to explain what I believe this option does, but that would be pushing my understanding of the inner workings of the AMQP protocol a bit, so let me just say that this option doesn’t seem to sit well with Service Bus. Mostly, the broker will simply not answer, the client time out and close the connection. After a few retries the client will assume the broker broken and that’s that.

Then again, sometimes you actually do get some messages. And then it dies. It’s just… weird. Set the recieveLocalOnly option on the JMSConnectionFactory and the issue vanishes.

JMSXGroupID headers

The Camel component I used to create messages from our IDM solution is written by yours truly and at the time, due to the inner workings of the IDM server, it seemed like a good idea to set JMSXGroupID and related headers to group messages. It was a nice-to-have that we currently have no use for, but I was ambitious. So, not tested and maybe I’ve misunderstood exactly how these headers should behave, but the really, really strange thing was;

Azure Service Bus really did something with JMSXGroupId headers.

It’s not clear what, if it’s broken or my code is. But still. Service Bus do something rather undocumented if you use such headers. I couldn’t get the messages off the queue. I tore those headers out, and suddenly everything started working like a charm.

Locking

If I didn’t look stupid before, it will begin now. The default lock duration on a queue in the Azure portal is 30s. Which you cannot set. You are told that the value has to be in the 1-5 range. So I turned it down to 5s. Now, you can change those seconds to minutes instead, but I just assumed that the error meant that 5s was the maximum lock duration.

Not so. You can set it to 1-5 seconds or minutes, but not something like 30s. Perhaps something is not crystal clear here. Perhaps I’m just stupid.

Anyway. I’ve thus been working quite a bit with rather short lock durations (until someone pointed this out) and I thought I could share my experiences. From time to time, in a real world situation where you actually do something with the messages, I would fail to pull the message off the queue in time causing me to handle the message several times. Since I had a single consumer, I solved that using the Idempotent Consumer pattern available out of the box in Camel.

<bean id="messageRepo"
    class="org.apache.camel.processor.idempotent.MemoryIdempotentRepository"/>

...
  <route>
     <from uri="amqp:queue:..." />
     <idempotentConsumer messageIdRepositoryRef="messageRepo" eager="false">
       <!-- do stuff -->
     </idempotentConsumer>
  </route>
...

It works. You may not need it. But it works.

Ephemeral connections

This was no surprise, well documented and quite obvious. Service Bus connections aren’t forever, you have to expect that they close. Though in real life with queues using partition, this seem to happen far less than I would expect. When I turned partitioning off I saw more connection resets.

So you have to set up some sort of resend policy in the Camel error handler, but that is just out-of-the box configuration.

 <errorHandler id="retryErrorHandler" type="DefaultErrorHandler"
     xmlns="http://camel.apache.org/schema/spring">
   <redeliveryPolicy maximumRedeliveries="10"
       retryAttemptedLogLevel="WARN"
       backOffMultiplier="2"
       useExponentialBackOff="true"/>
 </errorHandler>

I’ve never seen more than one retry.

Heureka

So, having banged my head against the wall long enough to punch through to the other side, this really works. I’ve pushed in the order of 1-2 million messages through Service Bus with Camel producers and consumer in both real world and testing situations without a single failure since.

We did this in order to see if we could avoid running our own broker, such as ActiveMQ or RabbitMQ. And currently, I don’t see any need for it. There could be more not-.Net-based tools around Service Bus, but I think we’ll live with that and create those we need.

Min röst hörs nu ifrån andra sidan – driften talar

Narcissistisk bild på mig självFör de som till äventyrs läser den här bloggen när det publiceras något på den måste jag konstatera att det har varit lite uppehåll här på bloggen för min egen del. Drifts- och supportgrupperna på IT-avdelningen har organiserats om och i samband med det har mina egna arbetsuppgifter ändrats ganska radikalt, ifrån att tidigare arbeta som utvecklare och arkitekt i Infosysgruppen, till att ta över som chef för driftsverksamheten.

Det finns ett stort behov att prata brett om IT-utvecklingen på KTH även från ett driftsperspektiv, och efter lite dividerande har vi kommit fram till att jag fortsätter att pladdra på i den här bloggen istället för att starta en ny, men då utifrån ett lite annat perspektiv. I mångt och mycket rör det sig om saker som egentligen ligger ytterligare lite längre bakom www.kth.se, så helt fel kanske det inte är, men det kommer alltså att bli en ytterligare breddning av ämnet.

Omorganisation

Under en ganska lång tid har det varit diskussioner om hur man ska organisera om drifts- och supportorganisationerna på IT-avdelningen. Utan att gå in på alla turer har det resulterat i att man har delat upp det som tidigare varit ganska stora grupper med relativt lite struktur i lite mindre grupper och lagt in ett ledningslager till. I det stora hela är det för de flesta i slutänden inte alltför radikala förändringar, utan den största nyheten är ledningsstrukturen.

Den struktur som är satt i driftsgruppen är en uppdelning som i någon utsträckning är kompetens- och funktionsorienterad även om gränsdragningarna inte alltid är självklara, men i någon mån kan det ses som en stackbaserad organisation från mer grundläggande gemensamma funktioner till mer specialiserade.

Infrastruktur

Infrastrukturgruppen har hand om grundläggande funktioner som nätverk, telefoni, serverhallar, virtualiseringslösningar och några gemensamma serverfunktioner med Anders Hillbo som chef.

Servertjänster

Högre upp i stacken hittar vi servergruppen med ansvar för de flesta serverfunktioner som Active Directory, filservrar med mera, med Patrik Blomqvist som chef.

Applikationer

Har hand om vissa större administrativa system och webben med Daniela Da Silva Gradim Herlitz som chef.

Datorarbetsplatsen

Arbetar med klienterna i systemet, WIKS och programvarudistribution med mera i den miljön med Panajiotis Kokkalis som chef.

Den här strukturen har nu satt sig någotsånär efter sommaren och det är nu dags att blicka framåt på allvar. Organisatoriskt är det nu framför allt brister i strukturen för det arbete som går tvärs över kompetensområden och grupper, som mycket av vårt arbete gör, som vi behöver arbeta vidare med.

Sedan har vi, som vanligt, kolossalt mycket att göra med själva IT-miljön, och det är kanske det som jag mer kommer att ta upp mina funderingar omkring i det här forumet framöver, för att öppna upp en mer allmän diskussion om framtiden för KTH i mer IT-tekniska termer.

Vi söker användbarhetsdesigner

Lite reklam. Vi letar efter en användbarhetsdesigner till IT-avdelningen (ITA) på KTH. Vi har haft bra konsultstöd på det uppdraget en längre tid och nått insikten att det dels är ett kompetensområde vi behöver säkra och ytterligare långsiktigt utveckla med kunskap om vår verksamhet. Därför lämpar sig inte konsultformen så bra och vi vill istället rekrytera en person.

KTH söker en användbarhetsdesigner/User Experience-person

Det handlar primärt om webb av olika slag men området är brett och jag skulle nog beskriva det som en ganska utmanande kombination av cutting-edge teknik och traditioner som på sitt sätt nog kräver kreativitet utöver det vanliga.

Läs hela annonsen här: 
KTH söker en användbarhetsdesigner

Välkommen till vårt team!

This entry was posted in UX.