Category Archives: Customers

Improving Coordination for Natural Disaster Responses with a Geospatial Data Sharing Platform

Photo credits:a befendo on Unsplash

GeoDASH is a geospatial data sharing platform in Bangladesh built using the open source GeoNode. It is supported by the Global Facility for Disaster Risk Reduction (GFDRR) – operated via the World Bank in Bangladesh – and implemented by the ICT division of the Bangladesh Computer Council (BCC). GeoDASH enables government agencies, private enterprises, academic institutions, and the public to manage, share, and visualize geospatial data. WSO2 API Manager is used to integrate multiple services and provide secure access to GeoDASH.

Data Sharing for Better Disaster Preparedness

GeoDASH came into being in 2014, when a roadmap was initially published as a means to facilitate the sharing of data between government agencies and help improve disaster responses. The beta version of the platform was launched soon after and a data sharing working group comprising of 11 key government agencies was established. Ownership of GeoDASH was transferred from GFDRR to BCC in 2015, and the project received media coverage the following year too. More recently in 2018, Bangladesh decided to integrate GeoDASH to the country’s National Spatial Data Infrastructure (NSDI) policy.

At present, GeoDASH consists of more than 50 organizations, 250 GIS maps, and over 500 users! Yet, the data belongs to the respective organization that uploads the data, making data sharing a challenge. To add to this complexity, further platforms are being introduced in addition to GeoDASH and NSDI. These include the Urban Resilience Project which aims to increase the capacity of government agencies to respond to emergencies and reduce vulnerabilities of areas in Dhaka and Sylhet. As a part of this project, the Dhaka North City Corporation plans to build another platform named UrbanSDI/MSDI. And finally, another SDI platform exists at the BCC.

Addressing Needs and Challenges

Given the number of platforms, interoperability is a must and this did not exist at the time. Furthermore, there was a lack of standardization and collaboration, due to the various organizations developing their own e-services; a central platform to search for all e-services was absent; security and monetization were issues of concern; and a collaboration mechanism was needed for data sharing.

Guidance is provided in the form of the Bangladesh National Digital Architecture, which is a holistic approach adopted to provide e-services for citizens. This framework addresses the inclusion of a national e-services bus for better coordination and collaboration, standardization of e-services, reuse of shared e-services, cost-effectiveness, and the improvement of e-governance. The framework also introduces the National e-Service Bus, built using WSO2 API Manager; an open source API management platform that addresses the full API lifecycle, monetization, policy enforcement, and even allows customization as required.

WSO2 API Manager has enabled integration and access of e-services, access control, security and monetization, interoperability, and the sharing of services and documentation. Services integrated to date include: food procurement, online internal recruitment, national identity database verification, government employee verification, geospatial data, birth and death registration, e-pensions for the education sector, a digital municipality system, and the ‘Alapon’ app for information sharing in the public sector. The implementation has met the objectives and improved both operational efficiency and coordination. Mohammed Abu Hamid, a consultant for the GeoDASH system at The World Bank, is optimistic about more successful integrations and registration of services in the future.

Learn more about GeoDASH, challenges faced, and future plans from Hamid’s talk.

We were named a Leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report. Get the report here and learn more about WSO2 API Manager here.

A Citizen Centric e-Government Journey From Bhutan

Photo by Karen W Lim on Unsplash

Bhutan’s information and communications technology (ICT) policy is an integral part of the country’s holistic approach to socio-economic development. Their ICT journey began in 1999, with the introduction of the Internet. Since then, the country’s ICT infrastructure has reported significant growth, with mobile connectivity coming in at over 93% in 2018. The Royal Government of Bhutan’s Department of IT and Telecom (DITT) is responsible for framing the country’s ICT policy, developing ICT infrastructure, innovating, and promoting ICT as a whole. DITT uses the WSO2 Integration Agile Platform to provide online services in accordance with their citizen centric e-Government policy.

Centralized Infrastructure to Improve Efficiency

