Delighting Customers with an API First Approach at Proximus

Proximus, the largest telecommunications provider in Belgium, has been around since 1930. At present, Proximus provides internet, TV, telephone, and network-based ICT services. Their brand portfolio includes Scarlet, NBRACE, tango, ClearMedia, TeleSign, Davinsi Labs, telindus, BEMOBILE, and bics. Collectively, these brands have presence beyond Europe – in the Middle East, Americas, Africa, and APAC.

APIs Are Great – Again

Proximus has 2,000 to 3,000 applicators in the entire organization, integrating internally and externally with partners, competitors, and customers. Most importantly, these integrations have to be managed. The scenario that would result in not doing so is endless difficulty and inconvenience. A decade ago, Proximus designed their architecture for managing commodity services such as authentication, authorization, routing, and monitoring. So far, so good.

Change came in the form of agile business transformation. By becoming more agile, they were looking to deliver services faster, of better quality, and at lower cost. Proximus achieved business agility by building functionality shaped building blocks that are re-usable and loosely coupled. These building blocks are used to provide their digital solutions, all at lower costs and higher quality. Agile transformation has been made possible by WSO2 API Manager, which supports any spectrum of the API lifecycle, and WSO2 Identity Server, a holistic identity and access management (IAM) solution. Both are open source.

“We had to rethink what we were doing and essentially look at making APIs great again,” says Sean Kelly, an enterprise architect at Proximus. They’ve already worked with APIs, mainly to offer services – but agile transformation means approaching everything differently. This began by bringing together architectural domains that are well-defined and separate. For one, there was a functional domain which operated on specific blocks of functionalities (such as customer address management). Then there was an important security domain that is responsible concerns such as GDPR compliance. The application domain handles patching, upgrading, migrations, and such. And finally, the infrastructure domain is needed for deployment.

Functional Domain in Detail

Sean explains the new approach at Proximus by using the functional domain as an example. The team at Proximus documented all business capabilities and they first defined the characteristics of a capability. For starters, a capability must be a subject matter expert i.e. a customer address management capability is the owner and master of this specific block of data. This capability is the single source of data for the particular function, with a specific team attached to it. Furthermore, business capabilities are also mutually exclusive – unique, but independent, self-contained, and well defined.

The implementation of this new API-first approach happened in a very structured manner. APIs at Proximus are lightweight and powerful, with simpler life cycles and release cycles. Product teams were empowered and the API management platform is more agile. Although the API management platform is a self-service one, there are certain controls in place. Collaboration plays a big role too. Given the number of architectural domains, collaboration could be a challenge and it required a shift in mindset across the organization.

Organizational Change from Service Orientation (SOA) to Resource-Based Architecture

Proximus adopted the Bimodal practice to deal with organizational change. Introduced by Gartner, Bimodal refers to the strategy of coping with change and it’s comprised of two modes (modes 1 and 2). As per Gartner’s definition, these 2 modes are cycles, and not separate groups or departments in the company. “Mode 1 is the marathon runner, that is, it refers to APIs that perform core business functions. Mode 2 is more like a sprinter. These are the APIs that respond to the environment, are closer to your customers, more agile, and typically more disruptive,” Sean explains. At Proximus, mode 1 is applied to internal APIs and existing SOA services. Mode 2 is applied to external APIs and this is where they publish their digital products, with a strong focus on security.

Apart from the Bimodal practice, Proximus has also adopted several principles. There’s no domain dumping model at Proximus, and they use concepts that are known and understood within the organization. They design for loose coupling, as vendor-neutral APIs are preferred and it allows them to change one component to another with minimal impact. Proximus also use industry standards such as O-Auth2, XACML, SID, JWTE, etc. Another is the use of smart endpoints and dumb pipes, which is to avoid business logic in a centralized middleware. Security is coded, rather than configured. As such, the code is typically only written once and then validated by security, making it easier to manage this process as well. Proximus also do not use the latest version of a particular technology offered – they prefer to trail behind the bleeding edge, as they’re on the lookout for the first round of patches and use the functionality with greater confidence at a later time. And finally, Proximus only builds components or purchases software that is cloud native.

