Category Archives: Customers

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.

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.

Open Banking Implementations in Europe and Africa: The Story of Société Générale (So Far)

Investment and retail bank Société Générale has its headquarters in Paris, France plus 45 branches in 36 countries, representing over 18 million customers globally. Retail banking services support 3 business lines in the regions of Europe, Africa and the Mediterranean, and Russia. Their 2020 strategic plan is simply named “Transform to Grow.” Open is the keyword here. “We want an open approach to develop offers and client satisfaction,” says Jean-Louis Rocchisani, enterprise architect at Société Générale.

The Transformative Powers of Open Banking

Open banking plays a crucial role in Société Générale’s transformative approach to business growth. Their open banking journey started in 2015, having recognized the opportunities it presents for improving the time-to-market and reforming their business model. Their open banking efforts have not passed by unnoticed. Recently, Société Générale was selected as the most advanced company out of 44 listed companies in the French market. After investing in the needed architecture, Société Générale now looking to extend towards the bank as a platform model.

Société Générale also sees the the transformative power of technology and APIs in its future. “We’re currently in the proprietary model, but we see the opportunities to increase our distribution power by creating a smooth digital end-to-end process,” says Jean-Louis. “We’re also looking to monetize our services and most importantly, create interactions between service producers and customers – which is also quite hard to launch. But this is possible because we have APIs as a product.”

Société Générale is guided by open banking drivers in the many parts of the world that they operate in. These include PSD2 compliance and beyond in Europe, modernizing B2B2C models, and enhancing digital banking services (as is the case in Africa). Community plays a central role in Société Générale’s open banking efforts, as markets are different and evolving across countries, and working with local communities of financial service providers is essential.

Jean-Louis presenting at WSO2Con EU

How Société Générale Came Across WSO2 Open Banking

Société Générale and WSO2 have a strategic partnership that dates back to 2015, ever since the first successful implementation. Their first success story and the fact that WSO2 is open source were major deciding factors for Société Générale. SOSMART is the acronym for Société Générale’s architecture principles which are sustainable, open, modular and real-time, and API first. They were looking for a technology partner who would accompany them for the entirety of their open banking journey. WSO2 Open Banking provides the technology for open APIs, secure integration with banks and third parties, and integration analytics capabilities. “WSO2 has innovative products, efficient people, and a shared vision with us,” explains Jean-Louis.

Use Cases From Africa and Europe

Germany: This was the first use case implemented by Société Générale and is centered on equipment finance, financing for big customers through vendors. This project began by implementing a B2B2C platform using WSO2 Open Banking, using the support from local vendors. This platform is now extended to include international vendors as well, using a federated model rather than a shared one to improve its efficiency.

Czech Republic: A large bank in the Czech Republic needed to leverage PSD2 towards open APIs, using WSO2 Open Banking. The bank is now working with fintech developers and partners in the country, using the API platform which was launched. This bank is looking to close the gap between iteration and deployment and they’re satisfied with their progress so far.

Africa: Société Générale works on innovations to digital and mobile banking rather than regulatory compliance in their African business operations. They currently have 12 banks in Africa, all of whom are different despite sharing the same core banking system and is therefore difficult to scale use cases from one country to another. An API layer has reduced the time to market, and the next stage is to open this platform to fintechs and other service providers in the ecosystem.

France: Société Générale’s French overseas territories banks have to achieve PSD2 compliance. In spite of the tight deadline, Société Générale believes this can be achieved on time and are using WSO2 Open Banking to speed up the implementation.

What’s Next?

With experience gained from a string of successes, Société Générale has more exciting projects lined up together with WSO2 Open Banking. For Jean-Louis, technology is an enabler (and not a constraint) and he says, “We believe in an interoperable world, where technology opens up possibilities leading to more success stories.”

Listen to Jean-Louis’s complete presentation in this video.

WSO2 Open Banking helps you achieve regulatory compliance in Europe and Australia, with successful use cases from around the world. Learn all about its capabilities here.

