In part 3 of my blog series on AngularJS migration, I go into fine detail on what code changes need to happen in preparation for the migration and how the actual migration is done.

Preparing your Application for Migration

Before beginning to migrate it’s necessary to prepare and align your AngularJS application with Angular. These preparation steps are all about making the code more decoupled, more maintainable, and better aligned with modern development tools.

The AngularJS Style Guide

Ensure that the current code base follows the AngularJS style guide https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md. Angular takes the best parts of AngularJS and leaves behind the not so great parts. If you build your AngularJS application in a structured way using best practices it will include the best parts and none of the bad parts making migration much easier.
The key concepts of the style guide are:

  1. One component per file. Structuring components in this way will make them easier to find and easier to migrate one at a time.
  2. Use a ’folders by feature’ structure so that different parts of the application are in their own folders and NgModules.
  3. Use Component Directives. In Angular applications are built from components an equivalent in AngularJS are Component Directives with specific attributes set, namely:
    • restrict: ’E’. Components are usually used as elements.
    • scope: {} – an isolate scope. In Angular, components are always isolated from their surroundings, and you should do this in AngularJS too.
    • bindToController: {}. Component inputs and outputs should be bound to the controller instead of using the $scope.
    • controller and controllerAs. Components have their own controllers.
    • template or templateUrl. Components have their own templates.
  4. Use a module loader like SystemJS or Webpack to import all of the components in the application rather than writing individual imports in <script> tags. This makes managing your components easier and also allows you to bundle up the application for deployment.

Migrating to Typescript

The style guide also suggests migrating to TypeScript before moving to Angular however this can also be done as you migrate each component. Information on the recommended approach can be found at https://angular.io/guide/upgrade#migrating-to-typescript however my recommendation would be to leave any migration to Typescript until you begin to migrate the AngularJS components.

Hybrid Routers

Angular Router

Angular has a new router that replaces the one in AngularJS. Both routers can’t be used at the same time but the AngularJS router can serve Angular components while you do the migration.
In order to switch to the new built-in Angular router, you must first convert all your AngularJS components to Angular. Once this is done you can switch over to the Angular router even though the application is still hosted as an AngularJS application.
In order to bring in the Angular router, you need to create a new top-level component that has the <router-outlet></router-outlet> component in it’s template. The Angular.io upgrade guide has steps to take you through this process https://angular.io/guide/upgrade#adding-the-angular-router-and-bootstrap

Angular-UI Router

UI-Router has a hybrid version that serves both AngularJS and Angular components. While migrating to Angular this hybrid version needs to be until all components and services are migrated then the new UI-Router for Angular can be used instead.
To use the hybrid version you will first need to remove angular-ui-router (or @uirouter/angularjs)from the applications package.json and add @uirouter/angular-hybrid instead.
The next step is to add the ui.router.upgrade module to your AngularJS applications dependencies:
let ng1module = angular.module(’myApp’, [’ui.router’, ’ui.router.upgrade’]);
There are some specific bootstrapping requirements to initialise the UI Hybrid Router step by step instructions are documented in the repository’s wiki https://github.com/ui-router/angular-hybrid

Implementation

Bootstrapping a Hybrid Application

In order to run AngularJS and Angular simultaneously, you need to bootstrap both versions manually. If you have automatically bootstrapped your AngularJS application using the ng-app directive then delete all references to it in the HTML template. If you are doing this in preparation for migration then manually bootstrap the AngularJS application using the angular.bootstrap function.
When bootstrapping a hybrid application you first need to bootstrap Angular and then use the upgradeModule to bootstrap AngularJS. In order to do this, you need to create an Angular application to begin migrating to! There are a number of ways to do this, the official upgrade guide suggests using the Angular Quick Start Project however you could also use the Angular CLI. If you don’t know anything about Angular versions 2 and above now is the time to get familiar with the new framework you’ll be migrating to.
Now you should have a manually bootstrapped AngularJS version and a non-bootstrapped Angular version of your application. The next step is to install the @angular/upgrade package so you can bootstrap both versions.
Run npm install @angular/upgrade –save. Create a new root module in your Angular application called app.module.ts and import the upgrade package.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { UpgradeModule } from '@angular/upgrade/static';
@NgModule({
 imports: [
   BrowserModule,
   UpgradeModule
 ]
})
export class AppModule {
 constructor(private upgrade: UpgradeModule) { }
 ngDoBootstrap() {
   this.upgrade.bootstrap(document.body, ['angularJSapp'], { strictDi: true });
 }
}

This new app module is used to bootstrap the AngularJS application, replace ”angularJSapp” with the name of your AngularJS application.
Finally, update the Angular entry file (usually app.maint.ts) to bootstrap the app.module we’ve just created.
That’s it! You are now running a hybrid application. The next step is to begin converting your AngularJS Directives and Services to Angular versions. The Google walkthrough that these steps are based on can be found at https://angular.io/guide/upgrade#bootstrapping-hybrid-applications

Doing the Migration

Using Angular Components from AngularJS Code

If you are following the Horizontal Slicing method of migration mentioned earlier then you will need to use newly migrated Angular components in the AngularJS version of the application. The following examples are adapted from the official upgrade documentation for more detailed examples see https://angular.io/guide/upgrade#bootstrapping-hybrid-applications
AngularJS to Angular
Below is a simple Angular component:

import { Component } from '@angular/core';
@Component({
 selector: 'hero-detail',
 template: `
   <h2>Windstorm details!</h2>
   <div><label>id: </label>1</div>
 `
})
export class HeroDetailComponent { }

To use this in AngularJS you will first need to downgrade it using the downgradeComponent function in the upgrade package we imported earlier. This will create an AngularJS directive that can then be used in the AngularJS application.

import { HeroDetailComponent } from './hero-detail.component';
/* . . . */
import { downgradeComponent } from '@angular/upgrade/static';
angular.module('heroApp', [])
 .directive(
   'heroDetail',
   downgradeComponent({ component: HeroDetailComponent }) as angular.IDirectiveFactory
 );

The Angular component still needs to be added to the declarations in the AppModule. Because this component is being used from the AngularJS module and is an entry point into the Angular application, you must add it to the entryComponents for the NgModule.

import { HeroDetailComponent } from './hero-detail.component';
@NgModule({
 imports: [
   BrowserModule,
   UpgradeModule
 ],
 declarations: [
   HeroDetailComponent
 ],
 entryComponents: [
   HeroDetailComponent
 ]
})
export class AppModule {
 constructor(private upgrade: UpgradeModule) { }
 ngDoBootstrap() {
   this.upgrade.bootstrap(document.body, ['heroApp'], { strictDi: true });
 }
}

You can now use the heroDetail directive in any of the AngularJS templates.

Using AngularJS Component Directives from Angular Code

In most cases, you will need to use Angular components in the AngularJS application however the reverse is still possible.
AngularJS to Angular
If your components follow the component directive style described in the AngularJS style guide then it’s possible to upgrade simple components. Take the following basic component directive:

export const heroDetail = {
 template: `
   <h2>Windstorm details!</h2>
   <div><label>id: </label>1</div>
 `,
 controller: function() {
 }
};

This component can be upgraded by modifying it to extend the UpgradeComponent.

import { Directive, ElementRef, Injector, SimpleChanges } from '@angular/core';
import { UpgradeComponent } from '@angular/upgrade/static';
@Directive({
 selector: 'hero-detail'
})
export class HeroDetailDirective extends UpgradeComponent {
 constructor(elementRef: ElementRef, injector: Injector) {
   super('heroDetail', elementRef, injector);
 }
}

Now you have an Angular component based on your AngularJS component directive that can be used in your Angular application. To include it simply add it to the declarations array in app.module.ts.

app.module.ts
@NgModule({
 imports: [
   BrowserModule,
   UpgradeModule
 ],
 declarations: [
   HeroDetailDirective,
/* . . . */
 ]
})
export class AppModule {
 constructor(private upgrade: UpgradeModule) { }
 ngDoBootstrap() {
   this.upgrade.bootstrap(document.body, ['heroApp'], { strictDi: true });
 }
}

Migrating your component directives and services should now be relatively straightforward a detailed example of migrating the Angular Phone Catalogue example, which includes examples of transclusion, can be found at https://angular.io/guide/upgrade#bootstrapping-hybrid-applications
For the most part, if the AngularJS style guide has been followed then the change from component directives to components should simply be a syntax change as no internal logic should need to change. That said there are some services that are not available in Angular and so alternatives need to be found. Below is a list of some common issues that I’ve experienced when migrating AngularJS projects.

Removing $rootScope

Since $rootScope is not available in Angular, all references to it must be removed from the application. Below are solutions to most scenarios of $rootScope being used:

Removing $compile