Delighting Customers

The team at Proximus are satisfied with their API first approach and the resulting API marketplace. “We’re focusing on delighting our customers, delivering value, and doing all this at a lower cost. We use WSO2 to do what they do best. For us, WSO2 is an API management platform and we let them handle that while we focus on the business,” says Sean. As with any innovative business, there are more changes afoot at Proximus and they’re looking to take WSO2 along with them as their business evolves.

Watch Sean’s presentation for more information about the transformation at Proximus.

Check out our product pages for WSO2 API Manager and WSO2 Identity Server to find out how you can use these products in your enterprise.

The API-driven World: WSO2 Integration Summit is Coming to a City Near You!

Starting in March, the WSO2 team, our partners, and I will be hitting the road for the 2019 WSO2 Integration Summit world tour. The 2018 Summit series was our biggest yet, featuring customer success stories from enterprises that have used our technology to fulfill digital transformation strategies and create innovative experiences for their customers. Refusing to sit back and relax, we’re making the 2019 Summits even better. We will be visiting at least 24 cities in 20 countries and 6 continents to show how you can achieve API-driven integration agility.

We are scaling our efforts by collaborating with our partners on each of our summits. We started this year by inviting all our partners for WSO2 Sales Bootcamp. For the first time ever, we had partners from all around the world participating in the 2019 kickoff alongside our own teams. Insights were gained, strategies were discussed, plans were made, and the summit tour was born. Because of our partners’ global presence, we are able to reach six of the seven continents (the penguins in Antarctica didn’t show much interest in WSO2!).

Group picture from Sales Bootcamp 2019

Summit Theme: The API-driven World

APIs are touching every facet of our society and the underlying trends are going to generate nearly 1 billion APIs in the coming years. All digital transformation depend on APIs and integration technologies underpin their evolution. Each WSO2 Summit will comprise a full day of vision and practical use cases focused on integrating a world of disaggregated APIs, cloud services, and data. We will discuss topics such as transforming integration projects from waterfall to agile, by moving from the centralized model to a decentralized architecture and methodology; combining enterprise integration, API management, and identity solutions; writing microservices that integrate APIs using Ballerina; and using open source technology for greater customization and flexibility. The summits will also feature guest speakers from digital-native organizations who will talk candidly about their API-driven transformations.

We’ll show you how to navigate current trends and use them to deliver innovation and new opportunities. Listen to visionary keynotes by WSO2 senior leadership, meet and network with industry experts and others who are striving to solve similar enterprise problems, and learn how integration agility could help with maximizing revenue and productivity. Join our interactive discussions to empower your team and stay one step ahead of evolving business needs.

While the the underlying themes of each summit remains the same, the agenda differs from location to location. The interactive sessions are tailored to each region, helping you gain relevant information on what matters to you and your enterprise. From open banking to retail and healthcare, our plan is to cover it all.

WSO2 Integration Summit 2019 global locations

If you are a customer or a community user and would like to speak at one of the summits, please let us know, as we have a limited number of spots still available. Get in touch with us at cfp@wso2.com.

I look forward to seeing you soon.

Space is limited, so save your spot today.

Follow @wso2 on Twitter to get the latest updates. We are using the #WSO2Summit hashtag.

Eagle Technology Group: Applying Agile Software Development Principles to WSO2 Products

Eagle TG is an information technology engineering and integration company based in New Braunfels, Texas. Owned by the Native American Modoc Tribe of Miami, Oklahoma, Eagle TG offers enterprise architecture, virtualization, and data center solutions. They are also a WSO2 Preferred Partner and carry an average of 18+ years of technology expertise per employee.

At WSO2Con USA 2018, Neil Custer, a senior enterprise systems engineer at EagleTG explored their agile process-based configuration management tool for WSO2 products, which they deploy and maintain for one of its largest customers — the headquarters of a branch of the US Department of Defense (DoD). Eagle TG harnessed its considerable in-house software development expertise to develop this new product.

The goal of the new configuration management product is to maintain the consistency of configurable items that affect the performance, functional capabilities and physical attributes of WSO2 products while taking into account operational concerns.