Macmillan Learning and Ribbonfish: Solving Diverse Integration Needs to Help Students and Instructors Better

Macmillan Learning is a leader in the education publishing and EdTech industries, with a target market of over 9,000 colleges and 50,000 high schools in USA and Canada. Their partnerships with many of the world’s best researchers, educators, and administrators, as well as their emphasis on top quality content drive their business. Macmillan Learning teamed up with Ribbonfish, who specializes in offering service solutions to the media and publishing industries, to answer the changing needs of the education industry – helping both students and instructors improve their outcomes.

A Technology Strategy for an Evolving Industry

Macmillan Learning observed how the education industry has been evolving over the years and realized that they need a strategy to answer to the rapid developments that are taking place in this industry. Key among their goals was responding to market needs faster and providing students with interactive digital solutions to support their education.

However, the education industry is a seasonal one and Macmillan Learning wanted to ensure their new solutions caused the least amount of disruption, particularly during peak times. Another important consideration was the internal organizational structure. “You can’t develop a technology strategy in isolation, we need to be mindful of both the structure and culture of an organization. The culture needs to be improved, particularly when partnering with others and the structure needs to be standardized across the various teams,” says Sagar Bujbal, VP technology at Macmillan Learning.

Like any other business, Macmillan Learning integrates with many disparate systems. “Around 60 to 80% of your time is spent on supporting these various systems, rather than concentrating on innovation. When thinking about the right solutions implement, we really need to quantify the strengths and weaknesses of each of these systems,” says Paul King, a solutions architect at Ribbonfish. Both Paul and Sagar stress on the point that seamless integration in such a context requires architectural guardrails and governance. They explain that a well-defined target reference architecture (prior to development) with a long term vision, taking into account changes that will have to be encountered over the years, is a solid starting point. Best practices and utilizing out-of-box platform capabilities are further requirements for seamless integration.

Sagar and Paul presenting at WSO2Con USA

Selecting the Right Technology

Both Sagar and Paul believe that an enterprise integration platform is one of the most strategic technology decisions that a business makes. They were looking to build a target reference architecture that was business driven, rather than focusing on a particular technology and evaluated several technology vendors based on this. Macmillan Learning and Ribbonfish considered factors such as platform capabilities, maturity of the product, type of agility provided for developers, quality of production support, costs, and the vendor’s willingness to work closely with a business to solve their particular needs. Both were of the view that WSO2 Enterprise Integrator, with its integration runtimes, message brokering, business process modeling, and analytics capabilities, catered to their requirements.

Achieving Seamless Integration

Given the fact that integration needs at Macmillan Learning were diverse, Sagar and Paul decided on APIs as the de-facto standard for integrating all their systems. They also made sure that there was no direct coupling. Their current architecture includes the Macmillan Learning integration layer composed of WSO2 Enterprise Integrator along with Salesforce. Paul explains that one of their main goals when building the new architecture was to not over complicate things and using WSO2 helped, “One of the big things we really took from it when we selected WSO2 as a platform and service was that there are plenty of solutions within WSO2 itself.”

Paul and Sagar state that documenting the inventory of business processes and interactions contributed a lot to their success, as it helped them to better define their target reference architecture. They also believe that defining their integration techniques, constant communication with their engineering team, and weekly reviews of what they implemented helped them immensely.

More innovation is planned for Macmillan Learning and Ribbonfish. The huge scale of transformation at Macmillan Learning means that there is a continuous demand to meet these requirements. Proactive customer service plays a key role in this transformation. Macmillan Learning and Ribbonfish gain insights from interactions between customer care agents, students, and instructors to improve this transformation process and customer satisfaction. And as mentioned earlier, they will continue to review what they do for the best possible outcomes.

To learn more about how Macmillan Learning and Ribbonfish are working together, watch this video:

Everything you need to learn about WSO2 Enterprise Integrator is here.

