Tag Archives: API Management

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 educational 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.

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.

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.

WSO2 Named a Leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report

Today, The Forrester Wave™: API Management Solutions, Q4 2018 was released and WSO2 is named a leader!

You can download the report (without filling in a form) here.

This recognition is a major achievement. Congratulations to the many internal teams, partners and customers that participated in the efforts to make WSO2 the only open source vendor evaluated in the report.

Nuwan Dias, WSO2’s product lead for APIM gave a tour-de-force 2-hour non-stop demo demonstrating raw software athleticism. Also, I’d like to tip my hat to Randy Heffner and the Forrester team for structuring a thorough (and frankly, exhausting) analysis that assuredly left no stone unturned from any vendor.

The API management market is growing because IT professionals see APIs as a critical foundation for agile software to support customer engagement, operational excellence, digital transformation, and business agility.

Forrester states why APIs are essential: “The API management solutions market is growing because more AD&D pros see APIs as a critical foundation for agile software to support customer engagement, operational excellence, digital transformation, and business agility.”

API management has become an essential part of every integration strategy and it’s why WSO2’s APIM solution is fundamental to how we help organizations become integration agile.

What Forrester Says About WSO2

  1. “WSO2’s open source solution provides a solid base for a variety of API strategies.”
  2. “[WSO2 is] the only fully open source solution in our Forrester Wave analysis.”
  3. “WSO2 provides good breadth across all evaluation criteria.”
  4. “[WSO2’s] strengths include formal life-cycle management and non-REST APIs, both of which facilitate mature and disciplined enterprise API strategies.”
  5. “WSO2’s solution provides flexibility to address a variety of approaches to APIs.”
  6. “The reference customers provided by WSO2 are highly satisfied with its solution and very satisfied with the vendor.”
  7. “[Customers] tend to be very to extremely satisfied with the product’s detailed features and functions.”
  8. “Customer comments include“[WSO2’s] partnership attitude inspires confidence and trust.”
  9. And “[WSO2’s] solution is easy to use.”

What Is Special About WSO2

In addition to the demo and a (many 100s) questionnaire, we delivered a summary presentation to Forrester’s team discussing our market penetration, product composition, and long term thinking.

WSO2 API Manager: The only comprehensive open source solution has been shipping for 6 years

API Management provides full lifecycle management of APIs for a variety of scenarios, whether B2B access, internal development, shared libraries, or monetization. WSO2 has been shipping our offering for 6 years and it has expanded to include a macro and micro gateway, embedded analytics and API identity, and API development tooling. WSO2 was the only vendor whose entire stack was both open source and available in on-premises or cloud offerings.

Embedded identity and integration makes legacy asset transformation into APIs possible without buying other products.

WSO2 provides a complete set of capabilities that allow customers to pursue any kind of API strategy. We front-end our offering with our ESB, identity server, and embedded analytics offerings to provide means to digitally transform legacy infrastructure into APIs.

More than 100 billion transactions run through WSO2 each day.

We are fortunate to have customers that participate in our conferences, give case studies and act as references. More than 30% of our API customers are financial services institutions. Starting small, our API management business is growing more than 75% each year and makes up 1/3 of our business.

What Are WSO2’s Big Bets

Forrester evaluates 26 criterion around the vendor’s current offering, strategy, and market presence.

WSO2’s long term strategy and roadmap are largely influenced by what we are seeing across the projects that we are working. Our observations are influenced by exploding endpoint issues on how integration has been preventing many organizations from realizing their agility goals.

  • Expect an increasing proliferation of digital endpoints, APIs, and applications that consume APIs. There is an integration economy that will grow exponentially with endpoints in the trillions, driven by edge computing, IoT, SaaS-SaaS integration, AI, machine learning, cloud computing and serverless.
  • APIs and digital endpoints will have an increasing diversity of origin. Different groups and personas will be creating APIs whether they are developers, knowledge workers or self-actualizing systems. There will be different locations where APIs reside, internal, external, on the edge, or in the cloud. And the structure of APIs will diversify taking construction from streams, events, async, and new protocols.
  • Expect the rise of dynamic APIs: short-lived, with frequent changes to facility agility. Microservices drive needs for fast-boot, low footprint, containerized services and some architectures requiring a microgateway per API. This creates change management and deployment problems for DevOps.
  • A need for adaptive management of APIs due to their proliferation and dynamism. Integral monitoring and management needed across diverse API origins. This amplifies demand for dynamic and federated identity, token swapping and SSO integration along with decentralized observability and monitoring with tools that keep pace with API rate-of-change.