Like $rootScope, $compile is not available in Angular so all references to it must be removed from the application. Below are solutions to most scenarios of $compile being used:

  • The DomSanitizer module from ’@angular/platform-browser’ can be used to replace $compileProvider.aHrefSanitizationWhitelist
  • $compileProvider.preAssignBindingsEnabled(true) this function is now deprecated. Components requiring bindings to be available in the constructor should be rewritten to only require bindings to be available in $onInit()
  • Replace the need for $compile(element)($scope); by utilising the Dynamic Component Loader https://angular.io/guide/dynamic-component-loader.
  • Components will need to be re written to remove $element.replaceWith().

Conclusion

In this 3 part blog, we’ve covered the reasons for migrating, the current AngularJS landscape, migration tips and resources, methods for migration, preparing for a migration, different ways of using migrated components and common architectural changes.
The goal of this blog series was to give a comprehensive guide to anyone considering migrating from AngularJS to Angular based on my experience. Hopefully, we’ve achieved this and if your problems haven’t been addressed directly in the blog the links have pointed you in the right direction. If you have any questions please post them in the comments.
AngularJS migration is not an easy task but it’s not impossible! Good preparation and planning are key and hopefully, this blog series will help you on your way.

Sources

You can read part 1 of this series here: https://gofore.com/en/migrating-from-angularjs-part-1/
And you can read part 2 here: https://gofore.com/en/migrating-from-angularjs-part-2/

Rhys Jevons

Rhys Jevons

Rhys is a Senior Software Architect with over 10 years of experience in Digital Transformation Projects in the Media, Transport and Industrial sectors. Rhys has a passion for software development and user experience and enjoys taking on complicated real-world problems.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

In part 3 of my blog series on AngularJS migration, I go into fine detail on what code changes need to happen in preparation for the migration and how the actual migration is done.

Preparing your Application for Migration

Before beginning to migrate it’s necessary to prepare and align your AngularJS application with Angular. These preparation steps are all about making the code more decoupled, more maintainable, and better aligned with modern development tools.

The AngularJS Style Guide

Ensure that the current code base follows the AngularJS style guide https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md. Angular takes the best parts of AngularJS and leaves behind the not so great parts. If you build your AngularJS application in a structured way using best practices it will include the best parts and none of the bad parts making migration much easier.
The key concepts of the style guide are:

  1. One component per file. Structuring components in this way will make them easier to find and easier to migrate one at a time.
  2. Use a ’folders by feature’ structure so that different parts of the application are in their own folders and NgModules.
  3. Use Component Directives. In Angular applications are built from components an equivalent in AngularJS are Component Directives with specific attributes set, namely:
    • restrict: ’E’. Components are usually used as elements.
    • scope: {} – an isolate scope. In Angular, components are always isolated from their surroundings, and you should do this in AngularJS too.
    • bindToController: {}. Component inputs and outputs should be bound to the controller instead of using the $scope.
    • controller and controllerAs. Components have their own controllers.
    • template or templateUrl. Components have their own templates.
  4. Use a module loader like SystemJS or Webpack to import all of the components in the application rather than writing individual imports in <script> tags. This makes managing your components easier and also allows you to bundle up the application for deployment.

Migrating to Typescript

The style guide also suggests migrating to TypeScript before moving to Angular however this can also be done as you migrate each component. Information on the recommended approach can be found at https://angular.io/guide/upgrade#migrating-to-typescript however my recommendation would be to leave any migration to Typescript until you begin to migrate the AngularJS components.

Hybrid Routers

Angular Router

Angular has a new router that replaces the one in AngularJS. Both routers can’t be used at the same time but the AngularJS router can serve Angular components while you do the migration.
In order to switch to the new built-in Angular router, you must first convert all your AngularJS components to Angular. Once this is done you can switch over to the Angular router even though the application is still hosted as an AngularJS application.
In order to bring in the Angular router, you need to create a new top-level component that has the <router-outlet></router-outlet> component in it’s template. The Angular.io upgrade guide has steps to take you through this process https://angular.io/guide/upgrade#adding-the-angular-router-and-bootstrap

Angular-UI Router

UI-Router has a hybrid version that serves both AngularJS and Angular components. While migrating to Angular this hybrid version needs to be until all components and services are migrated then the new UI-Router for Angular can be used instead.
To use the hybrid version you will first need to remove angular-ui-router (or @uirouter/angularjs)from the applications package.json and add @uirouter/angular-hybrid instead.
The next step is to add the ui.router.upgrade module to your AngularJS applications dependencies:
let ng1module = angular.module(’myApp’, [’ui.router’, ’ui.router.upgrade’]);
There are some specific bootstrapping requirements to initialise the UI Hybrid Router step by step instructions are documented in the repository’s wiki https://github.com/ui-router/angular-hybrid

Implementation

Bootstrapping a Hybrid Application

In order to run AngularJS and Angular simultaneously, you need to bootstrap both versions manually. If you have automatically bootstrapped your AngularJS application using the ng-app directive then delete all references to it in the HTML template. If you are doing this in preparation for migration then manually bootstrap the AngularJS application using the angular.bootstrap function.
When bootstrapping a hybrid application you first need to bootstrap Angular and then use the upgradeModule to bootstrap AngularJS. In order to do this, you need to create an Angular application to begin migrating to! There are a number of ways to do this, the official upgrade guide suggests using the Angular Quick Start Project however you could also use the Angular CLI. If you don’t know anything about Angular versions 2 and above now is the time to get familiar with the new framework you’ll be migrating to.
Now you should have a manually bootstrapped AngularJS version and a non-bootstrapped Angular version of your application. The next step is to install the @angular/upgrade package so you can bootstrap both versions.
Run npm install @angular/upgrade –save. Create a new root module in your Angular application called app.module.ts and import the upgrade package.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { UpgradeModule } from '@angular/upgrade/static';
@NgModule({
 imports: [
   BrowserModule,
   UpgradeModule
 ]
})
export class AppModule {
 constructor(private upgrade: UpgradeModule) { }
 ngDoBootstrap() {
   this.upgrade.bootstrap(document.body, ['angularJSapp'], { strictDi: true });
 }
}

This new app module is used to bootstrap the AngularJS application, replace ”angularJSapp” with the name of your AngularJS application.
Finally, update the Angular entry file (usually app.maint.ts) to bootstrap the app.module we’ve just created.
That’s it! You are now running a hybrid application. The next step is to begin converting your AngularJS Directives and Services to Angular versions. The Google walkthrough that these steps are based on can be found at https://angular.io/guide/upgrade#bootstrapping-hybrid-applications

Doing the Migration

Using Angular Components from AngularJS Code

If you are following the Horizontal Slicing method of migration mentioned earlier then you will need to use newly migrated Angular components in the AngularJS version of the application. The following examples are adapted from the official upgrade documentation for more detailed examples see https://angular.io/guide/upgrade#bootstrapping-hybrid-applications
AngularJS to Angular
Below is a simple Angular component:

import { Component } from '@angular/core';
@Component({
 selector: 'hero-detail',
 template: `
   <h2>Windstorm details!</h2>
   <div><label>id: </label>1</div>
 `
})
export class HeroDetailComponent { }

To use this in AngularJS you will first need to downgrade it using the downgradeComponent function in the upgrade package we imported earlier. This will create an AngularJS directive that can then be used in the AngularJS application.

import { HeroDetailComponent } from './hero-detail.component';
/* . . . */
import { downgradeComponent } from '@angular/upgrade/static';
angular.module('heroApp', [])
 .directive(
   'heroDetail',
   downgradeComponent({ component: HeroDetailComponent }) as angular.IDirectiveFactory
 );

The Angular component still needs to be added to the declarations in the AppModule. Because this component is being used from the AngularJS module and is an entry point into the Angular application, you must add it to the entryComponents for the NgModule.

import { HeroDetailComponent } from './hero-detail.component';
@NgModule({
 imports: [
   BrowserModule,
   UpgradeModule
 ],
 declarations: [
   HeroDetailComponent
 ],
 entryComponents: [
   HeroDetailComponent
 ]
})
export class AppModule {
 constructor(private upgrade: UpgradeModule) { }
 ngDoBootstrap() {
   this.upgrade.bootstrap(document.body, ['heroApp'], { strictDi: true });
 }
}

You can now use the heroDetail directive in any of the AngularJS templates.

Using AngularJS Component Directives from Angular Code

In most cases, you will need to use Angular components in the AngularJS application however the reverse is still possible.
AngularJS to Angular
If your components follow the component directive style described in the AngularJS style guide then it’s possible to upgrade simple components. Take the following basic component directive:

export const heroDetail = {
 template: `
   <h2>Windstorm details!</h2>
   <div><label>id: </label>1</div>
 `,
 controller: function() {
 }
};

This component can be upgraded by modifying it to extend the UpgradeComponent.