Veridium Develops World-Class Biometric Federated Authenticator for WSO2 Identity Server

Founded in 2016, Veridium is a provider of identity and access management software with a focus on biometrics. As a company, Veridium has essentially one goal: to protect organizations by reducing or eliminating identity as a major threat. It does this by replacing vulnerable passwords and tokens with biometric authentication. In other words, Veridium replaces what you know (passwords) and what you have (tokens) with what you are – your biometrics.

The Ascendency of Biometrics

Biometrics are fast replacing passwords and tokens as the go-to authentication method used by organizations looking to increase security and reduce fraud. This strategy is backed by research. According to a recent report by Verizon, 63 percent of data breaches could have been stopped if an alternative to passwords had been in place.

Veridium is at the forefront of the development of innovative biometrics-based platforms and has a global customer base representing a wide range of sectors including financial services, healthcare, government, and law enforcement all of whom have put their trust in Veridium’s password-free, single-step, frictionless biometric login.

Veridium offers its customers three flagship products: VeridiumID, VeridiumAD and 4 Fingers TouchlessID. VeridiumID is a server-side protocol for biometric authentication that works with a user’s smartphone. It is easily installed within a customer’s network and can provide authentication to enterprise applications, websites and even doors. VeridiumAD is an enterprise-ready solution that increases the security and convenience of Microsoft Active Directory access by replacing passwords with biometric authentication. Finally, Veridium’s trademarked 4 Fingers TouchlessID is an innovative new biometric that captures four prints simultaneously, providing unprecedented levels of security.

John presenting at WSO2Con USA

Effortless Integration of Veridium’s Biometrics with WSO2 Identity Server

Knowing that WSO2 Identity Server accommodated several different biometric configurations including primary authentication, 2FA, MFA or escalated transactions, Veridium first approached WSO2 to see how WSO2 Identity Server could enhance Veridium’s product offerings. John Callahan, Veridium’s Chief Technology Officer, was astounded by the ease by which his company was able to integrate with WSO2 Identity Server. Calling the integration, “one of the simplest things,” John said it took a single developer less than a month to create and execute the federated authenticator.

The result of the integration is the Veridium Authenticator (VA), a biometric authenticator developed to work with WSO2 Identity Server. The VA is IEEE 2410-2017 certified and provides biometric SSO capabilities for most iOS and Android devices using facial, voice and its proprietary 4Fingers™ recognition. VA comes with a vanilla app that is available for iOS and Android. It can also be embedded in customers’ existing apps via their software development kit. By securely linking users and their devices to their digital identities, Veridium’s innovative software-only MFA solution allows for improved and enhanced authentication.

Speaking about the collaboration between Veridium and WSO2 Identity Server, John says that “they just go well together.” Because the two companies share a common vision for the future where single sign-on (SSO) is either through SAML or Open ID Connect (OIDC) and there is movement towards API development, it is no surprise to him that the companies’ product offerings are in perfect alignment.

User-centric Biometric Authentication

The VA offers two types of single sign-on: QR-code and push notification. Both sign-on methods are part of the Biometric Open Protocol Standard (BOPS), the only protocol that specifies the use of an end-to-end system for authentication. In QR mode, a time-sensitive QR code is generated which the user scans and is then prompted for one or more biometric authenticators on their mobile phone. In push mode, the service provider (SP) redirection includes identity information for sending a push notification to the user’s mobile phone where they are then asked for biometric authentication. Successful authentication (for both sign-on methods), results in authorization via SAML or OIDC redirection back to the SP.

Identity and access management (IAM) is an evolving space. Callahan predicts an ascendency in biometrics as, in his words, “devices get scarily good at knowing it is you, and your device and [that] you are the one authenticating.” As the volume and intensity of cyber attacks increases, developers have to be more innovative and agile in their approach to authentication in order to provide their customers with the best protection. The collaboration between Veridium and WSO2 Identity Server in the form of the Veridium Authenticator is a perfect example of the type of forward thinking, adaptive authentication that will characterize the identity landscape of the future.