Managing Configurations Before WSO2 Update Manager (WUM)

The release of the WSO2 Update Manager (WUM) in late 2016, had a considerable impact on the way EagleTG did its configuration management. WUM is a simple command line tool that connects to the WSO2 Update service, determines which updates are new and relevant, and downloads them.

Prior to the arrival of WUM, Eagle TG used a painstaking manual process to capture configuration management changes. Using open source tools, EagleTG would evaluate the new out-of-the-box WSO2 product against what they had previously configured. They would then manually update a text file with all of the items that were changing.

The Impact of WUM

So, how did the release of WUM lead to Eagle TG rethinking its configuration management protocols?

WUM meant Eagle TG could no longer use an update patch and simply overlay a couple of files, and perhaps change a parameter or two in a configuration file to enable the product to work in both their lab and in their customer’s environment. With WUM, Eagle TG’s developers needed to wipe out the entire implementation of that product instance with the existing configuration, and do a complete reinstall of the product from scratch. They then had to test the new products in multiple environments.

Doing this with about 6 different WSO2 products was challenging, to say the least. Especially since many of their DoD customers worked in isolated environments where access to the Internet was not a given, which meant that they couldn’t use the Puppet scripts provided by WSO2 to automate the configuration process.

The New and Improved Configuration Management System

Eagle TG’s software and systems engineers realized they would need to rethink their configuration management process if they were to keep providing topnotch services and operations support to their DoD customer. After consulting the team at WSO2 they realized that they needed to script everything they can. The answer lay in harnessing the rich and varied software background of its personnel and recasting configuration management as software development. In other words, Eagle TG’s team decided to treat the items it had to configure in order to deploy a product into specific functions as source-code.

A shared, central repository was created to hold the configurable items for each product. This allowed all team members an efficient way to access these configurable items, modify them, as needed, and to push them back into the repository where others could do the same. All changes are tracked centrally, making it easy for team members to see what has been changed, by whom, when and why. With a simple right click, the repository history is viewable, listing every change that has been made by any team member, along with the date and reason for the change.

Branching while testing is another attractive feature of the new configuration management process. For example, engineers are now able to make a side-line configuration change that might get implemented at a later time, by essentially parking it in the repository in a separate branch. Meanwhile, the main branch stays intact until it is time to merge with the secondary branch.

They were initially going to store the entire zip file of the product home folder in the repository but quickly realized this was not feasible because of the large file size and the multiple products and environments they had to store for. They kept the size of the repository manageable by keeping only the items it has customized in it. A separate folder within the repository for certificate key stores was also set up. Within each key stores folder, every WSO2 product has its own separate environment where the product is deployed.

A cron job was created to ensure updates run smoothly. Set up to run three times a week, this interrogates WUM for any updates to relevant WSO2 products it supports for its customer. If the answer is yes, the updates are automatically pulled to a staging area and an email alert is sent out to everyone on the team. Then the previous fully-configured product instance is backed up. Finally, the new product release is deployed using configuration items and fully tested for the required capabilities.

Because Eagle TG had a strong development background, they were able to follow Agile principles in their configuration as code approach. These include having a shared repository where developers can collaborate, using scripts for “self-installing”, and leveraging Jenkins for continuous integration. They have also adopted continuous delivery and are offering the product as a service on AWS cloud.

To help create their code-based configuration system, they built standardized WSO2 Node “Deployers” for each product in each environment. A deployer is a single consolidated, distributable, compressed file (.zip) that helps deploy the fully-configured updated products. It contains

  • The folder structure for enabling the fully-configured product deployment
  • A README.txt file outlining the basic environmental requirements for scripts
  • Script files for carrying out the product installation
  • Configurable items for the product
  • WSO2 Product Source

95% of the deployer consists of the WSO2 Product Source, which means they have a low overhead of just 5% that is actually stored in their repository.

The Advantages of Adopting Agile Principles for Product Updates

Although the process of converting their configuration management from manual to automatic through their Agile configuration as code approach has been a long journey, it has proved to be advantageous for Eagle TG in many aspects.