import { Directive, ElementRef, Injector, SimpleChanges } from '@angular/core';
import { UpgradeComponent } from '@angular/upgrade/static';
@Directive({
 selector: 'hero-detail'
})
export class HeroDetailDirective extends UpgradeComponent {
 constructor(elementRef: ElementRef, injector: Injector) {
   super('heroDetail', elementRef, injector);
 }
}

Now you have an Angular component based on your AngularJS component directive that can be used in your Angular application. To include it simply add it to the declarations array in app.module.ts.

app.module.ts
@NgModule({
 imports: [
   BrowserModule,
   UpgradeModule
 ],
 declarations: [
   HeroDetailDirective,
/* . . . */
 ]
})
export class AppModule {
 constructor(private upgrade: UpgradeModule) { }
 ngDoBootstrap() {
   this.upgrade.bootstrap(document.body, ['heroApp'], { strictDi: true });
 }
}

Migrating your component directives and services should now be relatively straightforward a detailed example of migrating the Angular Phone Catalogue example, which includes examples of transclusion, can be found at https://angular.io/guide/upgrade#bootstrapping-hybrid-applications
For the most part, if the AngularJS style guide has been followed then the change from component directives to components should simply be a syntax change as no internal logic should need to change. That said there are some services that are not available in Angular and so alternatives need to be found. Below is a list of some common issues that I’ve experienced when migrating AngularJS projects.

Removing $rootScope

Since $rootScope is not available in Angular, all references to it must be removed from the application. Below are solutions to most scenarios of $rootScope being used:

Removing $compile

Like $rootScope, $compile is not available in Angular so all references to it must be removed from the application. Below are solutions to most scenarios of $compile being used:

  • The DomSanitizer module from ’@angular/platform-browser’ can be used to replace $compileProvider.aHrefSanitizationWhitelist
  • $compileProvider.preAssignBindingsEnabled(true) this function is now deprecated. Components requiring bindings to be available in the constructor should be rewritten to only require bindings to be available in $onInit()
  • Replace the need for $compile(element)($scope); by utilising the Dynamic Component Loader https://angular.io/guide/dynamic-component-loader.
  • Components will need to be re written to remove $element.replaceWith().

Conclusion

In this 3 part blog, we’ve covered the reasons for migrating, the current AngularJS landscape, migration tips and resources, methods for migration, preparing for a migration, different ways of using migrated components and common architectural changes.
The goal of this blog series was to give a comprehensive guide to anyone considering migrating from AngularJS to Angular based on my experience. Hopefully, we’ve achieved this and if your problems haven’t been addressed directly in the blog the links have pointed you in the right direction. If you have any questions please post them in the comments.
AngularJS migration is not an easy task but it’s not impossible! Good preparation and planning are key and hopefully, this blog series will help you on your way.

Sources

 
You can read part 1 of this series here: https://gofore.com/en/migrating-from-angularjs-part-1/
And you can read part 2 here: https://gofore.com/en/migrating-from-angularjs-part-2/

Rhys Jevons

Rhys Jevons

Rhys is a Senior Software Architect with over 10 years of experience in Digital Transformation Projects in the Media, Transport and Industrial sectors. Rhys has a passion for software development and user experience and enjoys taking on complicated real-world problems.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Vauhdikkaasti kehittyvä teknologia vaikuttaa organisaatioiden ydintoimintaan ja työn arkeen. Muutosten keskellä aidosti työntekijälähtöinen kehittäminen on vaativaa. Samaan aikaan kun on pystyttävä tuottamaan myös erinomaista asiakaskokemusta.

Organisaatiomuotoilu on oivallinen keino kokonaisvaltaisen muutosjohtajuuden tukemiseen. Se auttaa luomaan organisaation ja sen sidosryhmien välille rakenteita ja prosesseja, toimintamalleja, prosessikuvauksia tai järjestelmäkonsepteja, jotka tukevat yhteistyötä ja yhteistä kehittämistä.
Se tekee näkyväksi myös niin sanotun perhosvaikutuksen (butterfly effect), eli sen, että jokainen muutos organisaatiossa vaikuttaa toimintaan alueilla, jotka eivät ensin näytä kovinkaan ilmeisiltä. Hennolta perhosen siiven iskulta vaikuttava muutos yhtäällä voi aiheuttaa myrskyn toisaalla, jos muutoksen yhteisvaikutuksia ei tunnisteta.

”Muutos lähtee aina sisältä päin, mutta sitä
ei pidä tehdä tuntematta ulkopuolisia asioita.”

­Organisaatiomuotoilu auttaa tunnistamaan organisaation toimintaan ja sen kulttuuriin vaikuttavia tarpeita ja mahdollisuuksia. Tämä tapahtuu sisäisiä ja ulkoisia sidosryhmiä osallistamalla. Alla muutama esimerkki kysymyksistä, joihin organisaatiomuotoilussa etsitään vastauksia:

Sisäinen näkökulma Ulkoinen näkökulma
·       Mitä toimintoja voidaan toteuttaa tulevaisuudessa teknologiaa hyödyntämällä?
·       Mitkä asiat ovat sellaisia, joihin teknologian myötä vapautuvia inhimillisiä voimavaroja on toivottavaa ja järkevää käyttää?
·       Miten ihmiset toivovat työnsä muuttuvan, jotta he voivat paremmin vastata asiakkaiden tarpeisiin?
 
·       Mitkä asiat ovat asiakkaille tärkeitä ja miten hyvin tarpeisiin vastataan tällä hetkellä?
·       Millaisia odotuksia, toiveita, iloja ja suruja asiakkailla on?
·       Miten asiakkaat toivovat organisaation vastaavan heidän odotuksiinsa ja tarpeisiinsa?
 

Organisaatiomuotoilu yhdistää välillä ensi silmäykseltä täysin yhteen sopimattomilta tuntuvia palasia. Se on varsin taloudellinen tapa kehittää organisaation rakenteita, prosesseja ja toimintamalleja suuntaan, joka tukee sen muutosta kokonaisvaltaisesti – siihen asiakaslähtöiseen suuntaan.
Tukea asiakaskokemuksen skaalaamiseen
Tyypillisesti uusien toimintamallien tavoitteena on palvella asiakkaita entistä paremmin ja tehokkaammin. Samalla halutaan tukea positiivisen asiakaskokemuksen kehittymistä ja mahdollistaa asiakkaiden odotusten ylittäminen.
Asiakaskokemuksesta tekee mielenkiintoisen kehittämiskohteen sen henkilökohtaisuus. Kysehän on ennen kaikkea tunteesta tai käsityksestä, joka asiakkaalle muodostuu, kun hän on vuorovaikutuksessa organisaation edustajien kanssa tai käyttää sen tuotteita ja palveluita.
Voiko henkilökohtaista ja tilannesidonnaista kokemusta skaalata? Minusta voidaan, jos asiakaskokemuksen skaalaaminen nähdään digitaalisen ratkaisun tai palvelun tuottamana, suhteellisen muuttumattomana kokemuksena palvelun tai sen osan laajentumisesta huolimatta.
Tätä toteutetaankin jo esimerkiksi tekoälybottien avulla. Oppiva botti kerryttää asiakasymmärrystä jokaisessa kohtaamisessa kehittäen itse itseään – ja tarjoten tietoa myös muiden palveluiden kehittämisen tueksi.
Tähän pyritään nähdäkseni kansallisella tasolla myös 2015 alkaneessa Suomen hallituksen digitalisaatio-ohjelmassa, joka on tuonut yksityisen ja julkisen sektorin toimijat samalle ekosysteemialustalle, jotta hallintokeskeiset toimintatavat voidaan muuttaa yhdessä asiakaslähtöisemmiksi. Ketterien pilottien avulla yhtenäistetään palvelukokemus myös asiakkaiden yksilölliset tarpeet huomioiden.
Organisaatiomuotoilussa maalataan strategiatasolla isolla pensselillä – mutta yksityiskohdat ratkaisevat. Tunnistamalla vahvuudet, heikkoudet ja riskit sekä luomalla asiakaslähtöisyyden mahdollistavia yhteisiä toimintamalleja, on mahdollista hallita perhosvaikutusta ja tarvittaessa jopa muuttaa negatiivinen asiakaskokemus takaisin positiiviseksi.
 
Uskotko sinä muutokseen? Siihen, että voit muuttaa maailmaa paremmaksi ihmisille ja ympäristölle?
Tutustu uuteen julkaisuumme ja asiantuntijoidemme näkemyksiin: Recoding change

Soile Roth

Soile Roth

Soile toimii Goforella muotoilupalveluista vastaavana johtavana konsulttina. Lisäksi hän työskentelee strategisena muotoilijana ja organisaatiomuotoilijana. Soilella on vankka tausta asiakaskokemuksen parantamisesta niin kotimaisissa kuin kansainvälisissäkin yrityksissä, kuten esimerkiksi OP:ssa, opetus- ja kulttuuriministeriössä, Helsingin kaupungissa ja Kelassa. Hän on myös sertifioitu business coach ja tekee parhaillaan väitöskirjaa johtamisen kehittämisestä.