Watch John’s presentation to learn more about how Veridium and WSO2 worked together.

Everything you need to know about WSO2 Identity Server is here.

NewWave Taps API-driven Innovations to Develop Federally Compliant Healthcare Microservices for Centers for Medicare and Medicaid Services

The Centers for Medicare and Medicaid Services (CMS) is a federal agency in the United States Department of Health and Human Services that administers the Medicare program and works with state governments to administer Medicaid. It is the single largest payer for healthcare in the United States and provides services to over 130 million Medicare and Medicaid beneficiaries. Creating a stream of relevant and timely applications and products to service their significant customer base, while ensuring compliance with federal IT regulations, poses enormous challenges to CMS.

Traditionally, it takes several hundreds of hours of manual coding to develop an application that meets the federal government’s 3-zone architecture requirement. The process is so laborious and time consuming that the solution being developed often risks being obsolete before it has even deployed. Fortunately, CMS’ healthcare technology partner, NewWave, has devised an API-based solution that develops and deploys federally compliant healthcare microservices at hyper speed.

NewWave’s mission is to work with their clients to modernize their businesses and empower them to use technology in new ways. Donghwa Kim, director of application engineering at NewWave, says, “When we solve problems, we constantly remind ourselves of three things – people, processes, and tools. And of all three, people always comes first.” In keeping with this mission, the challenge of technological obsolescence at CMS was a natural fit for the company.

Donghwa discussing this solution at WSO2Con USA

Powered by Flexible APIs

Using API-driven innovations, NewWave developed SmartApp, a powerful development accelerator that streamlines application start-up and delivery at CMS. NewWave compared several vendors and settled on the open source WSO2 API Manager, as it had all the features they required for the new solution, which above-all needed to be flexible. WSO2 API Manager allows customization and extensibility, in addition to supporting full API lifecycle management. It’s designed to fit into microservices architectures. “Also, WSO2 provides great support,” says Donghwa.

Based on JHipster, a Yeoman generator for Sprint Boot applications, SmartApp uses best-in-breed components like Spring Boot, Spring Cloud Components, MongoDB, MySQL, HTML5, Angular JS, React, Bootstrap, and OAuth to generate responsive and cloud-ready Java applications. This saves developers hundreds of hours in manual coding. Compared to traditional application development which can take several sprints and up to fifteen weeks to complete, SmartApp compresses project set up/plumbing, basic CRUD Domain implementation and custom development into 2-3 weeks.

The beauty of SmartApp is its simplicity. The user selects an application’s desired features from a list of menu items which then generates a secure, unit-tested, and standardized project structure specific to the user’s specifications. A fully functional application can be built in minutes, with no coding required. Features include auto-populated project libraries, architectures and database back-ends. SmartApp is also available as a Vagrant-ready Docker image.

The infrastructure supporting SmartApp is called SPADE (Self-Provisioning And Dashboard Environment). SPADE is an open-source DevSecOps platform-as-a-service (PaaS) that deploys and manages SmartApp microservices. It supports modern containerized deployments while complying with the government’s three-zone architecture. This infrastructure is web-based, cloud-hosted, API-driven, vendor-agnostic, open-source, hosted on-premise, and has dashboard functionality. SPADE also enables SmartAPP users to develop, test, deploy, and maintain microservices.

Better, Faster Healthcare Apps

Both SmartApp and SPADE make up the complete solution by which CMS can develop, deploy, and manage federally compliant, secure healthcare applications in a matter of minutes. CMS is now able to automate the long-drawn out process of application development, and by reducing the time spent on time-consuming tasks, they can focus more on delivering value to their customers.

Learn more about SmartApp and SPADE in this video:

Find out more about WSO2 API Manager. We were named as a Leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report.

Using Open Source Technology to Solve Complex Integration Needs at American Express Global Business Travel