DITT began using WSO2 Enterprise Integrator (then named WSO2 Enterprise Service Bus) in 2010 to facilitate the provision of online services to citizens and extract information from the national citizen registry. They also began setting up a private network, which connects all government agencies from the centre to the local level. DITT centralized their government infrastructure in one government data center to improve efficiency. Standards were also introduced, as various government agencies had invested in monolithic applications independently, without following any particular form of standards. “We believe that the greatest benefits from technology can be gained by the state, if we make the optimal investment in ICT – rather than have every single agency investing in silo,” elaborates Jigme Tenzing, chief ICT officer at DITT.

Accordingly, the e-Government Policy of Bhutan is citizen centric and aims to strengthen the coordination and collaboration between government agencies. This e-Government policy is defined by the following:

  • It is digital by default – any new service, or reforms, relies on adopting technology.
  • ICT assets are shared to ensure cost-effectiveness and reduce any duplications and inconsistencies of data sharing.
  • Data owners are responsible for data collection, updating, and sharing – to avoid duplication and reduce errors/inconsistencies.
  • Information security and privacy are treated as a collective responsibility.
  • Business initiatives drive change requests and procurement of IT infrastructure.
  • e-Government projects work on a sustainable model for continuity.

A governance structure has also been implemented to manage, implement, and regulate this policy. This structure consists of a Review Committee, which is a technical body comprised of technical professionals who perform the initial review of systems and identify if there are any issues with maintaining consistency, and whether or not an investment needs to be made in the first place. Then there is an Executive Committee, which decides on financial/budgetary concerns and manpower, above which is a Government Council made up of government secretaries who communicate with the Cabinet.

One Government Approach

This approach is underscored by the need to provide a single platform, which citizens utilize to access services from the government with a single sign-on mechanism. This architecture’s information exchange layer is built by using WSO2’s integration and analytics products and identity management is managed by WSO2 Identity Server. WSO2’s integration platform – WSO2 Enterprise Integrator – provides a centralized enterprise service bus (ESB) with data and process integration, along with B2B integration capabilities. The analytics platform – WSO2 Stream Processor – understands streaming SQL queries in order to capture, analyze, process, and act on events in real-time; facilitating streaming data integration and analytics. WSO2 Identity Server is optimized for single sign-on and identity federation, with comprehensive support for strong authentication.

Data access is provided as APIs (and not via the integration layer). Hence, the architecture also consists of WSO2 API Manager (which provides full lifecycle API management, application development, access control, and rate limiting) to allow data access, after authentication by WSO2 Identity Server. This architecture also consists of other open source tools in addition to WSO2. “We still have some work to do, particularly identifying the custodians of data, but we have a lot of expectations from this architecture,” concludes Jigme.

To learn more about Bhutan’s e-Government journey, watch Jigme’s presentation on the topic.

WSO2’s integrated platform provides open source technologies for API management, enterprise integration, identity and access management, and streaming analytics. Learn more about us here.

We were even named as a Leader in the Forrester Wave™: API Management Solutions, Q4 2018 Report. Access the report here.

You can also read KuppingerCole’s Executive View of WSO2 Identity Server here.

An Integration Platform in Luxury Fashion – How Farfetch Delivers Value to Partners and Customers

Photo by John Schnobrich on Unsplash

E-commerce platforms in the luxury fashion industry occupy a small portion in the wider online fashion e-commerce industry. Established in 2007, Farfetch offers a leading online platform in the luxury retail industry, connecting brands, boutiques, partners, and the end customer. When looking at the numbers, currently over 1,000 boutiques and brands sell products using the Farfetch platform. Farfetch serves over 2 million users in 190 countries (plus, the Spring/Summer 2018 season alone had 5.7 million units of items stocked in the platform). Their online business operations are driven by an integration platform, built by using WSO2 Enterprise Integrator.

A scalable integration platform for a growing business

On a day to day basis, Farfetch communicates stock information between their partners and customers, manages orders and returns, and handles the logistics on behalf of their partners. Several years ago, Farfetch requested their partners to integrate with their architecture and built a SOAP API to facilitate this integration. However, with time, the partner network grew and integration became even more important, and Farfetch realized the solution at the time was not scalable in the long term due to the lack of a relevant platform.

