e metrics - isbsg · separation of presentation (front-end) and processing (back-end) functions...

© 2020 NTT DATA Corporation

Information Type:

Company Name: NTT DATA Italia S.p.A

Information Owner:

Measuring microservice architectures and cloud applicationsFunction Point Analysis and SNAP applied to contemporary architectures

CONFIDENTIAL

August 2020

NTTDATA Italia

Ena

ble

r‘S

OF

TW

AR

E M

ET

RIC

S’

Marcello Sgamma

2© 2020 NTT DATA Corporation

I. Evolution of application architectures

II. What is a boundary?

III. Measuring Service Oriented architectures

IV. Measuring microservice architectures

V. Application contexts in cloud enviroments

VI. Functional measurement in the cloud

VII. Conclusions

AGENDA

Ch

am

pio

ns ‘S

OF

TW

AR

E M

ET

RIC

S’

© 2020 NTT DATA Corporation 3

Evolution of architectures


Boundary definition

Defining a «loose» boundary prevents a correct measure of software complexityand value

On the other side, with too many boundaries FP count may increase too much(basically because of multiple counting of data functions) thus underminingmeasurement precision.

Granularity of Base Functional size Components (BFC)

Data functions (ILF, EIF): functional modeling of data functions should settlebetween the detailed level of DB tables structure and the abstraction level of high level business entities, keeping into account user perception. E.g.: Relation and extension tables are usually RETs of some ILF/EIF

Transaction functions or Elementary Processes (EI, EQ, EO): The smallest units of activity that are meaningful to the user(s); they must be

autonomous and leave the system in a consistent state Their primary intent mark their differences E.g.: different steps of a workflow may be portions of a single EP

Critical activities when measuring applications


When measuring advanced contemporary architectures, we need to

identify a software measurement approach that:

May pay for higher development costs

Without losing logical correctness of functional measurement

Basic principles:

Defining boundaries which correctly represent business needs

Identifying EPs with a granularity coherent with business needs

Measuring evolution


The boundary is a conceptual interface between the software under study and its

users.

Also referred to as application boundary, it defines what is external to the application;

indicates the border between the software being measured and the user;

acts as a ‘membrane’ through which data processed by transactions passes into and out from

the application;

encloses the logical data maintained by the application;

assists in identifying the logical data referenced by but not maintained within this application ;

is dependent on the user’s external business view of the application. It is

independent of technical and/or implementation considerations .

The boundary is determined based on the user's view . The focus is on what the

user can understand and describe.

The boundary between related applications is based on separate functional areas as

seen by the user, not on technical considerations.

[CPM 4.3.1, part 2, pp. 5-4, 5-5]

Boundaries in Function Point Analysis


From the theoretical point of

view, technological evolution

should not influence

functional measurement for

an application.

When defining the same

boundary and identifying the

same user functions within an

application, functional

measurement cannot change.

Evolution of architectures

could be a technical aspect,

unless…


In parallel with evolution of architectures, also user requirement have evolved, digging

from the functional level into technical and technological aspects.

Architectural and technological aspects, which formerly were designers responsibility

and suppliers assets (and therefore where out of scope for FPA, as technical ways to

deliver a function), have started to appear in bids and contracts:

• Initially service-oriented applications (SOA), allowing component reuse and reducing

development and maintenance costs

• Then microservice architectures, which add to stated SOA advantages higher

scalability and flexibility in technical constraints

Therefore we are facing a change in:

• Level of acknowledgement of application functions

• User view of the application

User requirements evolution


Typical situations can be:

Separation of presentation (Front-End) and

processing (Back-End) functions

Multi-channel and multi-supplier Front-End

Back-End environement with heterogeneous

technologies and suppliers

Therefore boundaries must be re-defined, for both

actors’ advantage, even if for different reasons

And even measurement granularity can change…

Measuring SOA


«monolithic» measurement

SOA example

2 disposal functions sharing user status checks

SOA measurement

Service 1

activation

Description Oper. Type Compl. FP

Service 1 activation ADD EI Avg 4


Total 8

User status

query

Service 2

activation

User status

query




User status query ADD EQ Avg 4

Total 12

Service 1

activation

Service 2

activation

User status

query


When measuring a SOA architecture, an accurate and correct definition of boundaries

is fundamental. Where «correct» means:

Methodologically correct: if existence of a BE environment and of one or more FE

environments is stated and organic to business needs, it can’t be ignored, just

because of boundary definition

Correct with respect to business view: 3-tier implementation (presentation,

business logic, and DB) for an application is nowadays not enough to define a

boundary between presentation and business logic

Acknowledgement of FE and BE boundaries brings decomposition of any user function

into two EPs: one in the FE boundary and one in the BE one

Business logic decomposition into services may lead to identification of more EPs

than the classic approach, as a consequence of user’s awareness of component

services.

Measuring a Service Oriented Architecture


Each component service within a microservice

architecture may be developed, deployed, managed and

scaled without influence on other component services.

Services should not share any code or implementation

with other services.

Persistent data for a microservice, which actually are

part of its implementation, should be private and

segregated within the microservice.

Any communication between microservices occurs

through well defined APIs.

Therefore:

Migrating from SOA to microservices, some new

Elementary Processes may be identified.

Data functions should be segregated and associated to

microservices

Measuring a microservice architecture


Microservice example


Microservice-boundary measurement





Total 12

Disposal actions

Microservice

User status

Microservice

User status

query

Service 1

activation

Service 2

activation

Single boundary measurement





Total 12

Disposal actions

Microservice

User status

Microservice

User status