American Express Global Business Travel (GBT) is a travel and meetings management company, which operates in 140 countries at present. They receive over 3 million messages and make 100 million service calls, all in one day! To effectively deal with the sheer volume of messages and calls, GBT launched Global Trip Record™, a platform that captures all global bookings on various transport companies in one system and functions as their single source of real-time and historic trip data.

A Strong Orchestration Layer: The Need of the Hour

GBT was looking for a strong orchestration layer on which to build this platform. They had an existing legacy system, part of which was a Java application that had thousands of lines of code across different files. For this reason, each redeployment required IT to shut-down, then re-start, the entire system. “No integration is easy and proprietary software doesn’t allow you to change much,” says Pradeep Chintam, software engineer at GBT. “As a developer, I like working with the code everyday. We were also looking for a product that allowed customization together with reliability. Hence, the decision to use WSO2 Enterprise Integrator,” he explains.

Eventually GBT decided on a microservices approach, yet they evaluated the pros and cons carefully first. Pradeep had a lot of questions on how microservices can be used to orchestrate between services, how to proceed with service discovery, and how to perform load balancing and fault tolerance. “When discussing microservices architecture, a lot of people are of the view that you should have smart endpoint and dumb pipes. I honestly don’t agree with that. What do we want from a solution – to follow principles to the letter or an application that functions without glitches? I think many people would choose the latter, no matter how important principles are,” says Pradeep. That was exactly what was done with WSO2 Enterprise Integrator when building their new platform.

GBT has many connecting systems and wanted to enforce a single entry point to their application. Thus, the architecture is built in way that everything connects via WSO2 Enterprise Integrator, and all orchestration between microservices happen within WSO2 Enterprise Integrator itself. This architecture has worked for 2 years to date, without a single instance of downtime.

Pradeep speaking at WSO2Con

The Deployment Model

Every message passes through at least thirty microservices and all the message transformation is handled by WSO2 Enterprise Integrator. GBT scales up their microservices so that they can handle hundreds of transactions and messages per second, but they scale the Enterprise Service Bus (ESB) based on their needs. To accomplish this, GBT also also uses Apache Kafka to bring elasticity to the application, as they do not want to overload WSO2 Enterprise Integrator when connecting 30 different downstream vendors.

During the deployment model, the code is first checked into git. The architecture includes a Jenkins server where the build is triggered and it then passes to SonarQube which verifies all vulnerabilities and bugs. It is then packaged to CAR files. A plain ESB image is pulled, customized files are overwritten, and the CAR files are then copied to appropriate folders. After that, the final Docker image is created and published in their Nexus repository. Deployment is triggered in OpenShift which only receives the image tag number. OpenShift will then pull the image from Nexus, deploy it, and is finally ready to serve the request.

Unlike the industry standard, GBT does not use a governance registry in their architecture. As a result, Pradeep limited the number of instances and technologies. GBT uses a custom solution, where they use another ESB project which acts as their governance registry.

This solution is an integral component of GBT’s aim to provide travel management tools that offer millions of customers around the world the best possible travel experience. “The fact that WSO2 Enterprise Integrator is open source and allows for flexibility were big plus points for us. Apart from that, the support has been great. I’ve been using the product for over 6 years and I’ve only raised a support ticket once, which was solved within the day,” says Pradeep.

To learn more about how GBT created Global Trip Record™, watch this video:

Micron Technology: Leveraging an API-first Strategy to “Chip” Away at Technical Debt

What do a caveman, a horse cart, and a Micron developer have in common? They all use archaic tools.

Micron Technology — a global manufacturer of semiconductor devices, headquartered in Boise, USA — currently has numerous monolithic client/server applications and legacy technology that amount to a lot of technical debt. To solve this issue, they decided to migrate from a system deeply entrenched with internally developed thick clients to an API-first strategy using WSO2 API Manager.

The Problem at Hand