Therefore, in 2016, Farfetch built their own integration platform named FFLink using WSO2 Enterprise Integrator, an agile integration platform that helps enterprises to build and scale integration solutions. FFLink is based on 2 components. The first component is universal plug-in, where Farfetch built a plug-in for a system that is used by multiple partners whilst ensuring scalability of the system. The second component targets their top partners, with whom Farfetch embarks on custom projects depending on the business case. In this instance too, scalability is important. In theory, Farfetch prefers to provide out-of-the-box integration options for their partners although in practice, this is not always possible as some of the bigger brands have custom API layers on top of their system, rendering it difficult to use with other partners. With FFLink, partners now integrate using the same API as Farfetch and the plug-ins.

Building the architecture to overcome challenges

In recent years, Farfetch has been nearly doubling their growth rate every year (sometimes more). One of the challenges now is no longer the integration platform – but managing and scaling this platform, along with the partners. Furthermore, Farfetch is also looking at discontinuing the use of their API which they introduced at the start but some partners continue to use it. This discontinuation process cannot be abrupt and they’ve introduced a process by which these partners will graduate start using FFLink. To do this, Farfetch has exposed one API to their partners, which they will then connect to their new and modern REST API internally. This ensures that Farfetch continues to support all their partners (including the ones using the original API) and simultaneously ensure their internal architecture continues to evolve and deploy new APIs.

The challenges don’t end there. Although Farfetch is satisfied with the way in which they were able to create FFLink and deliver value to their partners, they experienced some difficulty in supporting and maintaining all their partners. As such, they began to look at ways in which they can modify FFLink further, taking into account issues of scale, business growth, partner management, and support. They then introduced the second version of FFLink – which is an event driven architecture. Every transaction received by FFLink is transformed into an event. All orders that are synchronized between Farfetch and partners are transmitted through a central event service, regardless of the source system or the target system. This has eased the monitoring and scaling functions for the team at Farfetch. The main role of this architecture is to discover events. For example, when the system receives a new order, APIs are pooled by Farfetch and their partners to find this new order after which an event is created. However, not all partners use APIs and some of them still use files – leading to problems. In order to deal with this, Farfetch has built storage services in the system whose function is to discover and manage events that are triggered using files. Partners who use APIs are able to create events via the API gateway in the integration platform, through the exposed APIs.

Once an event is created, synchronous ones are published on the messaging, overseen by the orchestration layer. Asynchronous events trigger the orchestration layer, which turns it into a message and transforms it as needed. This is where WSO2 Enterprise Integrator plays a key role, helping Farfetch to scale this platform and build the orchestration layer. WSO2 Enterprise Integrator has integration runtimes, message brokering, business process modeling, analytics, and visual tooling capabilities.

Benefits

The new architecture has allowed Farfetch to set up a central back office, helping them to configure, manage, and monitor the system. This has helped them to anticipate and communicate any problem that they encounter to their partners, thereby ensuring the smooth day-to-day management of their functions – something which the team at Farfetch values greatly, given the continued growth of their business.

To learn more about FFLink, watch this presentation by Vasco Rocha, head of engineering, platform services at Farfetch.

Find out more about WSO2 Enterprise Integrator here.

Lindex: Innovating with APIs in the Fashion Retail Industry

Fashion is a dynamic industry and any fashion retail business needs to be as agile as possible, particularly in the present era of e-commerce and instant customer gratification. This is a reality that the Scandinavian based fashion chain Lindex is all too aware of, having been around since the 1950s. Currently Lindex has 470 stores in Scandinavia, Central Europe, Baltic states, Middle East, and the UK, with an employee base of over 5,000. Their business is underscored by sustainability, as 55% of their clothing is made from sustainable materials. Lindex decided to enhance their digital services by exposing APIs over their existing monolithic architecture. This enabled them to build applications that improved user experiences for both customers and employees.

Move With The Times

15 years ago, Lindex began their first foray into e-commerce. This was very much an experimental project, where a team was tasked with designing a platform and more importantly, monitoring customer responses to such a platform. Lindex started with a monolithic architecture which had worked satisfactorily for a decade. But there was a snag – they had accumulated a lot of technical debt over the years and moreover, security models had changed. It was time to try something new. Lindex considered open source, as they understood that it provides greater extensibility and flexibility when building a solution.