Versioning and traceability of changes: By storing configuration code in a version control system, EagleTG is now able to see who changed what, when and why, which makes it easy to analyze code differences between versions. It is also able to use branches to isolate changes under consideration without affecting the main source code.

Increased security: Running the product as a service allows it to run in its own space with a no log-on user in the Linux environment, making it a lot harder to hack into.

Overall, using software principles in configuration management has allowed EagleTG to streamline processes and take advantage of automation. Each discrete activity is self-documenting, making the process vastly superior to the previously employed manual process that was constantly on the verge of having outdated changes in configuration.

New Businesses Opportunities

This system was among the first to get a fully operational suite migrated to Eagle TG’s DoD client’s managed cloud platform. Eagle TG, together with their client’s engineering team, helped change the DoD branch’s internal processes which made it a lot easier for other programs to migrate to the cloud.

As a technology services provider, Eagle TG’s early success also led to more opportunities such as the one to provide the DoD branch with an updated identity and access management solution. They were also able to show the many advantages of open source software which is yet to be realized in many US Government agencies that opt to go for commercial proprietary software.

Watch Neil’s session at WSO2Con USA 2018 here.

Evolution of Nations Trust Bank’s Open Banking Story

Established in 1999, Nations Trust Bank (NTB) is one of the largest private banks in Sri Lanka with branches located throughout the island. They’re not new to introducing novel concepts and innovation. NTB was the first bank in the country to introduce 365-day banking and they’ve recently pioneered open banking in Sri Lanka. One of their innovations is FriMi – which also happens to be Sri Lanka’s first digital bank, mobile wallet, and payment system that is fast gaining in popularity. In fact, NTB was named one of the top 30 local business establishments and FriMi was named as one of the country’s top 30 financial institutions by the Asian Banker magazine.

Pioneers in Open Banking

Unlike other parts of the world, NTB was not driven by regulatory needs to introduce open banking. They wanted to align their strategies to cater to changing customer expectations and enable collaboration and data sharing within financial services providers in the country. By doing so, NTB was seeking to create new business opportunities and partnerships with startups. Since NTB offers a vast range of services for their customers, their main challenge was ensuring that no service disrupts the functioning of another service and inconveniences customers in the process.

Nisala Kodippili, the chief information officer at NTB, explains that one of the main issues they faced were the many integrations done at different times and at different levels. NTB’s ATMs and mobile and internet banking services used different APIs. This created a scenario where there was a discrepancy in the account balance displayed when customers accessed their accounts via ATMs compared to when they viewed their accounts using mobile banking! NTB managed to solve this problem by developing a method where they use a single API and to avoid these issues faced by customers. Ironically this set the stage for a bigger problem. Whenever there was an issue with one API, the entire stack is disrupted making this a single point of failure for everything. When this happens, the only way to bring in a new service is to build multiple APIs from multiple systems and identity management at multiple levels is not an easy task.

The Right Technology

To manage the different identities and APIs better, NTB turned to WSO2 Open Banking. Leveraging WSO2’s API management, security, and integration capabilities, WSO2 Open Banking provides the technology for open APIs, third party services, and digital transformation of financial services. It is built on architecture that can scale to deliver compliance for different deployment sizes. “Maintenance is simple, if there are any changes you have to go through the API Manager and do the modifications,” says Nisala. NTB’s new architecture is created in such a way where only one identity is needed for various applications, enabling them to collaborate all identities onto one platform.

Thanks to their new solution, NTB is now able to integrate easily with any new third party within a week. Nisala says that he and his team were astounded by the improvements, “It’s simply a matter of somebody consuming our API and even I didn’t expect the other service providers to follow us. But I’m proud to say that service providers and other third-party integrators who are working together are willing to move to the standard level. They are consuming our APIs very quickly.

Customer Satisfaction is Key

Customers who want to make any changes to their account now only need to make this change once and it reflects on all other services. Security has also improved and NTB has extensive monitoring capabilities where they can control the level of APIs consumed by a single party. “It’s very easy, even at the merchant level we can control the API consume levels,” Nisala explains. Using single sign-on for all applications has helped them to eradicate the issue of duplication of identity. WSO2 Identity Server manages this for NTB, regardless of what the third party application or any other application brings in. This has improved the user experience tremendously.

