2014 Asdenca - Capability-driven development of a soa platform, a case study

Capability-driven development of a SOA platform:

a case study

FP 7 ICT Programme Collaborative Project no: 611351

International Workshop on Advances in Services DEsign based on the Notion of CApability ASDENCA 2014

S. España, T. González, J. Grabis, L. Jokste, R. Juanes and F. Valverde


a case study



Agenda

Introduction Research methodology Case study Lessons learned Conclusion

Introduction Capability-driven development of a SOA platform: a case study

This story has fictional elements!

What is a capability?

I want to sell ice creams in all Spain


GoalCapability requires

Indicator

requires

influences

Context Set requires

Context Type

measured by

Pattern

requires

Process

motivates

Process Variant

Resource

Context Element

Measurable Property KPIContext

Indicator

requires

defines

supported by requires

related_to

Context Situation

has value

requires

has

Context Element Range

consists of

ContexElement

Value

consists of


GoalCapability requires

Indicator

requires

influences

Context Set requires

Context Type

measured by

Pattern

requires

Process

motivates

Process Variant

Resource

Context Element

Measurable Property KPIContext

Indicator

requires

defines

supported by requires

related_to

Context Situation

has value

requires

has

Context Element Range

consists of

ContexElement

Value

consists of

Capability-‐driven development No empirical valida;ons We conduct a case study


a case study



Agenda


Practical problem investigation • Investigate the need for a capability-driven development methodology and tools (stakeholders, goals, criteria). • Phenomena, diagnosis.

Solution design • Explore available solutions by reviewing state of the art • Design a new solution; i.e. the CDD proposal under development in project CaaS: • Capability modelling (goals, context, enterprise). • Pattern-based solution (repository, rules). • Support tools (design and runtime environment).

Solution validation • Demonstrate feasibility with lab demos. • Evaluate the benefits, the trade-offs, and the sensitivity of the solution

Research problem investigation • Current knowledge (see Section 2). • Research questions (see Section 3). • Unit of study (see Section 4.1).

Research design • Select project (see Section 3). • Define research protocol and agree with company (see Section 3). • Define instruments

Research design validation • Ensure effectiveness of protocol and instruments • Validity threats trade-off (see Section 5).

Research execution • Conduct interviews, report project enactment (see Section 4.2).

Analysis of results • Collect lessons learned • Identify challenges (see Section 4.3).

Engineering cycle (performed in CaaS project) Research cycle (reported in this paper)

Research Capability-driven development of a SOA platform: a case study

This paper


a case study



Agenda


Company Project Capability modelling

Capability-driven development of a SOA platform: a case study Case study



Current situa;on

200 services 250 municipali;es 1.000.000 Spanish ci;zens Complex and dynamic context Customisa;on at code level

Main challenges

Model the desired capabili;es Model impact of context Towards context-‐aware, self-‐adap;ve plaIorm


People involved

Public Sector and R&D Manager Business Consultant Technological Consultant 4 researchers from UPV and RTU


Capacity: IT infrastructure, monitoring tool, developers, technicians. Ability: being able to deploy a maintenance portal. Enterprise: everis Goal: keep services available despite platform errors. Context: loss of connectivity w. other subsystems. Goal KPI: time service available / time error in platform

Capacity: swimming pool facilities, swimming coaches. Ability: offer the electronic service to request swimming course registration. Enterprise: municipality Goal: reduce cost of service provision. Context: amount of requests. Goal KPI: amount of money saved


everis staff originally created 8 distinct definitions

issues related to

Perspective Granularity

everis

municipality offer the electronic service

deploy a maintenance portal


LEG

END

ACTIVITYPRECEDENCE RELATIONSHIP

GOAL MODELLING KPI SPECIFICATION

STAKEHOLDER MODELLING

CONCEPT MODELLING

CAPABILITY MODELLING

IT ARCHITECTURE DESIGN DRAFT

CONTEXT MODELLING

BUSINESS PROCESS MODELING

PATTERNS MODELLING OR

SELECTION

Then researchers entered the scene and, together, we followed this process


G-13: TO IDENTIFY CHANGE PATTERNS

G-14: TO USE PATTERNS

G-15: TO MONITOR SERVICE DATA USAGE

IN THE PLATFORM

G-17: TO AUTOMATE RESPONSE CREATION

G-16: TO ENSURE INTEGRATION WITH OTHER SYSTEMS

G-12: TO KEEP SERVICES UP TO

CURRENT REQUIREMENTS

G-18: TO ENSURE CONTEXT AWARENESS DURING THE RUN TIME

G-11: TO ENSURE COMPLIANCE WITH

LEGAL FRAMEWORKG-10: PROVIDE ADEQUATE IT

INFRASTRUCTURE

G-1: TO IMPROVE THE USAGE OF SERVICES