That something new was the development of a customer loyalty app – their change agent. Lindex wanted an omni-channel app which gave users a hassle free experience, with product information, prices, and promotions being shared between the app, website, and stores. They were clear that they did not want to integrate this new system with the existing monolith and furthermore, they also knew that a new team was needed.

The new platform consisted of customer loyalty app, the new ‘My Store’ app, and other customer experience solutions on the top layer, all to be exposed via an API layer. Once Lindex had completed the implementation of this first set of APIs it immediately became apparent that different levels of complexity within the backend systems would require different versioning of each of the created API’s moving forward as each monolithic application was adapted to become digital. It was recognized that the team would require some form of management for the API framework and a business case was undertaken to assess a number of API Manager systems which complied with industry standards and more importantly, would work seamlessly with their existing customer repository. Lindex also had a preference for a security solution that was able to work seamlessly with their existing customer repository. These requirements, along with the need for an open source solution, led them to WSO2 API Manager (which addresses API management, development, and integration). They also chose WSO2 Identity Server, which is optimized for identity federation and single-sign.

Multiple Teams for Multiple Customer Experiences

While the app team was developing the new application, Lindex’s team responsible for their existing monolithic architecture was busy refactoring the code in order to expose functionality in the customer shopping experience – i.e. features like shopping cart, wish list, pricing, promotions, and order details. They also had other development teams working on other areas of customer experience simultaneously. The ‘My Store’ program was upgraded, they were able to create a ‘My Stock’ app and a ‘My Customer’ app (when in-store personnel were acting on behalf of customers). During the complex process of setting up multiple levels of authentication across different user groups, Lindex found that WSO2 Identity Server provided the authentication capabilities needed for these apps. In total, there were 5 teams working on enhancing customer experience and there are plans for expansion.

Like their initial venture to e-commerce, this project has also been an experimental one for Lindex, to understand what works best and adds business value. They now believe that a gradual replacement of backend functionality is what works for them. “Thanks to WSO2 and the open source model, this has been a breeze. It’s been risk-free for us. The middleware has been rock solid from the get-go really,” says Johan Edling, an enterprise IT architect at Lindex.

Some Lessons Learnt Along the Way

Lindex gained some valuable insights when they worked on this project, and if they were to return to square one, their key advice to others starting this journey would be as follows:

  • Set up API statistics right at the start of the project, even if it looks expensive at first glance. Failing to do so is not the best course of action.
  • Time is always important – time must not only be allocated to the development of API resources, but to changes you anticipate as well.
  • Perform automatic testing of API resources and ensure that teams working on the project have the relevant API development skills are things to consider.
  • Document error handling guidelines.

With the new API design in place, Lindex now offers a modern shopping experience for their customers.

For more details, watch Johan’s talk.

WSO2 was named a Leader in The Forrester Wave ™: API Management Solutions, Q4 2018 report. Check it out here and learn about WSO2 Identity Server here.

Achieving GDPR Compliance in Heraklion, Crete

The city of Heraklion, capital of the Greek island of Crete, is many things – it’s a tourist attraction, a port and ferry dock, and a smart city. In fact, Heraklion was recognized as one of the world’s 21 smartest communities in 2014 and even has a technological university. As a tech-driven city, the Municipality of Heraklion decided to build a web portal for more than 6,000 users and a case management system for 700 employees. Also in this plan was the creation of an email system based on Postfix and Horde, mobile applications for the convenience of both citizens and employees, an e-payment gateway, and several WordPress sites for affiliated organizations of the municipality.

Solution Requirements

The IT infrastructure of the Municipality has multiple applications and users. And both ITDT and the Municipality wanted to create unique user profiles (and avoid duplications), a single-sign-on process for users, provide authentication mechanisms and very importantly, achieve GDPR compliance. A team comprising of the University of Crete, the National Technical University of Athens (NTUA), and ITDT Solutions (a company based in Cyprus working with a range of customers in Cyprus and the Balkans) worked with the Municipality of Heraklion to achieve these ambitious goals.