Nisala says that NTB has unlocked their true potential by venturing into open banking and their new architecture which is free from single point failure has helped them reach new heights. “WSO2 has enabled us to build, scale, and secure sophisticated integration solutions to achieve our digital agility,” says Nisala.

To learn more about NTB’s open banking journey, watch Nisala’s presentation.

Curious to learn more about WSO2 Open Banking? Everything you need to know is here.

Meeting the March 2019 PSD2 Compliance Deadline with WSO2 Open Banking

We’re reaching the final stretch of the PSD2 timeline. However, before targeting the final deadline, the Regulatory Technical Standards (RTS) also specifies an earlier deadline set on March 14, 2019. This will open doors to open banking by letting interested third parties explore the open banking ecosystem and start developing applications around it. As defined by the RTS, implementers should open up a sandbox environment ready to onboard third parties where testing can be done without exposing any sensitive information — a safe playground to kickstart open banking.

Regulatory Requirements

We’ll explore the essential building blocks that you’ll need to meet the March deadline. With WSO2 Open Banking it’s possible to meet these regulatory requirements out of the box and gain regulatory compliance in just over a month.

Open APIs

The main interface for consuming payment services is through APIs. Third parties bearing the roles of “payment initiation service providers”, “account information service providers” or both, will consume two types of exposed resources — accounts read-only API or payments read-write API.

Apart from exposing Open APIs, WSO2 Open Banking comes with fully-fledged API management capabilities that were positioned as a leader in The Forrester WaveTM: API Management Solutions, Q4 2018 report. This allows easy lifecycle management with pre-defined templates to support UK, Berlin Group and STET API specifications.

Strong Customer Authentication

The aforementioned APIs are protected with PSD2 Strong Customer Authentication (SCA) which is based on two or more authentication methods categorized under knowledge-based and possession-based factors. A solid SCA implementation will ensure that only authorized parties are consuming the APIs with explicit user consent.WSO2 Open Banking provides an out of the box SCA solution that is aligned with the PSD2 regulatory requirements. Also provided are identity and access management capabilities that allow seamless integration with legacy user stores.

Consent Management

The mediator between the Open APIs and SCA is consent management, which governs the access of user information by third-party providers. Access to this sensitive information is only retrievable with the user’s explicit consent. WSO2’s PSD2 compatible consent management module handles the heavy lifting while providing portals for customer care and self-consent revocation, therefore, allowing banks and users to manage their consent.

The task of consent management is to capture a user’s consent with fine grain details of transactions that ensures the user is informed of and has authorized the transactions. Consent can be of different types. For example, consent can either be given per transaction or for a recurring payment (where the consent is long-lived). The implementer’s consent management system should be able to handle a multitude of consent types while giving users and banks the ability to revoke and manage consent.

Transaction Risk Analysis

SCA provides a great layer of trust for open banking but handicaps user experience. This view was shared by many when the first drafts of the RTS were presented. The answer to this was Transaction Risk Analysis (TRA) — a context-aware rule-based system that makes sure SCA is exempted in low-risk scenarios thus increasing customer experience.

The solution ties TRA with a strong analytics and stream processing engine allowing accurate risk analysis and fraud detection. Proper implementation of this component is crucial to be PSD2 compliant and will promote better user experience with SCA.

Third Party Provider Onboarding (TPP)

The prior mentioned components build the fundamental open banking solution, but this won’t be any good if third parties are not able to onboard and consume its functionality. The system needs to be able to onboard third parties manually or through dynamic client registration, where third parties are on-boarded instantly with the backing of a competent authority.

WSO2 Open Banking provides customizable workflows for third-party onboarding and lifecycle management. External trust anchor integration allows dynamic client registration.

Regulatory Reporting

Each competent authority specifies certain statistical information to be reported regularly. WSO2 provides reporting tools to export required regulatory statistics.

Conclusion

By getting all these components together, banks will be prepped and ready for the external testing deadline in March. Additionally, this preparation provides strong guidance for meeting the September deadlines of the RTS. WSO2 Open Banking is equipped to help you meet both these deadlines within reasonable time frames and minimal effort from the bank.