Micron Technology has many dynamic link libraries (DLLs) that are deployed throughout 40,000 workstations across the company. Thick client applications are pushed to each desktop and all DLLs, .NET libraries and the issues that come with them need to be managed. By employing an API management layer, they first aimed to simplify the means for migrating and managing this system.

Today, if they wanted to do an enhancement to a DLL, they don’t know who it will impact and can’t easily find out who the owners are. So another key requirement was to have the ability to identify owners and users of those APIs. They also needed throttling capabilities and 24/7/365 uptime was critical. Next, they needed to support all sites with one solution. This includes the front-end site where the semiconductor chips and created and the back-end site where the processed chip is tested, probed and packaged.

They also needed to ensure that standards and best practices for API development and deployment were followed, which proved to be a difficult task considering the paradigm shift for Micron developers. “We need to provide a solution that makes it easy to design, develop, and manage these new web services,” says Alan Pearson, IT Operations Manager at Micron Technology.

The Journey to API Freedom

To create this solution they needed key functionality including security, monitoring, throttling, multi-tenancy, transforming, and routing capabilities – which lead them to WSO2.

They are currently deploying WSO2 API Manager on-premise and are in the process of reworking all their thick application to an API-first approach while providing the guaranteed uptime. They have 10 gateway deployments worldwide, kept up-to-date using subversion sync, with the master publisher and store in Boise, Idaho. Updates to WSO2 API Manager are applied every month using WSO2 Update Manager and Puppet scripts, which has saved them 15 hours of manual work and eliminated the possibility of human error.

They have now enabled core APIs as web services for language agnostic development, which eliminates the need to recreate the wheel for every desktop update (for example from Visual Studio 2010 to Visual Studio 2017). This is done by moving the data access and business logic to the web service.

They also implemented a global server load balancer, which is a self-aware system that sets up an alias and routes users (the developers) to the nearest site based on their location. For example, if a user makes a request from Taiwan, the load balancer would point them to the Singapore gateway. If for some reason that gateway is down, there will be an automatic failover to the Boise gateway. This provides resiliency and guaranteed uptime. In addition to this, they also created a number of usage metrics.

Creating an API Marketplace

Micron Technology didn’t stop there. To really make this API-first approach a success, they needed to educate their developers and make sure usage increased. This was done by applying the concepts of an API marketplace and promoting activities like evangelism, hackathons, and workshops. They built a Center of Excellence (CoE) that was responsible for helping the development community understand what the API gateway was and how to leverage it.

They did dog and pony shows in sites around the world, created manuals, conducted train-the-trainer sessions, and even employed additional training through Yenlo — a WSO2 Premier Certified Integration Partner. An innovation initiative was also introduced. They used an API that translates English to whatever language (the secure tech translator) to provide an overview of the API store and publisher. They then conducted a hackathon that allowed users to create and publish their own web services.

“The cool thing is you could translate English to Klingon [a fictional language in Star Trek], and when I did this is the demo, a few people actually understood what I translated,” says Alan. This shows how relating an educational session to something that their developers were interested in really helped Micron Technology with their onboarding process.

Learning Areas for a Successful API Program

Because it was a major paradigm shift for their developers, providing them with the appropriate training and tools was key. They also had to align WSO2 ownership within the team (from the hardware to the applications) in order to speed up turnover time and tighten the integration. Implementing the global server load balancer was also an important step in ensuring high availability. Additionally, they used Puppet to automate where possible and reduce manual work.

“The other thing I had to do is really go around and sell, sell, sell. If it means doing site visits, visiting with all our developers, and doing on-site training, that’s what we’ll do to get a successful deployment,” says Alan.

They still have a lot left to do including growing their documentation, continuing their training, supporting DevOps and API lifecycle management, creating a WUM test area and evaluating WSO2’s cloud deployment for external facing APIs.

After an architecture review and use case walkthroughs, WSO2 identified and added product enhancements to the roadmap including access control for an unlimited tier and mediation extensions. “WSO2 does listen and partnering with them has helped out. We’ve had quick turnaround on [support] tickets, they’ve added numerous enhancement requests, and we’ve had on-site architectural reviews that have been really helpful to drive the product forward,” concludes Alan.