Linkedin profileTwitter profile

Piditkö lukemastasi? Jaa se myös muille.

https://www.flickr.com/photos/ruben3d/8163748252/in/photolist-drpkWd-TumZbA-e5uuoi-xRMYpC-7dpqNU-89Mu7e-7veBL4-TumZad-5VSyfF-5efXv1-eRPVeZ-o8vG8S-b91EHa-oyGwvq-96MX7W-eg7afu-58knb-7fnkYL-6aMTQu-HvGBX-aBEgU4-9XdCMb-a1s6VU-aBEdBZ-aBEmVr-8uCWv8-7CKXn2-22uB61J-dzfcpn-7k2eST-rjpLGP-rNtfx3-6bNNow-4uNb24-2b3U5fV-bAApCy-28PfWFe-6b6ALx-ZgUW1-3f5Jvf-7toT6X-StCdPK-SBjg9h-9sE4qK-buYvFJ-ixCysV-RqZRy2-RqZNtK-Ugxewr-U4ScNXThis is a large topic and so needs a large introduction.
Essentially, I’m trying to explore what, as designers, we can do to save the planet. We should all know the consequences of climate change by now but to remind you, here are a few headlines from this year:

Pretty grim for sure, and I wish this was the media exaggerating as usual. Unfortunately, there is no sugar coating these facts. I have experienced the changes in the ocean and coral first hand. I have been to places twice over two years, only to find that every piece of coral has bleached and fish disappeared. There are very important yet simple steps that anyone can take to have a positive impact on the environment. Some of these are:

  1. Don’t buy things unless you need them. More on minimalism here.
  2. Cut out meat from your diet, or at least reduce it. This is probably the biggest one. Take a look.
  3. Cycle instead of driving a car.
  4. Go for a smaller living space. Some are even considering The Tiny House Movement.

The list can go on forever, but I advise you to go through a more serious list on the WWF website. (hint: it requires contacting political decision-makers to make larger green decisions.)

The next question is:
What can I do as a designer to prevent, or at least slow down climate change?

There are at least 4 things we can start with.

1. The internet

“While we might not be able to stop using the web, we can change how we build and power it, to make it planet friendly as well as user-friendly.” –Planet Friendly Web Guide

The web is the largest machine ever built in the history of mankind with 4.5 Billion users. The scary part is that it’s less than 50 years old. It’s complex, with many moving components. Simply put, however, more data requires more energy. In fact, in 2019, it will emit around 1 billion tons of CO2, that is more than the entire aviation industry.
The internet does pollute, nevertheless, the whole industry as a whole is conscious and is willing to move into a more positive direction. Yet again, start locally, see if you or your client are using green hosting and have optimised your website to be eco-friendly on EcoGrader.
Usually, cloud solutions are more sustainable than traditional data centres. Keep in mind, not all clouds are vaped-out equal. Google, for example, committed to being 100 per cent renewable-powered. Amazon, on the other hand, has only started to take its first steps in the right direction. Click-Green can give you a good insight into your favourite brands and their greenness.
Since we covered most facts and theories about internet pollution, let’s take initiative by taking a deeper dive into Planet Friendly Web. A great open source knowledge library, equipping you with the knowledge you need to make conscious and informed future decisions.

2. Start small, Start in the office.

Digital design is surprisingly taxing on the environment. Sharpies, post-its, laptops, phones, Ipads, pens and lots of coffee. Luckily, we can offset many of those quite easily. I found this simple spreadsheet to calculate your CO2 emissions.
The largest savings can be made on travel, which unfortunately isn’t as easy as cutting back on paper. Clients still need to be met, and users have to be interviewed. Fortunately, most progressive companies are open to remote work. Tools are developing at a rapid pace that makes collaborative design, research and interviewing remotely almost seamless. At Gofore, we use tools such as InVision, Axure and Abstract to allow for remote and asynchronously reviews and version control.
Finally, I have been conducting experiments holding large workshops using tools such as Mural and Mira. They are not flawless, but great, considering that they are in their infancy stages. You are a UX designer with an analytical mind, so you look at the numbers and see that every action you save on doesn’t actually make a difference. Let’s have a look at a global scale. According to LinkedIn, there are about one million UX designers worldwide, that is excluding service, UI, visual and graphic designer. With ease we can save about 3 million tons of CO2, that is more than closing entire coal-fired power-station. Designers are smart and creative, and our power should definitely not be underestimated. Every small action counts. Saving on paper, less travel and black coffee instead of a latte makes a big difference.

3. Greenify your products

Let’s pay attention to where our products meet the users. We as designers are partly responsible for that. The great news is that most of the users are concerned about the environment and are willing to make a positive change. Although, their motivation gets trumped by daily life, old habits and convenience. What we can do as designers is give means and motivation to pull(not push) their actions into positives ones towards the environments. We can ask some questions to determine if we are on the right track:

  • Is this helping or harming the environment? (a simple question that might require extensive research)
  • What are we making?
  • If what we are making has no sustainable alternative, how can we create the greenest experience with what we have?

Sometimes, solutions are easy and straightforward. When things are physical such as shipping and delivery, we can promote greener delivery options. Holiday booking apps/sites can offer means to offset the users’ carbon footprint etc. Most of what we design on the other hand is intangible and that makes it sustainable design thinking harder. Luckily with a designer’s brain, nothing is impossible
Asking users to go green is tricky. By asking users to go green, you are most likely asking them to sacrifice time, convenience or money. Design With Intent gives a good set of persuasion methods, I don’t agree with all of them as some contain dark patterns. If deemed effective however in actually saving our planet, I would explore “green patterns”. For example, choosing the more environmentally option by default for the user.

4. Size does matter, the smaller the better.

We are seeing banners growing larger, hero images taking the entire screens, video for visual appeal with no other function and more. This is harmful in some ways, starting from the digital divide. We are designing products to be used worldwide. Part of our design duty is to care about the user experience (people) worldwide, users in Bangalore with 0.5mb/s internet speed should have the same experience as the people in Helsinki. As from the planet’s point of view, more data means more fossil fuels. Websites are only increasing in size. From 500kb in 2011 to 4000kb in 2019. The majority of this lies with us, the designers. Modern sites and applications use web fonts, multiple JS libraries, high-resolution images, and videos, maybe adding a better visual experience, but definitely a more data-intensive and thus harmful experience for the planet.
Let’s not rely on internet speeds getting higher and work on making our products more lightweight. Also, research has shown that a faster user experience correlates with better conversions and higher user satisfaction. Take a look at the winners of the 10k Apart competition. They have achieved interactive and excellent designs whilst using 1/300th of the data of an average page.
Great tools for optimising your designs are, PageSpeedKraken.io and Performance Budget.

In conclusion

  • Raise awareness through design, educate and guide your users on making the right choices.
  • Data over everything. Deconstruct data to find what the right solution is, i.e. beware of greenwashing!
  • Shift to green hosting and you could save thousands of KGs in CO2. (Again, beware of Greenwashing)
  • Starting with ourselves, as people first, and as designers second.
  • Optimising design and code across all mediums.

We are experiencing a revolution in design, it’s being discussed in relation to the world’s largest topics such as diversity and inclusion, digital divide and politics. Sustainability should become an inseparable part of that conversation. This blog merely scratches the surface, and I would be grateful to hear your other ideas on how we can sustain this planet for our children.

Anmar Matrood

Anmar Matrood

Anmar is a designer with a strong background in UX and visual design. His passion is to simplify complex UX problems and his goal is to make intricate information accessible to the masses. Anmar is also an avid freediver, photographer, traveller and researcher.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

In part 2 of my blog series on AngularJS migration, I’ll discuss the different methods for migrating an application and highlight the tools and resources that make it possible.

Tools and Resources

ngMigration Assistant

In August 2018 Elana Olson from the Angular Developer Relations team at Google announced the launch of the ngMigration-Assistant. When run this command line tool will analyse a code base and produce statistics on code complexity, size and patterns used in an app. The ngMigration Assistant will then offer advice on a migration path and preparation steps to take before beginning the migration.
The goal of the ngMigration Assistant is to supply simple, clear, and constructive guidance on how to migrate an application. Here is some example output from the tool:

Complexity: 86 controllers, 57 AngularJS components, 438 JavaScript files, and 0 Typescript files.
  * App size: 151998 lines of code
  * File Count: 943 total files/folders, 691 relevant files/folders
  * AngularJS Patterns:  $rootScope, $compile, JavaScript,  .controller
Recommendation
Please follow these preparation steps in the files identified before migrating with ngUpgrade.
  * App contains $rootScope, please refactor rootScope into services.
  * App contains $compile, please rewrite compile to eliminate dynamic feature of templates.
  * App contains 438 JavaScript files that need to be converted to TypeScript.
      To learn more, visit https://angular.io/guide/upgrade#migrating-to-typescript
  * App contains 86 controllers that need to be converted to AngularJS components.
      To learn more, visit https://docs.angularjs.org/guide/component