The new solution had a list of proposed items for successful project completion. The starting point for this project was the creation of a new LDAP infrastructure based on OpenLDAP (the LDAP infrastructure which existed at the time needed upgrading). User migration had to occur from the web portal’s database and other applications. Identity management is a huge requirement and the team used WSO2 Identity Server and the national identity provider for advanced security services. And the final important item was the migration of applications to SAML2 and OAuth2.

GDPR Compliance Made Easy

GDPR compliance and its importance led the project team to WSO2 Identity Server, which as an identity solutions provider, is GDPR ready. This meant that ITDT and the rest of the team did not have to do much to become GDPR compliant by themselves. ITDT created a single user store for convenience which simplified the process (the other option was to become compliant for each and every user store and application). The self-care user portal of WSO2 Identity Server plays a crucial role in GDPR compliance since it functions as a medium for users to exercise their individual rights as defined by GDPR for data managed and retained by WSO2 Identity Server. This self-care portal allows users to access and rectify any information about themselves at any point of time. Users can also request portal administrators to delete their entire user account if needed. It also enables users to revoke consent and exercise their right to be forgotten, in addition to providing them with a portal format of storing data, the right to pause/ restrict data processing, and of course, transparency on how their data will be processed.

WSO2 Identity Server comes with other perks as well. For one, it enabled ITDT and team to build a central identity so they migrated all their user stores to the central LDAP infrastructure by the project’s end. Secondly, WSO2 supported various inbound authentication mechanisms (SAML, OAuth, JWT, etc). Lastly (and best of all) is that WSO2 Identity Server is open source. This project did not have the most generous budget, and the Municipality of Heraklion needed a solution that did not have extra licensing costs attached to it. WSO2 Identity Server has an Apache 2.0 license, thereby giving the team heading this project the freedom to use this solution.

Benefits and Expansion

Apart from creating a robust solution to achieve GDPR compliance, ITDT has been able to create unique user experiences and reduce development costs for the Municipality. A digital transformation project of this nature (or indeed any such project), naturally provides insights to the team leading it by the project’s end. What ITDT learnt was that the migration of user stores is harder than they had initially anticipated as it required a lot of manpower. The team also learnt that WSO2 Identity Server is an ideal platform for creating custom solutions whilst keeping the core solution unchanged. Given the success of this project, the next step involves expansion – to other applications in Heraklion city and to other municipalities in Crete. Data exchange between municipalities and universities in Crete, and creating loyalty schemes between public and private bodies are other areas of interest. Identity management will continue to play a central role in all these plans.

Watch this presentation to learn more.

WSO2 Identity Server can be used for a host of identity management requirements, check it out here.

This article helps you understand how WSO2 Identity Server helps you achieve GDPR compliance.

Medical Device Integration for Better Decision Making in the Healthcare Industry: A Case Study From Engineering Ingegneria Informatica S.p.A

Medical devices that communicate with one another…sounds futuristic (or like something from a science fiction movie or novel), but it’s happening today. Engineering Ingegneria Informatica S.p.A, an Italian based software solutions provider, developed a Medical Device Integration (MDI) solution that enables devices to communicate securely, efficiently, and intelligently, enhancing patient care and monitoring capabilities. And to create their solution, they rely on the entire WSO2 Integration Agile platform.

Medical Device Integration with the WSO2 Integration Agile Platform

MDI comes with its distinctive set of challenges. Communication between medical devices is complex, hence each device needs a standard and secure communication protocol based on multiple channels. Then there’s the issue of processing thousands of events. A large hospital has a multitude of patient data, generated from thousands of sources. Engineering Ingegneria Informatica S.p.A needed to analyze these events and view patient data in the form of trend lines on customized dashboards. Also needed were monitoring dashboards displaying data regarding the status of devices.