These dynamic conditions allow us to invest into features that enable micro API management in environments that have thousands of constantly changing and distributed APIs.

WSO2 API Manager roadmap focuses on diversity and micro-ization of distributed APIs

Rethinking API Development and Lifecycle With Ballerina

Starting three years ago, WSO2 began working on Ballerina. It’s a new programming language that is designed to be the best language for writing services that need to talk over the network. Ballerina’s launch earlier this year has received a number of accolades, has grown in adoption, and now has multiple enterprises using it to build service-based architectures.

A service, or an API, is a first class concept within the language. Ballerina is a compiled, strongly and statically typed, concurrent language. The language provides modern benefits of structural programming without requiring significant scaffolding to resiliently (load balance, fail over, transaction, payload management, and error conditions) build and talk to APIs.

Ballerina dramatically improves developer productivity by making API iterations fast and agile. Ballerina has a built-in API gateway and is designed to plug any services built by Ballerina into an API management solution, or drag along a micro gateway. Essentially, the Ballerina language and compiler are distributed systems aware, and prepare the artifacts made by developers to be API management ready.

Get Started with WSO2’s API Management Offering

WSO2 is now the world’s 6th largest open source software company. Our significant size and staff (600 employees!) allow us to run a 24/7 operation with a global reach. We have sold and delivered into 63 different countries with offices in the United Kingdom, Brazil, Mexico, United States, Sri Lanka, Australia, and Germany.

And as usual, if you have any questions about open source, our API management offerings, or WSO2 (we are hiring, a lot!), you can reach me at tyler@wso2.com.

Four Warning Signs an Integration Wall is Approaching

The Integration and API Management markets are growing, expanding in both popularity and use. Enterprise App integration will surpass $33b by 2020, and other markets like iPaaS and Data Integration are growing at double-digit CAGRs. Enablers, such as containers and serverless technologies are only accelerating the move toward increased disaggregation of applications.

All seems rosy. And it mostly is.

But with the explosive growth of APIs and endpoints, traditional centralized tools like ESBs will become unsuitable, and simple low-code snap-together tools won’t scale to address the broader scope. We’re potentially about to hit an “integration wall” at high speed.

Consider the following four warning signs – some technical, some process – that I find are beginning to plague the integration market:

1. Waterfall Development for integration is hitting a wall.

Although most code development has shifted to an Agile Development model, the same can’t be said for Integration tools. As the quantity and diversity of endpoints increases, and as Integration projects become more diverse and complex, use of the waterfall model is beginning to slow down integration projects. And with a future where there will be billions of Integratable endpoints, it’s obvious that an Agile Development model for integration will need to become the norm.

2. Existing tools and programming languages aren’t optimized for Integration-at-scale.

Enterprises that currently use low-code, snap-together, centralized integration technologies (including iPaaS) will not be optimized for orchestrating, integrating, observing and governing the expansion of constantly-changing endpoints. Nor are traditional centralized approaches (think: EDI and older ESBs) prepared to handle increasing endpoint scale or diversity. Many of these existing tools are well-adapted for Line-of-Business or Citizen Integrators of relatively small-scale implementations but are far from well adapted for more complex integration-at-scale projects.

3. Current programming languages are not optimized for Integration.

With languages like Java/Spring or JavaScript/Node, developers can engineer flow, but must take responsibility for solving the hard problems of integration. With these languages, developers have to write their own integration logic or use bolt-on frameworks. Clearly a new programming paradigm will be needed long term.