G-2: TO PROVIDE SMART SERVICES

G-3: TO STREAMLINE SERVICE ACTIVATION

G-4: TO PROVIDE A CHIOCE BETWEEN AUTOMATED AND

FACE-TO-FACE SERVICES

G-5: TO PROMOTE SERVICE USAGE IN SERVICE CATALOG

G-6: TO BE ABLE TO IDENTIFY SERVICE

CHANGES IN ADVANCE

G-7: TO IDENTIFY REASONS FOR

CHANGES IN USAGE

G-8: TO SUPPORT THE CHANGE

MANAGEMENT PROCESS

G-9: TO USE EXTERNAL DATA SOURCES TO IDENTIFY THE NEED FOR THE SERVICES

SUPPORTS SUPPORTS SUPPORTS SUPPORTSSUPPORTS

SUPPORTS

SUPPORTS SUPPORTSSUPPORTS

SUPPORTS SUPPORTS

SUPPORTS

SUPPORTS

SUPPORTS

SUPPORTS

SUPPORTS

SUPPORTS

Goal model

Strategic goals Business goals

Technical goals

Design-time goals Run-time goals


G-13: TO IDENTIFY CHANGE PATTERNS

G-14: TO USE PATTERNS

G-15: TO MONITOR SERVICE DATA USAGE

IN THE PLATFORM

G-17: TO AUTOMATE RESPONSE CREATION

G-16: TO ENSURE INTEGRATION WITH OTHER SYSTEMS

G-12: TO KEEP SERVICES UP TO

CURRENT REQUIREMENTS

G-18: TO ENSURE CONTEXT AWARENESS DURING THE RUN TIME

G-11: TO ENSURE COMPLIANCE WITH

LEGAL FRAMEWORKG-10: PROVIDE ADEQUATE IT

INFRASTRUCTURE

G-1: TO IMPROVE THE USAGE OF SERVICES

G-2: TO PROVIDE SMART SERVICES

G-3: TO STREAMLINE SERVICE ACTIVATION

G-4: TO PROVIDE A CHIOCE BETWEEN AUTOMATED AND

FACE-TO-FACE SERVICES

G-5: TO PROMOTE SERVICE USAGE IN SERVICE CATALOG

G-6: TO BE ABLE TO IDENTIFY SERVICE

CHANGES IN ADVANCE

G-7: TO IDENTIFY REASONS FOR

CHANGES IN USAGE

G-8: TO SUPPORT THE CHANGE

MANAGEMENT PROCESS

G-9: TO USE EXTERNAL DATA SOURCES TO IDENTIFY THE NEED FOR THE SERVICES

SUPPORTS SUPPORTS SUPPORTS SUPPORTSSUPPORTS

SUPPORTS

SUPPORTS SUPPORTSSUPPORTS

SUPPORTS SUPPORTS

SUPPORTS

SUPPORTS

SUPPORTS

SUPPORTS

SUPPORTS

SUPPORTS

Goal model Goal templates

G-1. To improve the usage of the services Currently, EVR provides up to 200 services for 250 municipalities, but 100 are in active use and not in all municipalities. The goal is to improve the usage of the services. Category: Strategic goal Stakeholder: S-3. EVR KPIs: Percentage of users consuming the services (target=25%)

Percentage of completed service actions / submissions (target=90%)

G-5. To promote service usage in service catalog EVR provides a huge amount of services in SOA platform service catalog. Each service must contain sufficient up-to-date information to help to the end users find and use the services. Category: Strategic goal Stakeholder: S-3. EVR, S-4. Municipality KPIs: Frequency of catalog update

Number of services in catalog

Stakeholders model


Concepts model


Context model


Context model

Capability-driven development of a SOA platform: a case study Case study Context element specifica;on

Element Values Measur. prop. Mapping rules

Municipality size {Small, Medium, Large}

NC = Number of citizens

If NC <10000 then ‘small’ If 10000 <= NC < 30000 then ‘medium’ If NC >= 30000 then ‘large’

Service usage in other municipalities

{High, Medium, Low}

PMUS = Percentage of municipalities using the service

If PMUS < 20%, then ‘low’ If 20% <= PMUS < 50% then ‘medium’ If PMUS >= 50% then ‘high’

Type of highlighting

{Automatic, Manual}

NA NA (unknown at design time)

: CONTEXT INDICATOR SP : KPI TO PROMOTE THE USAGE OF THE

SERVICES : GOAL

SP : CONTEXT SET SERVICE PROMOTION (SP) : CAPABILITY

PROMOTION OF THE SERVICE : PROCESS

HIGHLIGHT THE SERVICE : PATTERN

HIGHLIGHT THE SERVICE : PROCESS

VARIANT

INFORM MUNICIPALITIES WITH