The architecture behind MDI makes use of WSO2 Identity Server, WSO2 API Manager, WSO2 Enterprise Integrator, and WSO2 Stream Processor, along with WSO2’s IoT platform (now developed and supported by Entgra). To begin with, WSO2 Identity Server – a holistic identity and access management product – makes this solution and communication between components secure by using protocols such as OAuth2 with JWT tokens. This identity platform also generates tokens to access WSO2 API Manager.

WSO2 Enterprise Integrator facilitates all the communications in this solution and comes with integration runtimes, message brokering, and business process modeling capabilities. This agile integration platform is responsible for communicating with external modules, between the various devices and the central MDI system, and with Terminology Services to perform compensation and transformation of incoming/outgoing streams. Furthermore, WSO2 Enterprise Integrator provides technology for this solution to generate alerts or notifications from MDI to application solutions.

WSO2 Stream Processor – a lightweight stream processing platform – analyzes clinical messages from the device driver in real-time. Technical and clinical information has been divided into different complex event processing (CEP) flows. This makes it possible to manage technical warnings or CEP feeds of clinical data, and the machine learning component acquires and refines classified algorithms to help predict critical situations. WSO2 Stream Processor, in particular, has helped Engineering Ingegneria Informatica S.p.A to address the challenges of processing and analyzing the many events and the need for a customized dashboard.

The IoT capabilities are used to develop device drivers with installation packages. Each device driver has a health module that transmits technical information (which ranges from data like the heartbeat to the status of components). Each driver is also able to transform specific device protocols (such as RS232, HL7, etc.) into an encrypted generic platform message, thereby eliminating the need for MDI to identify each protocol.

The Benefits for Patients in Real Life

There’s quite a complex architecture in operation, so how does it function in a real-life situation? Marco Mastroianni, a software architect at Engineering Ingegneria Informatica S.p.A, explains how their solution applies to an Intensive Care Unit (ICU). Patients in the ICU are dependent on monitoring and life-sustaining devices where the use of information from combined (or integrated) data sources play a critical role in predicting a patient’s condition. Underpinning everything is time and the speed of communication. In such environments, monitoring capabilities and notification mechanisms come to the foreground. The data generated by these devices appear in the form of signals which is of value to signal processing techniques. Therefore, this process helps to both monitor patients and design algorithms that are used to implement patient alarms.

Patient monitoring is not limited to hospital premises – the MDI solution helps to monitor them in their homes too. Monitoring is dependent on communication between devices, how they’re managed, and how patient data is received by medical professionals. An MDI solution such as this reduces the probability of errors (particularly human errors) – greatly supporting the wellbeing of patients and the quality and speed of decision making.

You can listen to Marco’s presentation for more details on the MDI solution built by Engineering Ingegneria Informatica S.p.A.

WSO2 offers an open source integrated platform for digitally driven organizations who want to become integration agile. Everything you need to know is here.

Scaling Single-Sign-On with the Swiss Alpine Club

Mountain climbers and hikers in the Alps need reliable assistance, and that’s exactly what the Swiss Alpine Club (SAC) provides. Established in 1863, SAC is passionate about alpinism. They’ve contributed to the development of the Alpine region over the centuries and are advocates of safe, responsible mountaineering whilst ensuring free access to the mountain world.

Today, SAC has approximately 150,000 members, 111 sections in Switzerland that manage 153 mountain huts. On average, SAC sees 1 million daily visitors to these huts. SAC offers a range of services to both members and non-members. They have a SAC route portal, manage an online store with SAC products, offer discounts for accommodation, organize educational and training opportunities, and much more. Furthermore, SAC relies heavily their 7,000 volunteers who work as officials, guides, and youth organizers. These volunteers are supported by SAC’s IT office, which is located in the Swiss city of Bern.

Integration and Identity Management for User Convenience

SAC defined their digital strategy 2 years ago, and the cornerstone of this strategy is easy usage and access of services for their members and non-members. To this end, they had a straightforward set of goals which include: one identity login across all SAC services, single-sign-on (SSO) to access different services, easy onboarding of members, and to provide self-management of user accounts. SAC has around half a million users (this number keeps growing daily) and there are about 6,000 roles. Given the number of roles and types of membership (for example, officials, wardens, subscribers, etc.) means that there is a quite complex identity management structure at SAC.

