Webinar 2: Service2Media - Mobile Maturity Model: Initiation & design 13 Feb 2014

1

30 MINUTEN Welcome! How to build your Mobile App Competence Center? Webinar Series.. #2 Initiation and Design Peter Broekroelofs CTO

Agenda

2

•  Mobile Strategy •  A Mobile Maturity Model for Your App Center

•  #2 Ini9a9on and design •  App incep9on and ra9onale •  App intake and approval •  App defini9on •  App Design •  Architecture

COMPANIES STRUGGLE TO TRANSITION TO STRATEGIC MOBILITY

3

Opportunistic Strategic Mobile-First

The majority of companies A small minority of companies Very few, if any, companies

A reactive IT department

Mobility Center of Excellence: C-level attention, self-empowered lines of business, a responsive IT department

Low

Organization-wide strategic focus

Medium High

Most of the time customers only. Some-times siloed employee classes, typically field and sales forces and applications addressing basic informational interactions

Limited extendibility of architecture

Addresses large subsets of both dedicatedly and occasional mobile workers and more sophisticated offerings to customers. Transactional driven

Affects all mobile workers and internal activities and sophisticated customer engagement

Common architecture for mobility

Common architecture for mobility and integrated into most IT business processes

Siloed point solutions

Sophisticated administration and management tools; voice, data and integrated communications services

Integrated platform capabilities and ubiquitous connectivity

Few formal policies with decisions heavily user-influenced

Policy-driven approach for management, security and compliance

Policy-driven and 'factory' approach to mobile innovation, re-casting business workflows

Proportion of companies

Mobile strategy center of gravity

Level of business model innovation

Users

Architecture

Technologies

Policies

The Opportunistic Market in Transition

Experimentation is giving way to a more thoughtful approach to mobility. Organizations are taking a step back and rethinking how best to maximize the value of mobility. 3

1 "The early days of mobile adoption were characterized by experimentation and unfettered departmental demand for mobile apps. These apps, funded by the business, tend to be natively developed, and are built quickly and cheaply and often without coordination with the rest of the organization or a view to long-term sustainment and value maximization.

2 Such experimentation and piloting are necessary for organizations to test and learn about mobility, with the lessons learned that enterprise mobility can show significant business value, and that not embracing enterprise mobility will put the organization at a competitive disadvantage.

Source: Gartner, 2013

Mobile Maturity Model Explained

5

Disclaimer J

HOW TO GROW YOUR MOBILE MATURITY?

6

1. What is your Mobile Strategy Maturity goal? 2.  How are you performing currently? 3. What are the gaps? 4.  Define gaps that matter most 5.  Prioritize and close the gaps

7

Opportunistic Strategic Mobile-First

The majority of companies A small minority of companies Very few, if any, companies

A reactive IT department

Mobility Center of Excellence: C-level attention, self-empowered lines of business, a responsive IT department

Low

Organization-wide strategic focus

Medium High

Siloed employee classes, typically field and sales forces and applications addressing basic customer interactions

Limited extendibility of architecture

Addresses large subsets of both dedicatedly and occasional mobile workers and more sophisticated offerings to customers

Affects all mobile workers and internal activities and sophisticated customer engagement

Common architecture for mobility

Common architecture for mobility and integrated into most IT business processes

Siloed point solutions

Sophisticated administration and management tools; voice, data and integrated communications services

Integrated platform capabilities and ubiquitous connectivity

Few formal policies with decisions heavily user-influenced

Policy-driven approach for management, security and compliance

Policy-driven and 'factory' approach to mobile innovation, re-casting business workflows

Proportion of companies

Mobile strategy center of gravity

Level of business model innovation

Users

Architecture

Technologies

Policies

WHAT IS YOUR MOBILE MATURITY GOAL?

8

1.  Strategy and Organization 2.  Initiation and Design 3.  Development and Maintenance 4.  Test and Distribution 5.  Security and Management 6.  Backend and Integration

MOBILE MATURITY MODEL - ASSESMENT AXES

9

MOBILE MATURITY MODEL - LEVEL DETERMINATION

OPPORTUNISTIC

Developing

Aware

STRATEGIC

Optimising

Practicing

MOBILE FIRST

Leading

Opportunis9c Strategic Mobile First

Strategy & Organisa9on

Prac3ce observed 1 ✔ x Prac3ce observed 2 ✔ x Ini9a9on & Design

Prac3ce observed 1 ✔ x Prac3ce observed 2 ✔ Development & Maintenance