The ngMigration Assistant tool is a great place to start when considering migrating an AngularJS project. The statistics and advice it gives will help quantify the effort the migration will take and can highlight particular patterns that will need to be addressed. Be warned that the tool doesn’t cover everything and there will be additional areas of the application external libraries and some logic for example that will need reworking during migration. It’s a good first step but not comprehensive.

ngMigration Forum

The ngMigration Forum gathers together resources, guides and tools for AngularJS migration. The forum allows developers to ask questions and get answers on their migration problems, it also collates all the common issues that occur during migration.

The angular.io Upgrade Guide

The angular.io Upgrade Guide contains a number of examples and walkthroughs on how to proceed with an AngularJS migration. Written by the Angular team the guide addresses the most common cases and has a complete example of migrating the Phone Catalogue example application.

Deciding How to Migrate

There are 3 major approaches to migrating an AngularJS application to Angular.

Complete Rewrite in Angular

The first decision to make when considering migrating your Angular application is whether you will do it incrementally or not. If you need to support an existing application or the application is too large to fully migrate in a reasonable timeframe then an incremental upgrade may be the only path open. However, if the application is small enough or if you are able to stop supporting the existing application or allocate enough resources then a complete rewrite is usually the most straightforward approach.
Migrate the whole application without supporting the AngularJS version:
Pros

  • You don’t have to worry about upgrading or downgrading components
  • No interoperability issues between AngularJS and Angular
  • Opportunity to refactor areas of the code
  • Can benefit from Angular features immediately

Cons

  • The application will be offline during the migration or you will need to copy the code base to a new repository
  • You don’t see the benefits until the whole application is migrated which could take some time depending on the overall size
  • Since you will not see the whole application running until the end of the migration you may discover issues as you build more features

Hybrid Applications

ngUpgrade

ngUpgrade is an Angular library that allows you to build a hybrid Angular application. The library can bootstrap an AngularJS application from an Angular application allowing you to mix AngularJS and Angular components inside the same application.
I will go into more detail on the ngUpgrade library in Part 3: Implementing the Migration but for now, it’s important to know that ngUpgrade allows you to upgrade AngularJS directives to run in Angular and downgrade Angular components to run in AngularJS.

Horizontal Slicing

When migrating using a Hybrid approach there are two methods that will gradually move your application from AngularJS to Angular. Each has its advantages and disadvantages which I’ll discuss next.
Horizontal Slicing is a term used to describe the method of migrating building block components first (low-level components like user inputs, date pickers etc) and then all components that use these components and so on until you have upgraded the entire component tree.
migration routesImage: Victor Savkin
The term references the way that components are migrated in slices cutting across the whole application.
Pros

  • The application can be upgraded without any downtime
  • Benefits are realised quickly as each component is migrated

Cons

  • It requires additional effort to upgrade and downgrade components

Vertical Slicing

Vertical Slicing describes the method of migrating each route or feature of the application at a time. Unlike horizontal slicing views won’t mix AngularJS and Angular components instead each view will consist entirely of components from one framework or the other. If services or components are shared across the application then they are duplicated for each version.
vertical slicingImage: Victor Savkin
Pros

  • The application can be upgraded while in production
  • Benefits are gained as each route is migrated
  • You don’t have to worry about compatibility between AngularJS and Angular components

Cons

  • It takes longer to migrate a route so benefits aren’t seen as quickly as horizontal slicing
  • Components and services may need to be duplicated if required by AngularJS and Angular versions

Effort Needed to Migrate

Which method you adopt depends entirely on your business objectives and size of the application. In most cases, I’ve found that the hybrid approach is required and more often than not I’ve used vertical slicing during the migration. Maintaining a single working application at all times has always been a priority in my experience. Since the applications have also been very large the cleanest way to organise the migration across multiple teams has been to split the application up either by feature or by route and migrate each one in turn.
The amount of effort required again depends on your particular circumstances (size of the code base, number of people etc). I’ve found that putting everyone to work on migration at once leads to confusion and in turn wasted effort. What I’ve found is that by having a small team begin the work, bootstrap the hybrid application and produce some migrated components and services the rest of the team spends left effort getting started and instead begins scaling out the migration.

Part 3: Implementing the Migration

In part 3 I’ll go into fine detail on what code changes need to happen in preparation for the migration and how the actual migration is done.

Sources

You can read part 3 of this series here: https://gofore.com/en/migration-from-angularjs-part-3/
You can read part 1 of this series here: https://gofore.com/en/migrating-from-angularjs-part-1/

Rhys Jevons

Rhys Jevons

Rhys is a Senior Software Architect with over 10 years of experience in Digital Transformation Projects in the Media, Transport and Industrial sectors. Rhys has a passion for software development and user experience and enjoys taking on complicated real-world problems.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

In part 2 of my blog series on AngularJS migration, I’ll discuss the different methods for migrating an application and highlight the tools and resources that make it possible.

Tools and Resources

ngMigration Assistant

In August 2018 Elana Olson from the Angular Developer Relations team at Google announced the launch of the ngMigration-Assistant. When run this command line tool will analyse a code base and produce statistics on code complexity, size and patterns used in an app. The ngMigration Assistant will then offer advice on a migration path and preparation steps to take before beginning the migration.
The goal of the ngMigration Assistant is to supply simple, clear, and constructive guidance on how to migrate an application. Here is some example output from the tool:

Complexity: 86 controllers, 57 AngularJS components, 438 JavaScript files, and 0 Typescript files.
  * App size: 151998 lines of code
  * File Count: 943 total files/folders, 691 relevant files/folders
  * AngularJS Patterns:  $rootScope, $compile, JavaScript,  .controller
Recommendation
Please follow these preparation steps in the files identified before migrating with ngUpgrade.
  * App contains $rootScope, please refactor rootScope into services.
  * App contains $compile, please rewrite compile to eliminate dynamic feature of templates.
  * App contains 438 JavaScript files that need to be converted to TypeScript.
      To learn more, visit https://angular.io/guide/upgrade#migrating-to-typescript
  * App contains 86 controllers that need to be converted to AngularJS components.
      To learn more, visit https://docs.angularjs.org/guide/component

The ngMigration Assistant tool is a great place to start when considering migrating an AngularJS project. The statistics and advice it gives will help quantify the effort the migration will take and can highlight particular patterns that will need to be addressed. Be warned that the tool doesn’t cover everything and there will be additional areas of the application external libraries and some logic for example that will need reworking during migration. It’s a good first step but not comprehensive.

ngMigration Forum

The ngMigration Forum gathers together resources, guides and tools for AngularJS migration. The forum allows developers to ask questions and get answers on their migration problems, it also collates all the common issues that occur during migration.

The angular.io Upgrade Guide

The angular.io Upgrade Guide contains a number of examples and walkthroughs on how to proceed with an AngularJS migration. Written by the Angular team the guide addresses the most common cases and has a complete example of migrating the Phone Catalogue example application.

Deciding How to Migrate

There are 3 major approaches to migrating an AngularJS application to Angular.

Complete Rewrite in Angular

The first decision to make when considering migrating your Angular application is whether you will do it incrementally or not. If you need to support an existing application or the application is too large to fully migrate in a reasonable timeframe then an incremental upgrade may be the only path open. However, if the application is small enough or if you are able to stop supporting the existing application or allocate enough resources then a complete rewrite is usually the most straightforward approach.
Migrate the whole application without supporting the AngularJS version:
Pros

  • You don’t have to worry about upgrading or downgrading components
  • No interoperability issues between AngularJS and Angular
  • Opportunity to refactor areas of the code
  • Can benefit from Angular features immediately

Cons

  • The application will be offline during the migration or you will need to copy the code base to a new repository
  • You don’t see the benefits until the whole application is migrated which could take some time depending on the overall size
  • Since you will not see the whole application running until the end of the migration you may discover issues as you build more features

Hybrid Applications

ngUpgrade

ngUpgrade is an Angular library that allows you to build a hybrid Angular application. The library can bootstrap an AngularJS application from an Angular application allowing you to mix AngularJS and Angular components inside the same application.
I will go into more detail on the ngUpgrade library in Part 3: Implementing the Migration but for now, it’s important to know that ngUpgrade allows you to upgrade AngularJS directives to run in Angular and downgrade Angular components to run in AngularJS.

Horizontal Slicing

When migrating using a Hybrid approach there are two methods that will gradually move your application from AngularJS to Angular. Each has its advantages and disadvantages which I’ll discuss next.
Horizontal Slicing is a term used to describe the method of migrating building block components first (low-level components like user inputs, date pickers etc) and then all components that use these components and so on until you have upgraded the entire component tree.
migration routesImage: Victor Savkin
The term references the way that components are migrated in slices cutting across the whole application.
Pros

  • The application can be upgraded without any downtime
  • Benefits are realised quickly as each component is migrated