4. The Exploding Endpoint Problem is very real.

As I referenced above, IT is ill-prepared to address the oncoming wave of service disaggregation, the diverse types of APIs, differing sources of service endpoints, challenges from Big Data, and multiple approaches to serverless IT. The industry is about to hit a scale and diversity wall. To wit,

  • 917 apps in use per enterprise (Netscope, 2016)
  • 893-1206 average cloud services used per employee (Kleiner Perkins, April 2017)
  • 19,000 APIs as-of January 2018 (Programmable Web, 2018)

And if you don’t believe those numbers, Matt Eastwood of IDC recently pointed out that the number of containerized services has expanding well beyond where VMs ever were. Yep, billions of programmable endpoints aren’t kid’s stuff.

Where does this leave us?

A new approach to addressing the future of integrating thousands-or millions-of endpoints could lie in a new programming language, Ballerina.

Ballerina is a simple programming language whose syntax and runtime have been optimized for the hard problems of integration. Its focus is integration – bringing concepts, ideas and tools of distributed system integration into the language. Based on the concepts of interactions within sequence diagrams, Ballerina has built-in support for common integration patterns and connectors, including distributed transactions, compensation and circuit breakers. And it supports JSON and XML, making it simple and effective to build robust integration across distributed network endpoints.

So, watch this space for future developments. And in the meantime, beware of the approaching wall.

Three Months in to PSD2 – Confessions of the WSO2 Open Banking Team

It’s been 3 months since the PSD2 compliance deadline and the dust is settling in. Or is it really? Just like when it started, the post PSD2 landscape is viewed from different angles. It has been called everything from a ticking time bomb to a slow burn to a never ending honeymoon period. We think the biggest surprise was that everyone thought that January 13 was the end. It wasn’t, it was the beginning.

When we created WSO2 Open Banking, we knew customer needs would be diverse and every technology experience we deliver would be unique. Turns out we were right. Our journey with WSO2 Open Banking has unraveled some interesting experiences while working with different stakeholders in this compliance ecosystem. Here’s what we learned.

Confession #1: (Almost) Everyone was late to the party

Everyone (including us) started counting down to PSD2 from 6 months to 3 months to 1 month. But the reality was, January 13 was just the date when PSD2 was implemented by the EU parliament as a European-wide regulation.

Several regions across Europe chose to deal with imposing PSD2 in their own way. We’ve been tracking the country-specific deadlines quite closely and about 46% are yet to set an official deadline for compliance. We believe that the final date for compliance will be when the Regulatory Technical Standards (RTS) come into effect in September 2019. That’s good news for us because there’s still a large viable market for compliance technology! ;)

Confession #2: Compliance confusion did not discriminate

Over the past several months, we’ve worked with many banks of different sizes across Europe and they all had similar questions:

This led us to believe that banks, regardless of size, require a lot of guidance in the compliance process. It’s a good thing we have a team of experts to do just that!

Confession #3: They came, they saw, they vanished

When PSD2 first started gaining traction in 2016, the knee-jerk reaction of every API management and integration vendor was “this is a goldmine of opportunity we cannot miss”. So they went head on into the market with an existing product. Come 2018 when the need for compliance technology has evolved, these “first mover” technology vendors have gone quiet.

It remains uncertain whether it was the lack of a well thought out strategy to keep consistent market demand, fintech domination, or not giving the compliance market the attention it deserved. One thing is for sure, this is a highly competitive market for technology vendors like us. But no complaints, we love a challenge and are pretty good at winning them!

Confession #4: API standards (and the organizations writing them) are a solution providers BEST friends

A lot of shade gets thrown at not having a common API standard across Europe (version 1.1 of the Berlin Group API specification is yet to come, we’ve got our eyes peeled for that). However, Open Banking UK has got this in the bag by having a comprehensive API specification that WSO2 Open Banking supports.

