Infosys Experience with a Utility

Company

Objective

2

• Drive the future integration strategy for API

• Drive the API adoption with enterprise and develop highly agile platforms for future

business needs

• Align with market trends and built a fit-for purpose platform for the enterprise needs

• Enforce self service and lean governance

Future Integration Capabilities – Hybrid Integration Platforms

3

Internal

Applications

AP

I M

anagem

ent

ESB

MFT

Mobile App

External

Systems

Micro Service

M MM

SaaS AppsiPaaS

IOT

PLA

TF

OR

M

Device

Sensors

Things/

Devices

EMS

VMS

MWM

Messaging

File

DW

DW

Channel App

ETL

Customer

Portal

Event

Streaming

Event

Processing

Cloud

Adapter

ExternalInternal

Developer Portal

CCB

MDM

ADMS

MAXIMO

IVR

PeopleSoft

B2B

Our Approach towards a Hybrid Integration Platform for a Utility Company

4

Built a Reference Architecture for

Next Gen Integration

Build an practical Governance Model

Identify the Platforms based on Integration

needs

Approach for Reference Architecture

5

A workshop based collaborative approach to

• Define Principals that are based on key decisions

• Define the use cases for future integration

• Define Patterns from use cases

• Identify the platforms from the patterns

Reference Architecture - Guiding Principles

6

Built a Reference

Architecture for the NextGenIntegration

Build an practical

Governance Model

Identify the Platforms based on

Integration needs

Reference Architecture - Use case to Patterns

7

Built a Reference

Architecture for the NextGenIntegration

Build an practical

Governance Model

Identify the Platforms based on

Integration needs

Reference Architecture - Sample Patterns Defined

8

Usage Criterion Considerations

• API is identified as Enterprise API

• Provider is not able to expose the API with SOAP or RESTful end point

• Provider API data model requires enrichment to standardize as per SDM guidelines

• Provider API has the PII data that requires filtering/masking

• API Consumers are internal applications and/or external partners

• Proxy service to be exposed for external consumer

• Wrapper service required with RESTful end point for the existing web service SOAP end point

• Orchestration of multiple ESB Services /Provider APIs is required

• Provider API requires throttling or usage based authorization

• Provider data model is transformed into

API data model over ESB

• ESB does the validation, enrichment and

any maksing/filtering of PII data

• Protocol conversion (SOAP -> REST)

happens on API or ESB Platform

Built a Reference

Architecture for the NextGenIntegration

Build an practical

Governance Model

Identify the Platforms based on

Integration needs

Reference Architecture - Integration Strategy - Security

9

Communication Pattern Auth entication Transport Security Data Security

API OAuth2.0 SSL (HTTPS) PII Data should be handled as per security guidelines

Web Services Basic Auth SSL (HTTPS) PII Data should be handled as per security guidelines

XML/HTTP, HTTP Basic Auth SSL (HTTPS) PII Data should be handled as per security guidelines

JMS / XML User Auth SSL PII Data should be handled as per security guidelines

File Share A2A User Auth SFTP Folder level encryption* (E.g. Vormetric)

File Share B2B User Auth SFTPPGP encryption

Folder level encryption*(E.g. Vormetric)

Built a Reference

Architecture for

the NextGen

Integration

Build an practical

Governance Model

Identify the Platforms based on Integration

needs

Reference Architecture - Integration Strategy - SDM

10

• An API will be defined based on Domain capability and the subject area

• All published API in the company will be Open API 2.0 Specification compliant

• These Open APIs will use a service data model

• The Data Stewart from each business domain will own the service data model for the APIs within the domain

• When a project identifies and develop an API then the Data Stewart from that business domain will be engaged

to define the Service data model for the API

• Attribute nomenclature of the Service data model will be maintained by data Stewart

Built a Reference

Architecture for

the NextGen

Integration

Build an practical

Governance Model

Identify the Platforms based on Integration

needs

Practical Governance Process Promoting Self Service for Architects

11

Built a Reference

Architecture for

the NextGen

Integration

Build an practical

Governance Model

Identify the Platforms based on Integration

needs

Identify Hybrid Integration Patterns based on enterprise needs

12

Built a Reference

Architecture for

the NextGen

Integration

Build an practical

Governance Model

Identify the Platforms based on Integration

needs

How TIBCO helped

13

Integration Platform Covers in the Document

Process Orchestrator TIBCO BW, TIBCO EMS, TIBCO Hawk

API Management Under Evaluation

Integration Container TIBCO Business Works CE

B2B TIBCO Business Connect

ETL ETL

Built a Reference

Architecture for

the NextGen

Integration

Build an practical

Governance Model

Identify the Platforms based on Integration

needs

What we have learned

14

• Enterprise goal is to build E2E monitoring system to track transactions at any point of

failure. Current technology landscape is does not facilitate seamless E2E due to hybrid

integration strategy

• Planned to develop a API Development portal that also supports the Service Repository.

This will be a custom solution (API product selection is under consideration)

• Microservices platform is provided in the hybrid architecture platform. The ownership of the

microservices needs careful consideration

API Use Case

14

• Approved OTS / Customer to Internal: Any consumer facing applications consume data over ESB (TIBCO

BW/EMS) in a SOAP format. Its an enterprise goal to consume this data as RESTful API using API gateway

• External Mobile App to Internal: Replacing mobile first application that resides in the APS network with a unified

API gateway which standard security, throttle and developer portal capabilities to expose business functions as

RESTful APIs

• Approved OTS /Customer Internal/ External Mobile App to SaaS: Any provider SaaS application will expose

their business functions as RESTful APIs. Any.com, Any mobile app and any application residing out of enterprise

domain will access the data using API gateway. The transaction will not cross enterprise boundaries

• SaaS to SaaS: Any SaaS to SaaS communication will not cross enterprise boundaries and will be routed through an

API gateway in cloud

© 2017 Infosys Limited, Bengaluru, India. All Rights Reserved. Infosys believes the information in this document is accurate as of its publication date; such information is subject to change without notice. Infosys acknowledges the proprietary rights of

other companies to the trademarks, product names and such other intellectual property rights mentioned in this document. Except as expressly permitted, neither this documentation nor any part of it may be reproduced, stored in a retrieval system, or

transmitted in any form or by any means, electronic, mechanical, printing, photocopying, recording or otherwise, without the prior permission of Infosys Limited and/ or any named intellectual property rights holders under this document.

Thank You