SAC worked together with WSO2 Certified Integration Partner Avintis to implement their strategy. Right from the beginning of this project, both SAC and Avintis agreed on the consolidation of SAC’s user store. SAC’s new solution is composed of 2 parts – one part is concerned with integration and the other focuses on authentication, powered by WSO2 Enterprise Integrator (which can be used to build, scale, and secure integration solutions) and WSO2 Identity Server (which is a uniquely flexible product for identity needs) respectively. Being open source, both WSO2 Enterprise Integrator and WSO2 Identity Server provide SAC with a solution to avoid vendor and data lock-in, and use open standards for identity management and integration. This also further enables SAC to keep abreast with ever changing market needs.

The solution has a bi-directional integration with Microsoft Dynamics NAV and WSO2 Enterprise Integrator. They’ve also implemented REST based web services. This solution also consists of one master user store, with multiple service providers. At present, they have 6 service providers but this could potentially increase to 100 depending on the speed at which their implementation progresses. SAC translates their business cases to their user store and assign the right roles in the user store. They’ve created a login app on top of WSO2 Identity Server, which received the customer services that passes through WSO2 Enterprise Integrator. Furthermore, the identity management component follows the OpenID connect protocol.

The Result: One Login App for Everything (Literally)

SAC has reduced their data silos with the new solution. The resulting single login app facilitates user authentication, registration, membership applications, account activation, and password resets. Users can now book accommodation, subscribe to SAC services, shop in the online store, and access any other service with one single identity.

SAC’s plans extend beyond creating a seamless and convenient user experience. They’re now looking at WSO2 API Manager (which can be used to address any spectrum of the API lifecycle, monetization, and policy enforcement) for secure access to and management of upcoming/ existing APIs. In order to achieve scalability and reduce downtimes to zero, SAC runs most of the applications in Docker containers using Jelastic PaaS, and plans to migrate all of their web infrastructure to this cloud platform.

With plenty of changes anticipated in the near future (along with rising numbers of visitors to the Alps), Daniel Fernandez, head of IT at SAC, advises meticulous planning when undertaking a digital transformation project of this nature. And in addition to planning, he advocates being prepared for unexpected situations, as in his opinion a project such as this has an impact on everything else in an enterprise.

Listen to Daniel’s presentation for more details on how SAC implemented SSO.

WSO2 API Manager, WSO2 Enterprise Integrator, and WSO2 Identity Server form the WSO2 Integration Agile Platform. Learn all about our open source approach here.

Schneider Electric Uses API-driven Integration for Innovative Energy Management

Schneider Electric is the market leader in the digital transformation of the energy management and automation industry, with an annual revenue of over 25 billion Euros and around 150,000 employees in more than 100 countries. Schneider Electric makes it possible for IoT-enabled solutions to seamlessly connect, collect, analyze, and act on data in real-time. In doing so, they deliver enhanced safety, efficiency, reliability, and sustainability to their customers. The company helps its customers do three main things: enable them to to manage their efficiency better by optimizing their processes and energy usage; manage their energy supply better by integrating local production and managing energy sourcing; and lastly, manage their grid better through digitalization.

Addressing Changing Energy Needs Through Technology

Schneider Electric is keenly aware of the changing energy and technology landscape and knows that it needs to stay ahead of these changes in order to remain competitive. As the demand for energy continues to increase, Schneider Electric’s approach to solving this issue is to find ways of generating energy more efficiently. Using digitization and IoT, the company is looking at being three times more efficient in its energy demand going forward.
In 2015, Schneider Electric decided to move from solution-driven integration, to a service oriented architecture (SOA). This simplified how customers could access and consume services in a more standardized way, and also shielded them from the complexity of the back-end of the SOA systems. The digital team at Schneider Electric decided to use APIs to support the new SOA, and sought API publishers that would be able to expose APIs easily, and manage them effectively.

Schneider Electric chose WSO2 API Manager because it fulfilled all of their requirements while being open source and flexible in that it could be deployed on-premises or in the cloud. WSO2 API Manager was the ideal choice as it addresses full API lifecycle management, monetization, and policy enforcement as well as extensibility and customization.