When we first started out, these standards really helped set the base for building our solution. Our development team continues to spend a good couple of hours every week identifying latest improvements in the specifications and contributing to their development by participating in working groups.

Confession #5: Compliance is not a back breaker…it just needs a well thought out strategy

A lot of banks think of compliance as a major headache and seek a “quick fix” to compliance just so they can tick off the checkbox. The reality is, quick fixes can do more damage than good. PSD2 compliance is a big deal and if you go into it without a strategy, that’s cause for alarm. Even if you don’t have a dedicated open banking or compliance team you can still get the job done.

You just need to rally the right members, set your goals for compliance and figure out what you need from a technology vendor. Then you need to pick the technology that gives you value for money and won’t take eons to work with your systems and deliver compliance. It’s a matter of working closely with a solution provider towards a common goal.

Confession #6: Do your research or go home – The learning never stops

There is a minimum of 3 articles written a week on open banking. Everything from thought leadership material, opinion pieces (like this one), and publications from standards continue to explore and discuss this ecosystem. And what we learn from our conversation with customers is an invaluable source of research to keep abreast of where the market is heading. We treat each of these as a unique source of intelligence and they continue to nurture our product management, sales, and marketing strategies. It’s the only way to survive in an ecosystem as dynamic as this one.

It’s been a great ride so far and we can’t wait to see what comes up next! No doubt there will be plenty more surprises and exciting developments to look forward to!

The WSO2 Open Banking Team

Why Swiss Chocolate Relies on WSO2

The Swiss Federal Office of Information Technology, Systems and Telecommunication (FOITT) is one of the internal ICT service providers in the Federal Administration. It supports the administration by developing and providing efficient, secure, and user and public-friendly IT solutions. As part of its responsibilities, FOITT manages more than 40,000 enterprise users of two of their key platforms – one an electronic customs declaration process for imports/exports and the other, an automated way to manage revenue from taxes.

While these platforms have proved successful, FOITT embarked on a digital transformation initiative to make these more efficient. What they had hoped to achieve was the ability to scale to provide a more seamless experience to users.

At WSO2Con US 2017 Dr. Gion Sialm, chief architect at FOITT, explored how they leveraged WSO2 technology to achieve their objectives. They worked together with Yenlo, a WSO2 Premier Certified Partner, to implement their solution. To illustrate how the two platforms work, Gion took the example of Swiss chocolate – the process of importing cocoa to make chocolate and the distribution of the end product within and outside Switzerland.

The e-Dec (Electronic Declaration) Platform

All goods, and in this instance the import of cocoa and export of chocolate, need to be declared and there’s a specific process that needs to be followed. Given that it’s a fairly complex process involving many functions and stakeholders, FOITT created the e-Dec platform to simplify this process. What it essentially did was digitize this process and made it more efficient and user-friendly. As with any digital platform, the e-Dec platform too needed to be refreshed and revamped to be more aligned with new requirements.

For instance, the platform had a lot of different protocols and some were extremely outdated like POP3S and FTPS. Apart from this challenge, the application was based on the Oracle WebLogic Server, which follows the eXtended Architecture (XA) pattern. “Previously, WSO2 products didn’t support XA, but because of FOITT’s requirement, it’s now a part of their feature list,” noted Gion.

The Fiscal-IT Platform

On the retail side, all goods, like chocolate, sold within Switzerland carries a value-added tax (VAT). Previously, these transactions were done manually so FOITT built the Fiscal-IT platform that automated this process. Again, like the e-Dec platform, this too required improvements to further streamline this process.

For instance, the platform was created in a modular manner so as to have the best of breed technology for each feature resulting in a mix of multiple different technologies, like FileNet, Java and SAP, which all needed to be integrated. “Because we decided to employ microservices, we ended up with a lot of REST and SOAP APIs as well as JMS so we needed an enterprise service bus that was flexible enough to maintain these things easily,” said Gion.

The WSO2 Solution