query

Service 1

activation

Service 2

activation


Microservice example (with shared data functions)



Disposal actions

Microservice

User status

Microservice

User status

query

Service 1

activation

Service 2

activation


Disposal actions

Microservice

User status

Microservice

User status

query

Service 1

activation

Service 2

activation

Descrizione Oper. Tipo Compl. FP




Customers ADD ILF Low 7

Totale 19

CustomersCustomers

Descrizione Oper. Tipo Compl. FP




Customers ADD ILF Low 7

Customers@DispAct ADD EIF Low 5

Totale 24


There are three basic principles for microservice design:

Single purpose: Each service should entirely cover a single purpose.

Loose coupling: Services are unaware of other services. Communication between

services should occur only through public interfaces.

High level cohesion: Each service contains all related behaviours and data.

As a consequence of data segregation (cohesion), considering multiple boundaries in a

microservice architecture should have mimimum impact on measurement, as data

functions should be partitioned at microservice level.

Furthermore, simple application of correct guidelines for microservice design should

enforce a correct identification of BFCs with a granularity level appropriate for a correct

functional measurement:

Data functions: taken from data structures read/modified by each microservice

Elementary Processes: each distinct operation of each microservice

Therefore, from the methodological point of view, the best choice seems defining a

boundary for each microservice. But reality is ofeten somewhat different from theory…

Measuring a microservice architecture


Application contexts in a cloud environement

The 3 main cloud service

models (IaaS, PaaS and SaaS)

often cohexist in complex cloud

architectures.

FPA principles and measument

may apply also to cloud

environments, with obvious

different cost values applied to

different service models.

In the cloud, fee-based pricing

is used for FP measured

services.


Pricing a cloud application


Application context:

Informative and dispositive app

designed in microservices and

developed on cloud platform

HEROKU.

Structure: 45 operations, with

41 new, grouped in 10

microservices.

External interfaces: 24

services from legacy systems

may be invoked by operations.

Microservices measurement example (clean PaaS solution)

Microservice Operationsauthentication-service 6bill-service 4dispositive-service 2feintegration-service 5other-service 3profile-service 4pushnotification-service 4supply-service 5utility-service 7version-service 1

41


Context: ILFs within the

application and EIFs

corresponding to legacy methods

are clearly indentified


BFC L M H Tot

EI 5 4 7 16

EQ 7 8 9 24

EO 1 1

ILF 20 20

EIF 24 24


BFC L M H Tot

EI 5 4 7 16

EQ 7 8 9 24

EO 1 1

ILF 22 22

EIF 47 47

Context: EPs are the same; we

count 2 more ILFs (shared

between microservices), and

replication of EIFs due to poor

segregation



Single boundary

FPs from EPs: 187 FPs from data: 256 FPs in total: 443

Comparing measurements

Microservice boundaries

FPs from EPs: 187 FPs from data: 389 FPs in total: 576

We note that

EPs do not change, as expected in a microservice architecture There is an increase of 50% in FPs coming from data functions (about

30% of application size) due to poor data segregation By grouping microservices in congruent «service contexts», driven by

domain knowledge and data sharing, a better funcional modeling (and measure) could be obtained


Application context: ServiceNow suite in HR application, interfacing

customer’s legacy systems.

Scope: redefinition of 3 internal workflows, in term of user stories.

Sw impacts:

Modification of native steps within the ServiceNow workflow addinginterface with legacy systems

Definition of new specific workflow steps Definition of new data structures and modification of existing ones

Sizing: using classic FPA is OK for measuring complexity (and effort).

Measuring in mixed PaaS/SaaS context: example 1


Application context : ServiceNow suitein IT operation context.

Scope: custumization of a trouble ticketing system to meet customer’s

needs.

SW Impacts:

Custom data entity added to suite data model (a new dimension for tickets’context)

Configuration of suite functionalities

Sizing:

Almost no functional impacts (1 ILF, some modified web form). Most of activities in data loading, product configuration and graphics need for non-functional sizing (maybe SNAP?)

Measuring in mixed PaaS/SaaS context: example 2


Guidelines for microservice measurement obviously apply also when microservices are

deployed in the cloud. Some additional advices may be:

Apply methodology when defining purpose and scope of measurement

Boundaries and pricing rates are key aspects

Some tips for boundary definition in microservice contexts:

The microservice approach eases Elementary Processes identification and makes them almost independent from boundary definition

A single boundary could not model correctly the higher complexity needed for design and development of a microservice solution

Microservice boundaries in situations with poor data segregation may lead to excess measurement

Grouping microservices based on data sharing could be a more suitable approach, when agreed with the customer view.

Some advices for measuring the cloud


Business functions measurements should be grouped for

Business functions to be customized Business functions to be configured Business functions to be developed

FPA is (the only methodology) valid in all cloud service models, but there is wide

variability in pricing rates (and few experiences too…).

In SaaS contexts, where most activities are configuration activities or anyway

answer non-functional requirements, a measurement methodology for non-

functional user requirements should be adopted. IFPUG SNAP is still young and

lacks widespread application, but could help to size complexity and estimate efforts

Some advices for measuring the cloud

27© 2020 NTT DATA Corporation

http://www.ifpug.org/Metric Views/MVBuglione.pdf

EFFORT DI PROGETTO UNA VISIONE GLOBALE

Come poter valutare e stimare effort e costi PRIMA

di realizzare il software?
http://www.ifpug.org/Metric%20Views/MVBuglione.pdf

e metrics - isbsg · separation of presentation (front-end) and processing (back-end) functions...

Documents