They also decided to replace their legacy integration solution with WSO2 Enterprise Integrator in order to further support their API real-time strategy. WSO2 Enterprise Integrator is a comprehensive integration solution that enables communication between various disparate applications. Instead of having Schneider Electric’s various applications communicate directly with each other in all their different formats, WSO2 Enterprise Integrator would enable all of the disparate applications to communicate with the the product which handles transforming and routing of messages to their appropriate destinations. According to Tristan Solanet, integration platform owner at Schneider Electric, using WSO2 Enterprise Integrator has helped bring consistency across the company.

Deployment From Europe to the US and China

Schneider Electric began by deploying WSO2 API Manager and WSO2 Enterprise Integrator in a data center in Europe. The company uses both internal gateways and external gateways, the former for internal network usage and the latter has a subset of APIs published on them. As its customer base in the US expanded, Schneider Electric’s digital team decided to deploy select API gateways in North America using an Amazon virtual private cloud. This addressed the problem of latency that US customers had experienced when they had to call gateways in Europe in order to access information and support. The next step in Schneider Electric’s deployment strategy was to address the increasing demand from China. Taking into consideration the specificities of the Chinese context, Schneider Electric deployed additional gateways in China. Among the challenges the company faced was in making the connection between China and Europe work. The connection between the US and Europe through the company’s internal network had been a lot smoother than the one between China and Europe. Ultimately, it was decided that a second key manager be configured in China, in addition to the original one in Europe.

Schneider Electric’s partnership with WSO2 has enabled the company to share functional intelligence with their customers using log value. Custom dashboards have also been developed to suit the company’s needs using WSO2’s analytics capabilities. Metrics are monitored on a real-time basis on these dashboards and can be filtered for geographic region, period of time, and customer’s perspective.

EcoStruxure: An IoT Enabled Interoperable Platform

Schneider Electric also created EcoStruxure, an IoT-enabled, plug-and-play, open, interoperable architecture and platform. It is used in homes, buildings, data centers, and infrastructure industries and delivers innovation at multiple levels from Connected Products to Edge Control, and Apps, Analytics and Services. EcoStruxure has 6 domains of expertise – Power, IT, Building, Machine, Plant, and Grid and uses standard communication protocols to simplify the collection of data from intelligent devices around a customer’s organization. The data is then analyzed either locally using Edge Control or remotely in the cloud to provide the customer with critical insights to improve their business.

Interoperability is a key feature of EcoStruxure, facilitating the deployment of a range of agnostic applications, analytics, and services for seamless enterprise integration. To put it simply, EcoStruxure bridges IT and IoT and allows customers to maximize the value of their business data. Data is transformed into actionable intelligence which in turns leads to wiser business decisions. To date, deployment of EcoStruxure exceeds 450,000 installations, with the support of 9,000 system integrators, and over a billion connected devices.

mySchneider App: Showcasing Digital Transformation at Schneider Electric

The redesigned mySchneider App is one of the flagships of Schneider Electric’s digital transformation initiative. Distributors, partners, Schneider employees and increasingly, end-users use it to connect to the company’s digital hub. Based almost entirely on APIs, mySchneider App allows access to information on order management, support, partnership management, and a comprehensive product catalog. The app has been translated into 36 languages and has approximately 30,000 unique users a month. Each user has the ability to customize their interface with the app based on their user profile and country.

The benefits of an API-led connectivity approach include building reusable assets that save the company time and money, creating infrastructure that is flexible and designed for change, along with enhanced visibility, compliance, and governance. Projects are now delivered faster and team productivity is greater as a result.

Schneider Electric believes that by implementing SOA with an API-led connectivity approach, facilitated by WSO2, they have been able to drive business agility, provide customers with better customer experiences, and retain their competitive advantage as the world leader in the digital transformation of energy management and automation.

Watch Tristan’s talk to learn more about Schneider Electric’s plans to prepare for the future.

New to the WSO2 Integration Agile platform? Learn more about our technology for API management and enterprise integration, all open source!

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.