Cons

  • It requires additional effort to upgrade and downgrade components

Vertical Slicing

Vertical Slicing describes the method of migrating each route or feature of the application at a time. Unlike horizontal slicing views won’t mix AngularJS and Angular components instead each view will consist entirely of components from one framework or the other. If services or components are shared across the application then they are duplicated for each version.
vertical slicingImage: Victor Savkin
Pros

  • The application can be upgraded while in production
  • Benefits are gained as each route is migrated
  • You don’t have to worry about compatibility between AngularJS and Angular components

Cons

  • It takes longer to migrate a route so benefits aren’t seen as quickly as horizontal slicing
  • Components and services may need to be duplicated if required by AngularJS and Angular versions

Effort Needed to Migrate

Which method you adopt depends entirely on your business objectives and size of the application. In most cases, I’ve found that the hybrid approach is required and more often than not I’ve used vertical slicing during the migration. Maintaining a single working application at all times has always been a priority in my experience. Since the applications have also been very large the cleanest way to organise the migration across multiple teams has been to split the application up either by feature or by route and migrate each one in turn.
The amount of effort required again depends on your particular circumstances (size of the code base, number of people etc). I’ve found that putting everyone to work on migration at once leads to confusion and in turn wasted effort. What I’ve found is that by having a small team begin the work, bootstrap the hybrid application and produce some migrated components and services the rest of the team spends left effort getting started and instead begins scaling out the migration.

Part 3: Implementing the Migration

In part 3 I’ll go into fine detail on what code changes need to happen in preparation for the migration and how the actual migration is done.

Sources

 
You can read part 3 of this series here: https://gofore.com/en/migration-from-angularjs-part-3/
You can read part 1 of this series here: https://gofore.com/en/migrating-from-angularjs-part-1/
 

Rhys Jevons

Rhys Jevons

Rhys is a Senior Software Architect with over 10 years of experience in Digital Transformation Projects in the Media, Transport and Industrial sectors. Rhys has a passion for software development and user experience and enjoys taking on complicated real-world problems.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Martti, Emma, Sini ja Riku opiskelevat Tampereen yliopistossa kauppatieteitä. Tänä keväänä he yhdessä ideoivat kurssityönään Goforen tiimi-rekrytointikampanjan. Opiskelijoista hitsautui projektin aikana unelmatiimi, vaikkeivat he alussa tunteneetkaan toisiaan.

Martti Ketola (vas.), Emma Hinkka, Sini Sippola ja Riku Rantanen suunnittelivat kurssitehtävänään Goforen rekrytointikampanjan.

Alussa taustatyötä ja hulluja ideoita

”Aloitettiin homma hakemalla tietoa siitä mikä Gofore on ja mikä tekee siitä erilaisen”, kertoo Martti. Alussa lähdettiin rohkeasti vain ideoimaan ja lopulta tiimi kehitti yhteensä yli 30 ideaa, jotka lajiteltiin perusideoihin, arveluttaviin ja hulluihin. Opiskelijat kertovat, että tällainen ideoiden lajittelu mahdollisti sen, ettei ideointivaiheessa tarvinnut rajoittaa kampanjan lähestymistapoja. Idea kokonaisten tiimien rekryämisestä syntyi siinä vaiheessa, kun sai ideoida aivan mitä tahansa
Ideointia ryhmä oli pohjustanut haastattelemalla it-alan tuttuja ja kysymällä, mitkä tekijät saisivat heitä vaihtamaan firmaa. ”Olennaista ideassamme oli se, että ymmärrettiin it-alan työsuhde-etujen olevan jo niin hyvät, ettei niitä kannata nostaa rekrytointikampanjaan. Seuraavaksi pohdimmekin, mitä vanhasta työstä jää kaipaamaan. Usein hyvää ilmapiiriä ja työkavereita. Tärkeänä tekijänä ovat nimenomaan ne työkaverit, hyvä tiimi”, selittää Emma.

Unelmatiimi rakentuu luottamuksesta ja erilaisesta osaamisesta

”Unelmatiimissä jokaisen pitää pystyä olla oma itsensä ja tuomaan toisissa parhaat puolet esiin”, kertoo Sini.  Hänen mukaan tiimin jäsenet tällöin pelaavat hyvin yhteen ja jokaisella on oma osa-alue, jossa on tosi hyvä. Tämän myötä tiimi voi tehdä yhdessä parempaa tulosta kuin jäsenet erikseen.  Sini kertoo Martin loistaneen it-alaan liittyvässä tietoudessa, Emman tietäneen kaiken markkinoinnista ja Riku onnistuneen hyödyntäessään omat verkostonsa loistavassa taustatutkimuksessa.
Ennen kurssin alkua tiimin jäsenet eivät tunteneet toisiaan. Tästä huolimatta jäsenet olivat tyytyväisiä ryhmään ja kehuivat toistensa erityisosaamisten lisäksi erityisesti tiimin ilmapiiriä. ”Tiimissämme kunnioitettiin ja kuunneltiin toisiamme ja sallittiin se, että välillä oli parempia ja välillä huonompia päiviä”, kertoo Riku. Martti lisää ilmapiirin mahdollistaneen sen, että omia ajatuksia oli helppo esittää. Kun ideat uskalsi sanoa ääneen, oli muut tiimin jäsenet valmiina jatkamaan ja kehittämään ideoita. ”Kun tietää että tiimiin voi luottaa ja että toisetkin vievät asiaa eteenpäin, niin homma toimii. Se on jotain mitä toivon unelmatiimiltä. Tässä tapauksessa se löytyi meidän tiimistä”, summaa Martti.

Onnistuneessa opiskelijayhteistyössä kehittyvät opiskelijat ja yritys

”Opiskelijoiden suunnittelema kampanja oli nerokas, joten tietenkin halusimme toteuttaa sen”, kommentoi Goforen rekrytoinneista ja työnantajamielikuvasta vastaava Anni Roinila. Hän kertoo, miten Goforella uskotaan paitsi tiimien voimaan, uskalletaan myös luottaa niiden autonomiaan. Tämä näkyy muun muassa siinä kuinka tiimit itse valitsee parhaat toimintatavat, tekevät päätökset yhdessä ja huolehtivat itse myös esimerkiksi rahankäytöstään.
Anni kertoo Goforen tekevän paljon erilaista yhteistyötä opiskelijoiden kanssa, mutta kokee hedelmällisimmäksi opiskelijoiden mukaan ottamisen oikeisiin projekteihin: ”Tietenkin excuille ja muille kiltasponsoroinneille on ehdottomasti paikkansa, mutta kaikista hienointa on, kun pystymme luomaan tavan tehdä yhteistyötä, josta oppivat sekä opiskelijat että me itse. Oikeiden työelämäprojektien avulla opiskelijat pääsevät löytämään työelämäkontakteja ja aidosti näkemään, millaista on työelämä Goforen kaltaisessa yrityksessä.”
Valmiin rekrytointikampanjan löydät täältä: gofore.com/teams.
Lue, miten tiimirekrytointi vakiintui pysyväksi väyläksi hakea töihin Goforelle: https://gofore.com/tiimirekrytointi/.

Nelikon omia suosikkitiimejä ovat Viisikko, The Rolling Stones, Spice Girls ja ankanpojat.

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.