Prac3ce observed 1 x

10

MOBILE MATURITY MODEL - GAP IDENTIFICATION

Key Players

11

CIO CTO CMO Developer

Designer

Tester

Security Officer

Scrum master

Chapter two:

12

Initiation and design

Initiation and Design (1/5)

13

App Incep9on and Ra9onale


App opportunity iden3fica3on is based on 'tradi3onal' IT process

App opportunity iden3fica3on is an agile, crea3ve process

App opportunity iden3fica3on is regular process as part of total solu3on scan aligned with core business processes

Prac3ces Observed

1) App Thinking 2) App opportunity iden9fica9on 3) Business case

ENTERPRISE APPS THE FACE OF SYSTEMS OF ENGAGEMENT

User-Centric Enterprise Apps | 14


15






Prac3ces Observed


STRATEGIC BUSINESS OBJECTIVES

Acquisi'on Reten'on Efficiency

IMPACT INNOVATIONS USER NEEDS (B2C & B2E)

Goals Emo'ons

Interac'ons ISSUES INSIGHTS

TRENDS & ACCELERATORS

Technology, Behavioral, Business Trends

Mobile Strategy (CX) Design Approach


17






Prac3ces Observed


Achieve Sustainable Business Growth & Profit CX = A + R + E

INCREASE BRAND EQUITY

INCREASE MARKET SHARE

INCREASE SHARE OF WALLET

DRIVE LOYALTY

DRIVE ADVOCACY

INCREASE ROI

INCREASE PRODUCTIVITY

DECREASE COST OF OPERATIONS

RETENTION (MONETIZE RELATIONSHIPS)

ACQUISITION (INCREASE SALES)

EFFICIENCY (LEVERAGE INVESTMENTS)

GENERATE MORE OPPORTUNITIES

APP


19

App Intake and Approval


App requests intake is ad hoc and approval process is long and 'hard'

Efficient business planning process with joint pipeline between business and IT

App Pipeline building is embedded in the IT core process

Prac3ces Observed

1) App Intake 2) Accuracy of quotes 3) Approval


20






Prac3ces Observed


Points of Impact: User Life Cycle & App Life Cycle

Marke3ng & Sales

Service & Support


22






Prac3ces Observed



23

App Defini9on


App defini3on is determined ad hoc and visually documented

App defini3on is result of customer journey, with clear user stories and visual protoype

App defini3on is part of the total solu3on defini3on, only highligh3ng new elements

Prac3ces Observed

1) App Requirements 2) Tools 3) Back-‐end requirements


25

App Defini9on





Prac3ces Observed


Advanced app solutions | 26


27

App Defini9on





Prac3ces Observed



28

UI Design


Client designs from scratch with image manipula3on so\ware, na3ve design tools or HTML5 tools

Client uses design tools in combina3on with reusable templates/design components in lifecycle approach

Client uses cross pla_orm design tools and templates with addi3onal emphasis on UX and Usability

Prac3ces Observed

1) Cross pla[orm design 2) Design process 3) Standardisa9on

APP DEVELOPMENT PARADIGMS

29

Drive for better user experience

HYBRID

NATIVE CONTAINER

HTML CODE

DEVICE API

NATIVE

NATIVE CONTAINER

DEVICE API

NATIVE CONTAINER

M2ACTIVE API

M2ACTIVE APP

WEB

DEVICE API

BROWSER

WEB BROWSER

HTML CODE

DEVICE API

NEAR-NATIVE

Drive for cross-platform efficiency


30

UI Design





Prac3ces Observed


31

M2ACTIVE STUDIO BRIDGING THE GAP BETWEEN DESIGNER EN DEVELOPER

33


34

UI Design





Prac3ces Observed


35

36


37

Architecture


Architecture is done on the fly, just solving the issues that come up when integra3ng apps with current (web) infrastructure and so\ware architecture. (Limited extendibility)

Architecture is done for client and server to op3mise for mobile performance and future maintenance (common architecture for mobility)

Architecture is based on mobile paradigms as star3ng point on client and server, redesigning legacy elements where needed (common architecture for mobility and integrated into most IT business processes)

Prac3ces Observed

1) Data exposure 2) Reference architecture 3) Dependency management


38

Architecture





Prac3ces Observed



39

Architecture





Prac3ces Observed


Incep3on and ra3onale pb App opportunity iden3fica3on is based on 'tradi3onal' IT process