Watch Alan’s presentation at WSO2Con USA to learn more.

Try the open source WSO2 API Manager today >

Did you know? We were named a leader in The Forrester Wave: API Management Solutions, Q4 2018 report. You can download the report here, no email required.

Skate to Where the Puck Will Be: How Wells Fargo Created an Award Winning, Customer Facing API Channel

When studying Internet user habits, Wells Fargo came across a surprising revelation – although the amount of time that individuals spend online has leaped significantly over a 16 year time frame (from 2000 to 2016), only around 3% of that time is allocated to browsing about financial services. This got Eric Halverson, SVP, Head of Gateway Support & Services at Wells Fargo, thinking about their existing distribution channel and how it can be improved to provide better experiences for people. For Eric (and Wells Fargo), doing what’s right for customers means not only answering customer expectations, but exceeding them and building relationships that last a lifetime. Enter the Wells Fargo API Gateway, created using our open source WSO2 API Manager. This platform delivers all their products and services to customers’ digital experience of choice and supports all of Wells Fargo’s business units across the company.

Eric Halvorson presenting a keynote at WSO2Con USA 2018

Yet how do you begin to provide APIs to customers all around the world? Upon realizing there were no large banks in the US that had an API platform, a team of 4 from Wells Fargo spoke to banks in Europe and Southeast Asia, in addition to companies in the US who had built API platforms. Following which Wells Fargo decided to expand this particular team from 4 to 150 within six months. They also decided to use agile, and in essence live the agile manifesto, over the waterfall fashion. The API Gateway was launched on September 2016, with 5 APIs and DevPortal 1.0 (the latter was very basic at the time, although it had all the functionalities for integration).

Fast forward to July 2018, Wells Fargo had hundreds of implementations with many customers who are performing multiple API implementations. The platform provides streamlined on-boarding for both new and existing partners, round the clock operations and support, and multiple security layers in addition to the existing risk management controls. They’ve also launched DevPortal 2.0 which bagged a Monarch Award for its creativity and innovation.

Engaging with their community of customers and partner groups takes precedence for Wells Fargo. They’ve repeatedly heard from customers about the difficulties they face when implementing large scale platforms. Which is why from the project’s inception, Wells Fargo went that extra mile to ensure that customers can integrate easily. The fastest onboarding time so far? One day!

Customers and partnerships will continue to be at the forefront as Wells Fargo continues to explore the many API opportunities that are out there. Currently they’ve identified 3 areas of interest: creating API products for wholesale customers, partnerships with 3rd party platforms, and accelerate Wells Fargo integrations with vendor solutions. Eric explains further, “As we gain more experience with our customers and see how our integrations work, we’ll open up to more as we go along. It’s a constantly evolving strategy of trying to be where the puck will be – we want to be where the industry is moving before it gets there.”

Some use cases of the Wells Fargo API Gateway include account aggregation, ACH payments, and foreign exchange. Retail customers are a big beneficiary of account aggregation APIs, as they can control access to their data through a product named Control Tower™ which Wells Fargo introduced specifically for this purpose. Customers can check their account balance and activity data on approved aggregator sites. As the top ACH payment provider in the US, Wells Fargo has built up their transactional APIs to be re-used, allowing customers to move from one experience to another with minimal changes to their resources underlying the APIs. Customers who need to transfer funds internationally benefit from the foreign exchange platform, which is directly connected to customers’ ERP or customer portals. These customers can obtain a foreign exchange quote, book a deal, and settle the payments all in one go. “We’re making people’s lives richer by embedding financial services in the moment they’re at, and delivering services to where the customer is at rather than making them come to us,” concludes Eric.

Watch Eric’s presentation for more details about the Wells Fargo API Gateway.

Learn more about WSO2 API Manager. Did you know? We were named as a Leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report. You can download this report here, no details required.