Tässä Recoding-podcastin jaksossa keskustelimme Nina Nissilän kanssa. Ninalla on viimeiseltä muutamalta vuodelta huikea kokemus varsinkin julkishallinnon digitalisaatiokehitykseen liittyen, ensin Valtiokonttorin D9-tiimin vetäjänä ja nyt Kelan johtajana. Tätä kokemusta vasten puhuimme siitä, miten muutosta pitää johtaa, kun maailma ympärillä muuttuu jatkuvasti.
Ninan ajatus on, että parhaimmillaan digitalisaatio ja teknologia eivät käyttäjän kannalta näytä yhtään miltään. Minusta tässä on hieno ja arvokas ajatus. Samalla ei pidä unohtaa, että tällaisen asiakaskokemuksen takana on paljon muutosta, osaamista ja töitä.
Tällä hetkellä tapahtuva muutos on ennen kaikkea ICT:n ja muun teknologian kehityksen draivaamaa. Kehitys on ennennäkemättömän nopeaa ja sen piiristä nousee jatkuvasti uusia asioita, joita organisaatiossa tulee hallita. ”Näkymätön teknologia”, joka ratkaisee asiakkaiden ongelmia, syntyy vain riittävän osaamisen myötä. Nina kertoi, että Kelassa tämä on ratkaistu suurelta osin oman in-house IT-palvelukeskuksen avulla.
Paraskaan teknologiaosaaminen ei kuitenkaan riitä. Huipputason asiakaskokemus ei synny vahingossa, vaan vaatii, että ymmärrämme aidosti asiakkaiden tarpeita ja osaamme suunnitella näitä tarpeita palvelevia ratkaisuja. Muotoilun keinoin syntyy helppokäyttöisiä ja tarkoituksenmukaisia digitaalisia palveluja. Samoilla osallistavilla ja yhteiskehittämistä korostavilla menetelmillä pitää myös miettiä koko palveluketju uudestaan ja muotoilla sen taustalla oleva organisaatio. Kelassa jopa strategiaprosessikin toteutetaan muotoilun keinon.
Kenties kaikkein tärkeintä on kuitenkin johtaminen. Innovaatiot ja organisaation kyky uudistua saavat polttoaineensa modernista organisaatiokulttuurista, jossa innostuneet ihmiset työskentelevät yhteisen päämäärän puolesta. Nina kertoi Kelan uudesta innovaatiokeskuksesta, jossa tehdään erilaisia kevyitä kokeiluja uuden oppimiseksi. Uuden oppiminen voi oikeanlaisessa kokeiluja ruokkivassa ympäristössä usein tarkoittaa myös sitä, että opitaan mikä ei toimi.
Kelan kaltaisen suuren ja perinteikkään organisaation muuttaminen ei ole helppoa. Se on kuitenkin välttämätöntä, kun maailma ympärillämme muuttuu. On erinomaisen hienoa kuulla, että myös Kelassa on otettu jo askeleita muutoksen tiellä.
Kuuntele jakso SoundCloudista tai lue artikkeli alta:

Digitalisaation tuoma jatkuva muutos vaatii innovointia ja uudistumista
Kelan yksi keskeinen kehityskohde tällä hetkellä on parantaa tiedon liikkuvuutta digitaalisessa muodossa eri toimijoiden välillä. Ninan mukaan monet pelkäävät, että automatisaatio poistaa ihmiskontaktin kokonaan, mutta tähän hän ei usko. Digitalisaatio auttaa tehostamaan toimintaa ja palvelua, mutta ihmistä tarvitaan yhä. Hän huomauttaa, että parhaimmillaan digitalisaatio ei itseasiassa näytä miltään. Esimerkiksi veroilmoituksista 70 % hoituu jo niin, että ihmiseltä vaaditaan vain verottajan kirjeen tarkastaminen. Tämän Nina näkee tavoiteltavana mallina: ihmisiä kaduilla kävelyttävien robottien sijaan teknologian tehtävä on vapauttaa ihmisille aikaa. Tällaisten palveluiden kehittämisessä myös Gofore toimii neuvonantajana, esimerkiksi juuri Kelalle.
Jatkuvassa muutoksessa olevassa maailmassa uusien innovaatioiden tärkeyttä korostetaan, ja niihin on myös Kelassa panostettu. Vaikka innovaatioita kehitetään, uudistuminen Kelan kokoisessa organisaatiossa tapahtuu kuitenkin hitaammalla tahdilla. Tällä hetkellä keskitytään IT-palvelujen uudistamiseen, jota varten 1.4. alkaen aloitti toimintansa uusi innovaatioyksikkö. Uuden yksikön tehtävänä on kokeilla nopealla syklillä uusia teknologioita ja niiden soveltuvuutta julkisiin palveluihin. Vaikka uusia innovaatioita kehitetään, vaatii teknologioiden ja toimintamallien käyttöönotto aina suurta määrää työtä ja suunnittelua julkishallinnon palveluiden asiakaskunnan laajuuden vuoksi. Nina myös korostaa, että vaikka uusien innovaatioiden kehittämisen tulee olla kiinteä osa toimintaa, ei olemassa olevien perusjärjestelmien kehittämistä saa unohtaa.
Palvelumuotoiltua strategiaa ja johtamista
Kelassa on paraikaa käynnissä myös strategian uudistus. Nina näkee strategian palveluna, joka tarjoaa suuntaviivat sinne, mihin organisaation on tarkoitus mennä. Strategian näkeminen palveluna antaa käyttöön palvelumuotoilun työkalut, joiden avulla strategiaa on nyt lähdetty Kelassa kehittämään. Palvelumuotoilua tullaan Ninan mukaan hyödyntämään strategian ohella myös toimintatapojen ja prosessien uudistamiseen.
Vaikka Kelan strategiaa uudistetaan, tulee erinomainen asiakaskokemus olemaan edelleen sen keskeisissä tavoitteissa. Ninan mukaan onnistuneen asiakaskokemuksen ytimessä on tyytyväiset työntekijät ja siksi hän nostaa myös erinomaisen työntekijäkokemuksen varmistamisen esiin strategisena tavoitteena.
Innovaatioita ja asiakaskokemusta tukeva johtamistapa eroaa perinteisestä johtamisesta julkisella sektorilla. Nina kertoo, että hänen on sanottu olevan epätyypillinen virkamies ja hän näkee omana vahvuutenaan sen, että hän on innostunut siitä mitä tekee ja hän laittaa itseään likoon. Omalla esimerkillään hän osoittaa kiinnostusta työhönsä ja uskoo sen motivoivan myös muita. Johtajana hän pyrkii tarjoamaan alaisilleen tavoitteita, suuntaviivoja ja rajoja, mutta jättää vapauden toteutuksesta työntekijöilleen.
Ninan mukaan työhön tulee suhtautua vakavasti, mutta uskoo rennon meiningin ruokkivan tuloksentekokykyä. Ninan mukaan organisaatio, jossa ihmisten on hauska tehdä töitä, olisi hänelle suurin ylpeyden aihe. Tällaisen organisaatiokulttuurin luomisessa Kelan etu on se, että ihmiset kokevat yleensä työnsä merkitykselliseksi: he vaikuttavat työllään suoraan ihmisten arkeen ja toimeentuloon.

Uskotko sinä muutokseen? Siihen, että voit muuttaa maailmaa paremmaksi ihmisille ja ympäristölle?
Tutustu uuteen julkaisuumme ja asiantuntijoidemme näkemyksiin: Recoding change

Avatar

Mikael Nylund

Mikael on Goforen johdon konsultoinnin palveluista ja yritysjärjestelyistä vastaava johtaja sekä toimitusjohtajan sijainen. Hän on työskennellyt Goforessa vuodesta 2010 lähtien ja auttanut sinä aikana lukuisia organisaatioita polulla kohti digitaalista liiketoimintaa. Mikael ajattelee, että parempi tulevaisuus tehdään teknologian avulla ihmisten ehdoilla.

Piditkö lukemastasi? Jaa se myös muille.


Tieto asiakkaista kasautuu organisaatioissa epätasaisesti. Nykyisillä tiedonkeruun ja hyödyntämisen tavoilla se ei leviä, eikä siitä kasva läpi organisaation hyödynnettävää, arvokasta, pääomaa eli asiakasymmärrystä.

 
Usein asiakastietoa kerätään pistemäisesti erityisesti projektien alussa. Tiedonkeruun ja ymmärrykseksi jalostamisen mekanismit ja toiminnan jatkuvuus puuttuvat. Ja juuri ne olisivat tässä ajassa kaikkein olennaisimmat asiat!
Asiakkaat muuntautuvat aiempaa nopeammin kaikilla tasoilla. Selkeiden linjausten sijaan strategian ytimen voi muodostaa oikean suunnan hakeminen kokeilemalla. Asiakas on osa ekosysteemejä, eikä itsekään välttämättä tiedä, missä oman toiminnan rajat päättyvät tai mitä tehdä.
Siksi vastaukset vuosi sitten kysyttyihin kysymyksiin voivat olla tänään ihan erilaisia. Tarkkuutta tekemiseen tuo ymmärrys monimutkaisista kokonaisuuksista, jotka asiakasta ympäröivät.

Muutos, jota kohti nyt mennään

Yllä kuvattuun tilanteeseen vastaamiseksi on kehitetty useita keinoja. Kolme omasta mielestäni kiinnostavinta kehityssuuntausta ovat:

  1. Asiakasymmärryksen hajautettu johtaminen

Yhä useammat organisaatiot purkavat perinteisiä päätöksenteon mekanismeja. Nykyisin moni organisaatio antaa merkittävääkin päätöksentekovaltaa organisaation kaikille tasoille.  Näissä organisaatioissa ymmärretään, että päätökset tulee perustaa asiakasymmärrykseen – joka kertyy eri puolilla organisaatiota.

  1. Asiakasymmärryksen jatkuva kerryttäminen

Päätöksiä on pystyttävä tekemään nopeasti. Asiakasymmärryksen kerryttäminen, esimerkiksi asiakastutkimus tai tarvekartoitus, vie liikaa aikaa yksittäisen päätöksen tueksi. Organisaatioihin on syntynyt tarve kerryttää asiakasymmärrystä kaiken aikaa, jotta siihen voidaan peilata päätösten teossa riittävän nopeasti.

  1. Asiakasymmärryksen jalkauttaminen useille organisaation tasoille