For more information on how we can help you get ready for the March 2019 deadline, drop us a note at openbankingdemo@wso2.com. You can also download an effort estimate to understand how we can help you meet the deadline in just over a month and check out our webinar for more information.

Ask an Expert: Catching up with Ruwan Abeykoon

Ruwan, on the right, participating in a badminton competition in WSO2

If you bump into Ruwan outside WSO2, you’re most likely to meet him along a hiking trail or underwater, scuba diving somewhere in Sri Lanka’s southern coast. He’s also a vehicle enthusiast and loves technology. Inside WSO2, Ruwan currently looks into product stabilization efforts of WSO2 Identity Server that results in improving the overall architecture of the product.

In this interview Ruwan sheds light into his journey at WSO2 so far, identity and access management (IAM), and his view about software.

1. How did you enter this industry (was it by accident, why IAM)? Tell us about your journey at WSO2 so far?

Every change in my career was based on calculated decisions at critical junctures and I’m very pleased at how everything has turned out.”

I started off as an entrepreneur after grad school, working in the telecom and retail sectors. My expertise lies in telecom signalling and it’s been one of my interests for the longest time, in addition to high performance computing and IoT. Subsequently, I joined WSO2 where I was a part of the App Manager team, which is now the WSO2 Identity Server team. Every change in my career was based on calculated decisions at critical junctures and I’m very pleased at how everything has turned out.

2. What are some of the interesting projects you’ve worked on recently?

Adaptive authentication is one of the latest features we added to WSO2 Identity Server. What’s different about how we offer adaptive authentication is that it’s based on scripting language similar to ECMA. This is also involves user behavior analytics based authentication.

WSO2 Identity Server analytics is able to monitor login and logout sessions, and provide analysis based on a user’s behavior which helps with providing an additional security layer when authenticating them. This is what adaptive authentication is ultimately about.

Adaptive authentication is very important right now and not because of user convenience alone. Major financial institutions use adaptive authentication to provide advanced user experiences while providing Open-Banking APIs.

3. Do you see adaptive authentication as a game changer and how so?

People always want easy access to applications and systems. Making this process difficult means users will either move away from the business or they will have weak security methods. For example, enforcing people to use long and complex passwords can lead to them writing their passwords on a piece of paper somewhere, which isn’t a smart thing to do.

On the other hand, security experts want to limit access to resources and systems as well. Hence there is a need to find the right balance. And a need to detect risk and limit access while allowing free access for legitimate cases or users. This involves evaluation of many parameters and behaviors than simple static rules that are offered by most IAM solutions. In the future, we’ll also need to embrace AI on the authentication process.

4. What trends do you see in the IAM market? Where do you think we’re heading?

I’m going to provide a very brief overview of some trends that I’ve observed. For one, there’s an increasing dilemma between whether or not we should opt for a centralized IAM system. But given privacy concerns, it’s quite evident the IAM industry is heading towards a decentralized identity and access management system. Another trend is sovereign identity, where an individual decides what can be done with an identity. Although there’s a growing need for increased privacy, people must be able to share and delegate easily. Another is space-time-bound edge device security with identity of a person.

5. We now keep hearing that IAM is an enabler and it’s more than just security or an IT project. What’s stopping enterprises from embracing this? Why do you think they should?

It is easy to start an IAM system with a homegrown solution of simple databases. There are a plethora of libraries available to kick start a homegrown IAM system. But it gets into an inescapable vortex when more and more functionalities are needed in today’s agile businesses. Enterprises need to detect this at an early stage and adopt a proper IAM solution before the vortex grows into an unmanageable beast by itself.

6. Two things you’ve learned in your career that you’d like to share with a newbie?

Think of software as a medium of communication between both systems and people.”

First, think of software as a medium of communication between both systems and people. This could be system to system, system to person, and person to person. Second, learn to unlearn. No software practice has lasted for more than a decade. New languages and methods keep propping up and your openness to learn is what helps you progress.

Ruwan on one of his many scuba diving adventures!