Prac'ces observed

pb App thinking -‐ "Systems of Records" is central to app iden3fica3on process (inside-‐out) App opportuni3es iden3fica3on -‐ embryonic app opportuni3es scan within the business, e.g. app contest Business case -‐ Emerging business ra3onale in addi3on to "me-‐too"

App thinking -‐ "Systems of Engagment" -‐ agility is iintroduces (outside-‐in) App opportuni3es iden3fica3on -‐ A systema3c method is in place (customer journey) to determine app opportuni3es Business case -‐ Each app requires a business case

App thinking -‐ Systems of Engagement thinking is star3ng point for every IT investment App opportuni3es iden3fica3on -‐ Customer journeys are used to enhance app opportuni3es and develop app por_olio coherence Business case -‐ The business case is derived from the overall business strategy

App intake and approval pb App requests intake is ad hoc and approval process is long and 'hard'



Prac'ces observed pb

App intake -‐ Emerging intake process Accuracy -‐ Consistancy and accuracy of App requests and quotes is growing Approval -‐ Cumbersome, lengthy (old school) approval process with many stages in siloed organisa3on

App intake -‐ Central (formal) process for app intake exists Accuracy -‐ Reasonable accuracy on 3me and costs of the en3re app lifecycle Approval -‐ Approval processes are balanced in dura3on with clear gates; Business and IT are aligned about scope and budget

App intake -‐ Intake for apps is embedded in the intake process for other IT investments Accuracy -‐ Accurate, fast and flexible quota3on process in joint effort between Business and IT based on previous experience Approval -‐ Approval for mobile apps is part of total solu3on approval process. Silo's are gone

App defini3on pb App defini3on is determined ad hoc and visually documented


App defini3on is part of the total solu3on defini3on, only highligh3ng new elements and reusing the rest

Prac'ces observed pb

App requirements -‐ App requirements process is ad hoc, including features to match compe33on or because they are 'nice-‐to-‐have' Tools -‐ (Graphical) Design tools are used to define app requirements Backend requirements -‐ Content sources are iden3fied

App requirements -‐ App requirements are result of customer journey and mapped in user stories and high level UX visualisa3on/prototypes Tools -‐ User stories are detailed in sprints and are evaluated with prototyping tools Backend requirements -‐ Architectural skeleton with content flows

App requirments -‐ App Requirements are a subset of the total customer journey, only covering the subset that is new in the app por_olio. The rest (e.g. generic requirements like device support, screen orienta3on, phone/tablet) is reused. Tools -‐ User stories are used and kept up-‐to-‐date during the complete lifecycle; reuse is facilitated by tooling Backend requirements -‐ Backend requirements focus on new func3onality. Exis3ng func3ons are available and mobile op3mized and can be reused.

Graphical & Interac3on Design dt Client designs from scratch with image manipula3on so\ware, na3ve design tools or HTML5 tools

Client uses design tools in combina3on with reusable templates/design components

Client uses cross pla_orm design tools and templates.

Prac'ces observed dt

Designs -‐ specific for each specific OS Interac3on design and graphics design -‐ mixed Primary design tools -‐ Photoshop, Visio,…

Designs -‐ same or similar designs for all OS's Interac3on design and graphical design -‐ increasingly based on templates: a library of design objects is created Design tools -‐ Separate tools for interac3on and graphical design

Designs -‐ equal designs but harmonised for a specific 'na3ve' look and feel Interac3on design and graphical design -‐ Design templates ac3vely maintained Design tools -‐ use of prototyping tools, producing 'real' apps without a business logic or with templated business logic

Architecture (infrastructure) dt Architecture is done on the fly, just solving the issues that come up when integra3ng apps with current (web) infrastructure and so\ware architecture. (Limited extendibility)



Prac'ces observed dt

data exposure -‐ project specific reference archictecture -‐ embryonic dependency management -‐ embryonic

data exposure -‐ mobile specific interface are developped reference architecture -‐ encompasses all "systems of Engagment" dependency management -‐ follows a roadmap

data exposure -‐ becomes informa3on exposure, all interfaces serve all clients reference architecture -‐ global, integra3ng the needs of all poten3al clients (browser, apps, …) dependency management -‐ all systems serve all clients; specific mgt is no longer required

Advanced app solutions | 40

Are you interested in a Mobile Strategy Maturity Assessment?

[email protected]

41

Next Webinar March 13th

42

#3. Security and Management by Derk Tegeler