SIMILAR PROFILE ABOUT HIGHLY USED SERVICES : PATTERN

INFORM MUNICIPALITIES WITH

SIMILAR PROFILE ABOUT HIGHLY USED SERVICES : PROCESS

VARIANT


Capability model


Process model

"GROUP" PATTERN

"GROUP" COMPOSITE STRUCTURE PROCESS VARIANT

"GROUP" COMPOSITE STRUCTURE PROCESS VARIANT

"GROUP" PATTERN

USAGE OF THE SERVICE IN OTHER

MUNICIPALITIES: CONTEXT ELEMENT

AMOUNT OF ACTIONS / SUBMISSIONS PER

MONTH: CONTEXT ELEMENT

FEEDBACK IN SOCIAL NETWORKS:

CONTEXT ELEMENT

MASSIVE MAILING TO OTHER

MUNICIPALITIES WITH SIMILAR PROFILE

CONTACT PMO FOR SERVICE

DISSEMINATION

RUN HIGHLIGHTING PROCEDURE ONCE EVERY 72 HOURS

RUN HIGHLIGHTING PROCEDURE ONCE EVERY 24 HOURS

HIGHLIGHT THE SERVICE

CHECK THE AMOUNT OF AVAILABLE SERVICES IN

MUNICIPALITY'S HOMEPAGE

INFORM OTHER MUNICIPALITIES

ABOUT HIGHLY USED SERVICES

+

HIGHLIGHT SERVICE THAT IS HIGHLY

USED IN SIMILAR MUNICIPALITY

+



a case study



Agenda


Capability-driven development of a SOA platform: a case study Lessons learned

Motivation to adopt CDD everis is highly motivated due to: •  Perception of current limitations in the platform. •  Expectations of new features that the CDD methodology

and tools can enable (self-adaptation).


Modelling issues

Difficulties with perspective and granularity.

CAPABILITY

PROBLEM

SOLUTION

GOAL CONTEXT

RESOURCES PROCESSES

INFORMATION TECHNOLOGY

Capacity: Ability: Enterprise: Goal: Context: Goal KPI:

Capability definition template


Modelling issues

Difficulties with perspective and granularity.

We envision the need of relationships among capabilities:

C1MUNICIPALITY

OWNER

EVERISC2

OWNER

ENABLER

SOA1

SOA1.1 SOA1.2 SOA1.3

<

C_SLA1

C_SLA2

<

C_SLA3

Perspective Refinement Context or quality levels


Modelling issues

How to start capability modelling.

LEG

END

ACTIVITYPRECEDENCE RELATIONSHIP

GOAL MODELLING KPI SPECIFICATION

STAKEHOLDER MODELLING

CONCEPT MODELLING

CAPABILITY MODELLING

IT ARCHITECTURE DESIGN DRAFT

CONTEXT MODELLING

BUSINESS PROCESS MODELING

PATTERNS MODELLING OR

SELECTION

Who should be involved in modelling.


Modelling issues

What modelling notations to use. How to elicit and model relevant context elements.


Modelling issues

What modelling notations to use. How to elicit and model relevant context elements.


Modelling issues

How to identify and model variability

1

2 3

4

5

6

1

2 3

4

7

8

6

1

2 3

4

9

10 11

6

+

+

(A or B) and C D and E F and G and H

1

2 3

4

x

5 7

8

9

10 11

6

+

+x

(A or B) and C

D and E

F and G and H


Modelling issues


1

2 3

4

6

PRODUCT READY TO

BE 6-ED

PRODUCT JUST 4-ED

OPT

ION

1

INSERTSTART

5

END

START PRODUCT JUST 4-ED

OPT

ION

2

INSERT

START

7

END


8O

PTIO

N 3

INSERT

START

END


END PRODUCT JUST 4-ED

9

10 11

+

+



(A or B) and C

D and E

F and G and H


Modelling issues


END PRODUCT

JUST 4-ED


1

2 3

4

6

PLAC

EMEN

T

5 7

8

9

10 11

+

+

PLAC

EMEN

T

REPL

ACEM

ENT

1

REPL

ACEM

ENT

2

REPL

ACEM

ENT

3

(A or B) and C D and E F and G and H


a case study



Agenda


Capability-driven development of a SOA platform: a case study Conclusion

Summary

•  Capability modelling is central to capability-driven �� development (CDD).

•  Case study research on the industrial application of CDD to �� a SOA platform project

•  CDD facilitates a systematic analysis of organisational needs �� and designing a context-aware IT solution.

•  The CDD methodology still needs improvement.

Future work

•  Method: guidelines for goal-first capability modelling, variability modelling, context elicitation and modelling, ��run-time adjustment…

•  Validation: controlled experiment, case studies

Thanks!

Software

2014 Asdenca - Capability-driven development of a soa platform, a case study