They followed the same architecture for both platforms so as to reduce cost and speed up their go-to-market. The API Gateway, Publisher and Store components of the WSO2 API Manager as well as the WSO2 Identity Server as the Key Manager were used as their core API management solution. WSO2 integration technology was used for routing and message transformation between the sender’s and receiver’s different protocols. WSO2 analytics (not pictured in the architecture diagram above) also plays an important role in the solution — FOITT, together with their service providers, developed a dashboard using WSO2 Data Analytics Server to identify any problems that occur in the application. The user just has to type in the source and destination program and within a few seconds the metadata of all the messages is collected (message tracing) so that errors can be easily identified. The dashboard can even correlate the messages with the log files, which is a very important feature in a distributed landscape like this.

“WSO2 products relate to digital transformation like the Swiss army knife relates to MacGyver. Our platforms are evolving rapidly. In order to keep pace with this innovation it’s important to have a strong relationship and collaborate well with WSO2,” says Gion. “Automation is also key. We have to manage 11 stages throughout our platforms and doing it manually would be quite impossible,” he adds.

To learn more about how FOITT is leveraging WSO2 technology for key government initiatives, watch Gion’s presentation at WSO2Con US 2017:

Travis Perkins: Disrupting the Retail Industry with WSO2 Integration Technology

Travis Perkins, UK’s largest supplier of building materials, embarked on their digital transformation journey last year in the hopes of enhancing customer experiences, growing their business and improving the usability of their systems. At WSO2Con EU 2017, Christopher Stone, the head of integration at Travis Perkins, talked about the steps they took to go digital with the help of WSO2 technology and key partners.

To help understand Travis Perkins’ current situation, Christopher used an analogy coined by their previous CIO Neil Pearce – the house of IT.

By looking at all the areas of the house that need improvement, Travis Perkins realized that they needed to adopt integration technologies that would allow their systems to be flexible, future-proof, innovative, and reactive. “Integration is the plumbing, electrical wiring, and foundation — basically the rooms of the house,” said Christopher. “Effective integration and quality data are the key enablers for our digital agenda that is built on a solid foundation such as reliable cloud infrastructure and networking.”

Once Christopher explained this analogy, he explored how they previously worked on integration projects. He would most likely be a part of a program delivery team who is pressured to deliver fast and within a strict budget. This hinders their vision of the overall enterprise benefits and results in a point-to-point spaghetti architecture that leads to high maintenance costs, difficult to support, inconsistent standards, reliability issues, and limited reusability.

Today, Travis Perkins has a central integration layer powered by WSO2 integration and API management products. Services are developed according to project requirements, but built with the entire enterprise in mind using a set of policies, patterns, and standards governed by the project diagnostic team. This results in maximum reusability, easier support and maintenance, and continuous improvement in delivery, quality, and speed. The replacement of their core ERP system from a legacy system to an ERP vendor named M3, for sales order entry, sales order management, pricing, tool hire, finance, and supply chain is the largest program Christopher’s team is currently delivering on. But they have been involved in various other integration projects too. “The right tools combined with the correct mindset, architecture, and governance allows you to meet your goals in achieving good enterprise integration which benefits your company as a whole,” he says.

Many external parties helped Travis Perkins along their journey. In their early days, Wheeve, integration technology experts partnered with WSO2, gave them a theoretical and conceptual mindset on how an integration department should run. They helped set up the department and build up the team and aided them with their architecture and processes. During the delivery phase, Travis Perkins’ engineers and analysts were supplemented by ICT solutions providers partnered with WSO2 — Chakray and Mitra Innovation. They offered integration specialists well-versed in the WSO2 platform who helped analyze the requirements and worked in an Agile Scrum fashion to deliver the projects. “They have helped us come leaps and bounds, not only in delivering projects but also in terms of learning from their experience and knowledge of the WSO2 platform,” said Christopher.

“WSO2 is a great platform. It enables us to deliver quickly and compliments our strategy to utilize open source technology wherever possible,” Christopher concluded. “When any of our engineers come across difficulties in development, the WSO2 Subscription gives us great SLA’s. We don’t need to use production maintenance support very often, but when it does happen we have a very good relationship with WSO2 for them to support us in getting back to business as usual.”