Ennen yritykselle saattoi riittää, että tuotteen kehitystiimi ymmärsi asiakastarpeita. Palveluliiketoiminnan jatkuva kasvu on siirtänyt tämän tarpeen tiimitasoilta organisaation tasolle. Palveluiden tuottamiseen osallistuu tyypillisesti suuri joukko työntekijöitä yrityksen eri puolilta ja näillä ihmisillä on oltava yhteinen ymmärrys asiakkaan tarpeista.
Kaikkia yllämainittuja kehityssuuntia yhdistää ajatus siitä, että asiakasymmärryksen kerryttäminen, johtopäätösten tekeminen on liiketoiminnan keskeinen osa. Siksi sitä pitää alkaa johtaa.

Keinoja aloittamiseen

Tieto ei saa enää jäädä hautumaan ihmisten mieliin tai palautelaatikoihin. Se pitää saada hyötykäyttöön ja siitä pitää jalostaa yhteistä ymmärrystä.
Siksi jokaisessa organisaatiossa tarvitaan sekä tarkasti kohdennettuja tutkimuksia että yleisempää kuvaa niistä ekosysteemeistä, joissa asiakkaat toimivat. Keinoja siirtyä satunnaisista kohtaamisista järjestelmälliseen tiedonkeruuseen ja jalostamiseen, jossa kokemustieto ei värity kuulopuheiden perusteella liiaksi.
Yksinkertainen, kaikkien toteutettavissa oleva keino kokonaiskuvan luontiin on koota asiakkaista ja heidän tarpeistaan kerätyt, ajantasaiset tiedot eri puolilta organisaatiota yhteen. Seuraavaksi tavoitteeksi voidaan ottaa eri tutkimukset kattava analyysityö kokonaiskuvan muodostamiseksi. Kolmannessa vaiheessa pidetään yllä priorisoitua listaa tiedonjyväsistä, jotka pitää seuraavaksi selvittää asiakkaista.
Haluatko aloittaa työn heti? Ollaan yhteydessä!
 
Uskotko sinä muutokseen? Siihen, että voit muuttaa maailmaa paremmaksi ihmisille ja ympäristölle?
Tutustu uuteen julkaisuumme ja asiantuntijoidemme näkemyksiin: Recoding change

Mikko Nurmi

Mikko Nurmi

Mikko haluaa ratkoa yritysten ja yhteiskunnan ongelmia hyödyntäen käyttäjäymmärrystä, liiketoimintaosaamista ja uusien teknologioiden tuomia mahdollisuuksia. Osoituksena idearikkaudesta ovat yli sata myönnettyä patenttia käyttöliittymien ja digitaalisten palveluiden alueilta.

Piditkö lukemastasi? Jaa se myös muille.

First, what do we mean when we talk about maintenance?

We make a lot of custom-made solutions, systems, applications and services to our customers. These projects can last anywhere from a few weeks to a few years, but they do usually have a specific goal and an expiration date. However amazing the final product is, and however much we’ve learned from creating it, the product will only start bringing value to our customers after it’s gone live. This is when we enter the maintenance phase.
Software maintenance offers the customer technical support, incident management and bug fixes, plus change management and further development to their existing live product. We want to guarantee that our super amazing product keeps being super amazing and does not simply fall into decay after it’s gone live. This is a matter of pride to all of us: quality in Gofore’s project delivery even after the project has been delivered.

software maintenance meeting

How would you prepare for a marathon?

A software project typically has a beginning, includes various steps taken to create the desired product, and finally, it comes to an end. You might find yourself tempted to think that the end of the project signifies the end of the software company’s work. However, the final release of the development project is the starting gun for the software maintenance phase.
It is part of our expertise at Gofore that, at the very start of a project, we explain to the customer that we should be making plans for when the product goes live and what happens after that. You wouldn’t run a marathon without practising and training for it. The maintenance phase can last for years after the product has gone live! For example, projects usually have multiple waypoints or sprint goals during the development phase. Maintenance should be included in this thinking – not just as a single point or event to reach, but as a natural and continuous extension of the development work.

Have you ever felt like…?


Not to worry, we have a solution for you: a centralized service desk and organized software maintenance.
While we who work with software maintenance daily are very excited about our great services, the most common thing we’ve heard in the past is that ”only creating new products and services through coding is fun and exciting,” while maintenance is sometimes seen as a boring routine or an ungrateful chore that no one wants to do.
If you view maintenance this way, you probably aren’t up to speed with the latest news from the world of Service Desks. Maintenance in the year 2019 looks very different from even just a few years back, and it keeps evolving at a fast pace. Robotics and automation already take care of those boring routine tasks. The first line no longer just escalates tickets or parrots, ”Have you tried turning it off and on again?” Those days are history.
At Gofore, our Service Center consists of specialists who resolve the complex issues the customers couldn’t solve themselves. As all the products we create are custom-made, maintaining them requires deep understanding and knowledge of a multitude of systems, programming languages and infrastructures. Service management, i.e. the maintenance phase equivalent for project management, is also known to increase its importance in the next few years. Service management and software maintenance require more and more expertise and specialized people year after year.

Don’t just take our word for it…

Here are some thoughts from our developers:

”Maintenance tasks improve your problem-solving skills, out-of-the-box thinking, social skills, and increase familiarity with the architecture. Participating in software maintenance is beneficial to all developers.” – Antti Simonen
”Software maintenance offers unique insight into the application’s issues and gives you a chance to make the customer happy. The quality of the code is continuously improved by maintaining your own applications.” – Petri Sarasvirta
”Understanding the application from someone else’s perspective enables you to write code that can be maintained more easily. One of the best ways to gain a better grasp of the big picture is through software maintenance.” – Antti Peltola

Our biggest supporters are our customers. Every month the people who do software maintenance at Gofore receive 5-star reviews from our very happy customers!

Actionable steps to success!

Here are some things to consider if you are a software developer:

  • When you write code, write it for others, not yourself. To put it in another way: if you can’t read your own code without a 30-page manual right now, you can only imagine how impossible the task is for someone who has to find and fix a bug in it two years later.
  • Make sure your commits are sufficiently descriptive. As all Agile developers know, documentation should not be a forced burden – but it is necessary, nonetheless. Work smart, not hard, and make sure your code speaks for itself. Remember to also keep your software delivery mechanisms (CI/CD) and infrastructure (servers, firewalls, etc) sufficiently documented.
  • Have tests and monitoring in place for production. You are the expert on what needs to be monitored and how it should be done.

And some notes for the project managers in our midst:

  • Allow time for proper documentation and make sure your customer understands its value. It should be your ethical guideline that we cannot skip such an important part of the project’s delivery.
  • Make sure your project team tests and monitors things that are significant in terms of business value. You have a unique understanding of both what is important to the customer and what your team can deliver.
  • Start preparing for the production/maintenance handover well on time. The earlier you give your colleagues who work with maintenance a heads-up, the better they can help you make the transition as smooth as possible.

software maintenance meeting at GoforeValue for the customer

Continuous services guarantee that the custom-made system, application or service works as planned throughout its lifecycle. Stability and quality in continuous services are a matter of honour and pride to our service managers. We are seasoned professionals and know how to navigate and translate between the development team and the customer, making sure all parties understand each other.
We meet customer expectations by proactively offering new solutions and further development, keeping in mind improving the customer’s business. Continuous services free the customer’s resources from maintenance to their own business. Finally, the most important thing we offer is peace of mind – the customer simply raises a ticket describing their concerns, and our Service Center swiftly takes care of the rest.

What’s in it for me?

So, you might be wondering, ”What’s in it for me?” To sum up, keeping the maintenance phase in mind has its benefits…

  • …for sales, longer lasting customer relationships
  • …for developers, doing maintenance makes you ”harder, better, faster, stronger”
  • …for project managers, less stress about moving to production
  • …for our customers, stability, quality and peace of mind
Avatar

Ella Lopperi

Ella captains Gofore's Service Center, making sure maintenance is smooth sailing for customers and Goforeans alike. Doubling as a Service Manager, she believes honest and clear communication to be the key to a great customer experience. When out of the office, Ella reads voraciously, enjoys videogames and studies the wonders of the Universe.

Jenna Salo

Jenna Salo

Jenna toimii Continous Services Leadina ja palvelupäällikkönä. Jennan jokapäiväisen työn lähtökohtana on tarjota asiakkailleen mielenrauha. Työkulttuuri on myös lähellä hänen sydäntään. Vapaa-ajallaan Jenna on kahden chihuahuan nöyrä palvelija, ja jenkkiautot ja kellohameet saavat hänet takuulla innostumaan.

Linkedin profileTwitter profile

Piditkö lukemastasi? Jaa se myös muille.