To learn more about how Travis Perkins is successfully traversing its digital transformation path, watch Christopher’s video at WSO2Con EU 2017 below.

Bringing an Efficient Home Care Solution to Life with WSO2 Technology

Senior citizens and disabled people—many in fragile health and requiring assistance—often have limited resources for managing their health and ensuring their security. Effective home care solutions allow such people to safely go about their day-to-day lives and enhances their quality of life. To aide home caregivers and patients, Raffaello Leschiera, a solution architect at Engineering Ingegneria Informatica, proposed a reference architecture for efficient home care using WSO2 technology at WSO2Con EU 2017.

Raffaello began by exploring the proposed reference architecture that connected and interfaced with all stakeholders, like the patient, his/her family and medical staff. Firstly, they need to collect data from medical devices in the patient’s home. Protocols like IEEE VU specifications are used and medical devices are mediated using Arduino and Raspberry Pi boards. Once collected, the data needs to be normalized and stored so it’s represented in the same way no matter which device it was collected from.

This data needs to run through analytics to monitor the patient’s health, process events and if needed, send notifications through various communication channels. Data integration channels using the HL7 standard protocol for health care is used to send this data to medical staff. The medical staff can then access it through web and mobile interfaces and an API gateway decouples all features from these user interfaces. And finally, the entire system needs to be synchronized and controlled by identity and access management to ensure security and privacy.

Reference architecture for a home care solution

Raffaello noted that WSO2’s comprehensive technology platform, particularly its integration and analytics capabilities, were the main reasons for picking WSO2 as their technology partner. The open source nature of the products was also a key deciding factor since Raffaello and his team work with many public administrators who prefer to adopt solutions that are completely open source. “WSO2 has a wide technology platform so you can find the right answer to every part of your problem,” said Rafaello. “And because all the products seamlessly integrate with each other it’s easy to focus on the domain problem rather than the technology problem,” he added.

To describe how WSO2 products were used for different tasks, Raffaello compared the home care solution to a football game:

  • Goalkeeper: WSO2 Microservices Framework for Java (WSO2 MSF4J) serves as the goalkeeper. This is the entire back-end of the system, which is based on lightweight microservices that are developed, deployed and monitored through MSF4J in a highly scalable and reliable manner with integrated security.
  • Defenders: WSO2 Data Analytics Server serves as one defender that receives data, analyzes it in real-time, and sends notifications. WSO2 Enterprise Integrator is the next defender who transforms disparate types of data into a normalized format and sends it to the hospital IT systems.
  • Forwards: WSO2 API Manager is one of the forwards, which faces the medical staff and is used to design, prototype and publish APIs and govern API usage. WSO2 IoT Server is another forward, which faces the medical devices for data collection, device management and protocol support.
  • Wings of the pitch: Here the WSO2 Identity Server takes care of all the strict security and privacy requirements.
  • Center of the pitch: Finally, WSO2 Governance Registry serves as the ‘Lionel Messi’ at the center of the pitch; in other words it governs the solution through surveillance just like how Messi would guide and lead his team to victory.
  • For this solution to work, Engineering Ingegneria Informatica needed a remote device that can track a patient’s movements within his/her home. Enter Joe Care (or the Joker pictured above). Joe Care is a remote presence device that is flexible and agile enough to move around the patient’s home. They used various technologies like Arduino boards, software that deals with movement and the sense of space as well handling (touch). It served as the medical eyes, ears, voice and fingers within the patient’s home.

    In the future Rafaello and his team aim to engage with users more, further analyze threat paths and include more technology like wearables that monitor movement and exercise. They would also like to create more intelligent early warning score models and move their entire solution to the cloud so more patients and operators can access it.

    Watch Rafaello’s presentation at WSO2Con EU 2017 below to learn more about their home care solution powered by WSO2.