Category Archives: Products

Why We Make Our Product Roadmaps Public

“Can you please share your roadmap?”

“What are your plans to engineer feature xxx?”

“Great product, but does your vision match ours?”

We get these questions all the time, from customers, partners, and analysts.

As the leading open source API integration company, it seemed antithetical to be open and transparent about our code, financials, and priorities, but not about our actual product roadmaps.

So we’ve now opened-up our product and solution visions and roadmaps for each of our integration-related products, all part of our Integration Agile platform:

Why would we do this?

There are a number of reasons we chose to take this bold step – a step that most high-tech companies shun as competitively risky, and thus guard their plans with absurd paranoia.

  • Public roadmaps are consistent with our open source community
  • We trust our community to work with us, and they can only do so if they know our plans. That way they are always involved in the technology and will be able to best deliver meaningful new features, contributions, and roadmap suggestions.

  • Public roadmaps signal our transparency
  • Transparency is key to building trust between partners. A public roadmap helps committers, partners and customers to know we’re pulling no punches with our direction. It’s also consistent with our no-lock-in approach… and that means there’s no lock-in to our roadmap either. With a transparent set of roadmaps, our technology partners know what to expect… and have a proactive vehicle to comment on the direction.

  • Public roadmaps are good for our customers’ trust
  • When our customers buy-in to our integration platform, they’re putting technology direction on the line. They want to know if we’ll be evolving in the direction they want. For them, it’s all about mitigating long-term technology risk. This way, we’re “opening the kimono” and boldly stating direction.

  • Public roadmaps show our pride, confidence, and vision
  • WSO2’s technology has been evolving for over 13 years. Over 350 engineers currently work on technologies like API management, identity management, ESBs, enterprise integration, and related integration architectures. This is one way of showing-off our vision and capabilities.

  • Public roadmaps are good for business
  • In sales situations, customers often ask pointed questions about specific (missing) features. And the usual answer “Yup, we’re working on supporting it” is always received with skepticism. Our public roadmaps put our money where our mouth is… either it’s on the roadmap, or it’s not. Or, we work with our partners to change the roadmap… for everyone else to see.

Next, what’s on our Roadmap roadmap?

This is the first of many more steps we’ll be taking toward increased openness and transparency. But the other critical component is your feedback. So if you have thoughts about our roadmap- positive or negative – there are many avenues you can use, including our Contact Us button – and include your feedback.

Everything I know about Integration I learned at the Ballet

or, New ways to bring together the world of arts and technology…

Why would the inventors of an integration programming language partner with a Ballet company?

We asked ourselves that when WSO2, launched Ballerina, a new programming language for writing code to integrate software.

The notion of integrating software isn’t new… it’s been around for 10-15 years. And the current market for software integration — the set of technologies used to connect different software components together — is billions of dollars. That’s huge because there is simply so much software and data in the world. It resides not only in the companies that build it, but also in the “cloud”and in the billions of devices that people carry and use.

But when we thought about creating a programming language for integrating software, we didn’t realize how it would lead us to the San Francisco Ballet.

Enter Stage Left: Two entirely different — yet similar — partners

I don’t consider the SF Ballet one of those stodgy steeped-in-tradition companies. Just the fact that it’s in San Francisco means it has access to diverse-thinking, art-loving, Silicon Valley open-to-anything audiences…as well as access to global dance talent. To further appeal to this audience, they offer an annual Sensorium program that synthesizes dance, art, and music. They asked, “What could be possible when we integrate all of these art forms into one evening of celebration?”

Meanwhile, leadership at WSO2 asked something similar. What could be possible if we took a radical, new and open approach to connecting and integrating all software technologies? What would be possible if we developed an internal corporate culture of openness and transparency, of appreciation of our personal diversity?

When WSO2 began developing Ballerina roughly three years ago, we chose the name because of its technical elegance. But we hardly knew how prescient that name would be. So in 2018 when we officially launched the language, we thought that involving a ballet company might be a cool creative move, consistent with the “Ballerina” name. But what we discovered with the SF Ballet was much more. We realized that we had many themes and goals in common.

Common themes in the arts *and* in technology

When the SF Ballet told us about Sensorium and their mission to blend arts and technology, we knew we had a great future together. And so, WSO2 became the SF Ballet’s first technology sponsor.

Together, we found three common overarching themes arose that both patrons of the arts — as well as technologists — could appreciate: the concepts of integration, elegance, and openness.

Integration: Literally and metaphorically, this is the key to all creativity. In the arts, SF Ballet knew that dance, music, culture, and even technology could come together to create new experiences and new ways to engage the public. Integration at the Sensorium was a way to co-locate art, music, and dance exhibitions — and allow guests to interact with all of them. In the arts, integration often means a “synthesis” of diverse media and approaches to its use. And so, in technology, integration is a necessary approach to innovation, building on diverse software components that are often created by others. The beauty with technological integration is that the original developer may never know how the software component might be used by others to create something new, exciting or valuable.

Elegance: This is a word that’s often used with the assumption that it relates to the arts, to fashion or to dance. In those contexts, elegance is the use of resources like the body, fabric or media (or a combination) to create something of beauty — something that makes perfect or unique use of those assets. Often we just know elegance when we see it. As a recovering engineer, I also know there is absolutely an elegance to technology, science, and mathematics as well. Think about a suspension bridge, making perfect use of minimal materials — steel or concrete as support and cables to suspend — not a touch more heft or bulk than needed. Similarly, in mathematics, there are often short, concise formulas that so perfectly describe the physical world. And the same goes for coding where elegant programming makes efficient use (and re-use) of software components.

Openness: This last theme is deceptively simple but powerful. It’s about the importance of openness to new experiences, cultures, media, and perspectives. In technology, openness (i.e. open-source software) is also a well-known concept that means allowing others to build and create on top of your work, to view your code, your instructions, your architecture. In personal relationships — as well business and politics — openness implies trust and even a disruption of power (think: free press). So, openness is a necessary platform for true creativity as well as for effective innovation.

Will Ballerina learn more from SF Ballet?

At WSO2 and with Ballerina, as well as with the SF Ballet, we’re looking to continue thinking about more and different ways to “do integration” — whether it’s a revolutionary mashup of arts and culture, or new code-first approaches to integrate software, data and cloud computing. And that’s the beginning of a beautiful relationship: common goals, common interests, common values.

After all, a more integrated world—in arts and technology — is a more interesting, innovative, and creative place to be.

Meeting the March 2019 PSD2 Compliance Deadline with WSO2 Open Banking

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

Regulatory Requirements

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

Open APIs

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

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

Strong Customer Authentication

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

Consent Management

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

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

Transaction Risk Analysis

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

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

Third Party Provider Onboarding (TPP)

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

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

Regulatory Reporting

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

Conclusion

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

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

Ask an Expert: Catching up with Ruwan Abeykoon

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ruwan on one of his many scuba diving adventures!

A Year in Identity

We’re looking at the possibilities of 2019, and after spending one year as the product marketing manager for WSO2 Identity Server, here are some observations I’ve made as to why enterprises would need identity and access management (IAM).

Identity is more than SSO, it’s a key enabler for Integration Agility

Throughout 2018, we kept hearing how identity should be treated as something more than merely a security project at every identity conference we took part in. We have to go back to our enterprises and say why identity is the glue that holds it all together. Single sign-on (SSO0, authentication or securing APIs, would come off a simple task or singular project but it all eventually becomes a part of a much larger project, like integration. Customer identity and access management (CIAM) is a great example of integration. You use identity, API management, and integration components along with analytics to give users a fantastic user experience. So whatever your enterprise strategy may be, identity plays a key role in being future-proof and it’s more than just logging into applications.

Your customer comes first

CIAM, which may appear as a trend, should be the ultimate goal for any enterprise. Most customers that we deal with use WSO2 Identity Server for CIAM through SSO, identity federation, etc. CIAM helps to give your users a unified experience. An example is West Corporation, who does an excellent job of giving their customers a connected experience.

We’re moving from multi factor authentication to adaptive authentication for the very same reason, to help you make your user’s life secure and better.

There’s an API for that

Everything today is API driven. All businesses are inclined to expose their APIs and the rate of exploding endpoints is surely alarming. Yet, what would be the point if these are not secure?

Open source IAM is “still” an emerging concept and this should change

Although open source might not be the most known option for IAM, it should be. A lot of people assume that open source means free, but it’s the “freedom” to try the product, to scan and test the code as you please and NOT being “locked-in” to a vendor. It’s also easy to innovate fast with open source and it’s versatile because of the variety of authenticators and connectors. One of my team-mates illustrated this quite brilliantly on Quora.

Therefore if one were to choose an IAM solution for their enterprise, I strongly urge to give open source a try.

Privacy

It takes a situation like Cambridge Analytica for enterprises to take IAM seriously. With the rise of General Data Protection Regulation (GDPR) and the upcoming California Consumer Privacy Act (CCPA), user consent and privacy are taking the precedence over everything and we fully support this. IAM is wired to provide compliance so that users are secure and businesses can make use of this opportunity to demonstrate that they are “user-centric” and prioritize privacy over everything. This way you maximize user retention too.

Some final thoughts

2018 has been a fantastic learning curve, also because I get to work with the best in the industry (both in Marketing and Engineering/IAM). One such person is Prabath Siriwardena, who is a walking encyclopedia of all things identity (check out his blog, you’ll learning something you didn’t know).

Here’s to a data breach free 2019!

. . .

You can read more blogs posts from me here. I also Tweet and get in touch with me @fishfaceishi

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.

WSO2 API Management Strategy: Industry Observations and Implications

Recently we at WSO2 were asked by a leading analyst to outline our vision and strategy for the future of API management. We felt that our response captured much of our current and planned execution, so much so that we felt we needed to share it. Our culture at WSO2 has always been one of transparency, and in the past, we’ve even shared our financials.

Following are some of our positions on API management and additional market insights, as well as our vision of the composable enterprise. Stay tuned for additional strategy-related posts that dive more deeply into our technology “big bets” and direction.

How digital transformation is changing the landscape of APIs and digital connections

Current IT trends show that over the next few years, enterprises will find they need to deal with more than 1 trillion programmable endpoints and APIs. These will consist of traditional application APIs, data APIs, data streams, software component APIs, microservices, sensors, and IoT inputs as well. Indeed, everything may become an API.

Knowledge workers know this, and will want/need access to all these APIs/endpoints whether it’s only to create a basic SaaS-to-SaaS connection, or to create a more complex integration. Therefore, over the next 2 to 5 years, we expect that tools and processes will necessarily evolve to address this level of scale and complexity.

Additionally, infrastructures to support this huge quantity of endpoints will gravitate toward those optimized for microservices and serverless underpinnings. From a development perspective, current low-code integration approaches that involve centralized IT orgs and/or waterfall style processes simply will not scale. As a result, architectures will necessarily tend toward more decentralized, cell-based approaches underpinned by microservices and serverless.

With the trend toward trillions of endpoints, WSO2 believes much of what is today considered part of the “development” organizations will evolve to include API integration. The trend will be particularly strong where APIs serve as the core of digital apps and applications that rely on Internet of Things (IoT) data and artificial intelligence (AI). This is at the core of the disruption WSO2 sees in the coming years: that IT organizations tend less toward “development”, and more toward being “API integrators.” We call this new disruptive IT phase the composable enterprise, which will be fueled by the explosive availability and use of APIs and programmable endpoints.

The future of digital connections across enterprise boundaries

WSO2’s position is that API ecosystems across enterprises will expand as today’s software disaggregation (componentization) trends continue. Thus the composable enterprise will become a combination of both internal and external API-based services, each front-ended by private and/or public APIs. This API diversity—and dynamism—will inherently require hybrid API integration capabilities and distributed (rather than centralized) forms of management and governance.

To accomplish this, we see the use of distributed integration technologies, such as microgateways and micro ESBs, which necessarily operate in a decentralized fashion, bridging services from different sources, vendors, and enterprises.

From a business perspective, WSO2 sees ever-tighter service integrations across enterprises, suppliers, partners, and customers—all underpinned by API integration technologies. IT departments will become the “services supply chain managers.”

A perfect example is WSO2 customer Wells Fargo, which has successfully front-ended its organizations and systems with public APIs and gateways to accelerate new product and service delivery, as well as speed integrations with business partners. This form of API marketplace is being adopted by digitally driven organizations that are encouraging partners, suppliers, and even customers, to work more closely with their offerings.

Enter: the composable enterprise

The WSO2 vision of the composable enterprise does not imply a purely internal IT model, but rather an approach that spans the enterprise’s complete external service ecosystem as well.

The notion of the composable enterprise will involve closer, more secure, and more real-time digital interactions between vendors, suppliers, and customers—as well as for internal integrations. API-based interactions will also result in more rapid product and service innovation among all parties, creating new forms of value for customers, partners, and internal business units alike. Already, multiple forms of storefronts, macro-gateways, and monetization models are arising where enterprises are brokering their internal services for use by external entities.

Today, WSO2 customers are pursuing this vision. Wells Fargo, BNY Mellon, and StubHub are just three of many enterprises that are publishing their APIs, as well as basing their internal architectures on disaggregated components front-ended with APIs, gateways, etc.

Indeed, many leading companies are already basing the bulk of their revenue on the API economy, capitalizing on the business wave highlighted in by the Harvard Business Review back in 2015:

“…Salesforce.com generates 50% of its revenue through APIs, Expedia.com generates 90%, and eBay, 60%. Salesforce.com has a marketplace (AppExchange) for apps created by its partners that work on its platform; they now number more than 300. Expedia’s APIs allow people using third-party websites to tap its functionality in order to book flights, cars, and hotels. And APIs allow eBay to list its auctions on other websites, get bidder information about sold items, collect feedback on transactions, and list new items for sale-all of which give additional exposure to eBay items and increase revenue.”

Future drivers and shapers of API management

WSO2 sees the major pressures driving the future of the API management space as grouped into two main categories: the market drivers led by the demand for API business and the technology shapers, led by vendors and innovators.

Drivers of API demand aren’t entirely new, but they have recently risen in their influence on IT behavior:

  1. The trillion endpoints future: the trend toward every digital asset becoming a programmable endpoint and causing IT to create strategies to access these assets.
  2. Digital business competitive pressures: forcing organizations to more quickly find ways to digitally interact with suppliers, partners, and customers.
  3. Knowledge worker information consumption: where organic demand for nearly every digital asset begins with line-of-business users looking for new data and conveniences.
  4. SaaS-to-SaaS app integration: a trend increasing exponentially where every new SaaS app or component is more valuable each time it’s integrated with another.
  5. Machine learning: with applications of ML forcing both data at rest and data streams to become accessible and front-ended with APIs.

Similarly, API management is being shaped by adjacent systems and technologies, quickly maturing the use (and re-use) of software endpoint components:

  1. Microservices and serverless technologies: these are (and will be) driving massive app disaggregation because of the abstractions and simplicities they create for software deployment, directly leading to a world of more broadly distributed micro APIs and microgateways.
  2. Cloud native dynamic systems: growing class of distributed and dynamically changing microservices will cause API discovery and surveillance to become dynamic as well.
  3. Configuration-based integration tools (e.g. ESBs) and code-based integration programming languages (e.g. Ballerina): because, “Software is eating the world,” every company is being forced to make software and agile integration to become a core competency. This creates a world where forms of API integration need to become as agile as developers and organizations want them to be.
  4. API security, access and governance: these requirements are leading to the native integration between integration, access Management, and API management.
  5. The advent of distributed cell-based architectures: these new architectures will allow for decentralized development, test and deployment, speeding integration activities across organizations.

Implications WSO2 sees for the future of API management solutions

  • Implications for architecture: there will be a growing shift toward cloud-native architectures and a need for decentralized composable units of architecture. Each composable unit is what WSO2 terms a “cell”. Cells are defined by, and interfaced through, APIs; are governed by micro- and macro-gateways; include embedded control planes like service meshes; and are developed by decentralized, independent teams.
  • Implications for development agility: with the need to develop and maintain an increasing number of connections across the enterprise, an organization’s ability to remain agile while supporting this expanded connectivity, faces pressures. WSO2’s vision is not only enabling organizations to make these connections, but to empower development teams, DevOps, and operations to increase their adaptive agility while doing integration. Integration teams must become integration agile, adopting the tools, organization, and processes similar to agile development.
  • Implications for tools: all API management and integration tools will need to involve some form of distributed technology, and all will necessarily evolve to be microservice and serverless friendly, i.e.:
    • Provide distributed forms of observability and security
    • Offer multiple control planes
    • Support service meshes
    • Support hybrid orchestration architectures

In closing…

Here at WSO2, we’re betting that all developer organizations will eventually have to adopt integration skills as well — especially as all digital assets become accessible and programmable.

We’re also anticipating the result will be the composable enterprise, shifting business onto a digital ecosystem. And to facilitate that, we’re building open source integration tools, integration agile methodologies, and even programming languages, to help digitally driven organizations achieve this future.

Stay tuned for more of our technical “big bets” in a future blog.

Ask an Expert: Catching up with Dakshika Jayathilaka

Dakshika Jayathilaka is the team lead for WSO2’s UX efforts. With more than 10 years of industry experience in the areas of UX planning, interaction design trends, wireframing, prototyping, and more, Dakshika is a speaker, visiting lecturer, and a family man.

In this interview, Dakshika talks about some of the things he’s passionate about – WSO2 (of course), UX and its role in an integration company, and an exciting new project that he has been working on!

1. For how long have you been at WSO2 and what has your journey been like?

I have been working at WSO2 for more than 4 years and it had been a tremendous journey with an awesome bunch of people. As the first UX member at WSO2, I was able to inspire software engineers to enhance the usability of our offerings by actively driving the UX process, which is crucial in delivering successful projects to clients. Currently I am actively working on an interesting project that will enhance our tooling experience.

2. There’s a misconception that UI and UX are the same. Can you enlighten us about this?

Let’s take a step back and first look at the definitions for UI and UX are.

UI designing is closely related to graphic designing, where as UX designing involves the more technical aspects of application development including learning the user needs, gathering and analyzing market data, and performing alternative testing.”

In the IT industry, UI which stands for User Interface is an umbrella term that covers everything designed into information devices which enable people to interact with them. Examples of UIs are laptop screens, desktop screens, etc. These interfaces facilitate users to interact with software applications. UI designing is the discipline that refers to the crafting of such interfaces. User experience designing, which is commonly known as UX, covers everything done to enhance user satisfaction by focusing on usability and accessibility aspects. UX can be considered as a discipline that stemmed from traditional HCI practices.

To answer the original question, UX isn’t just a buzzword invented to replace UI. However, UI can be thought of as subset of UX. UI designing is closely related to graphic designing, where as UX designing involves the more technical aspects of application development including learning the user needs, gathering and analyzing market data, and performing alternative testing.

3. What are the key aspects and considerations for a good user experience?

Good (or improved) user experience depends on the market, the personas that we cater to, the level of user stories, and epics we have derived. In case you’re not familiar with these words, here’s a quick introduction to them:

  • A persona encompasses the characteristics of a person. For example, a debit card user can be considered as a persona that ties with the need to transact with the debit card.
  • A user story identifies each individual requirement of a particular persona, e.g., as a debit card user I want to pay for my grocery items using my debit card, so that I do not have to carry cash in my wallet.
  • An epic intervenes all the inter-related user stories to provide the bird’s eye view.

It’s critical to understand the personas you are catering to with your product offering. You need to be familiar with users’ jargon to effectively communicate with clients, gather the user requirements, and map them to personas. This is the foundation of a good UX design.

After gathering the requirements, you need to craft the user stories and epics to provide the overall picture to the internal stakeholders. Such meetings will help you to brainstorm good ideas and forecast the design. Most B2B organizations are following agile practices and thus, you may have multiple meetings with both internal and external stakeholders to refine user stories. Such market findings will help you to come up with a good story flow.

Once user stories are finalized, do alternative designs using your previous UX project experience. Subsequently, conduct A/B testing to come up with the most usable design. This too can have iterations. Finally, always keep yourself updated about new tools and research around the UX domain to be on top of the game.

4. Working in a middleware company that involves more technical work when compared with an end user application, how do you view the benefits of UX and the role of an UX engineer?

UX is not an afterthought and you need to thoroughly think about your design and system development. Middleware companies also have different personas and priorities, and the needs differ depending on the areas of focus. For example, at WSO2, Enterprise Integration and Identity and Access Management mainly target integration specialists and identity administrators, while API Management focuses on API admins, publishers, and developers. To achieve the right experience, we perform lab testing, A/B testing, and heuristic evaluations on each product area.

When you really think about it, UX is a crucial aspect for the middleware domain that gives it a competitive edge.”

According Jared M. Spool, “Without also having proactive UX design efforts, the design team is only fixing problems caused by decisions the product team has already made. These already-made decisions are about what the product will do, how it will work, and what its underlying architecture will be.”

When you really think about it, UX is a crucial aspect for the middleware domain that gives it a competitive edge.

5. What’s the latest project you are working on and how do you think that will benefit our customers?

Currently I am working with the WSO2 Enterprise Integrator team to introduce usability improvements to the tooling. Enterprise integration is often considered a complex process that requires technical skills to work with. WSO2 Enterprise Integrator is an open source, hybrid integration platform that allows developers to do quick, iterative integrations with any application, data, or system.

Integration tooling is a must and needs to be designed with great UX in mind. Integration is also a vast area and includes multiple personas. Thus, with this project, we are trying to improve the experience of integration specialists and ad-hoc integrators. This will mainly cover the developer experience of each persona. In essence, we are trying to provide the right experience to each user category while providing proper user onboarding.

6. Where do you see the future of UX is heading and what are some trends to watch?

Soul-searching is happening in many professions at the moment, as high-tech, reliable, and inexpensive artificial intelligence (AI) and automation technologies are becoming a reality in every industrial sector. There are already commercial attempts at using AI to improve the UX.”

UX has evolved not only because of the ubiquity of smart technology (smart devices, Smart TVs, etc. ), but also because developed economies are increasingly focused on the service industry, where customer experience is crucial. Soul-searching is happening in many professions at the moment, as high-tech, reliable, and inexpensive artificial intelligence (AI) and automation technologies are becoming a reality in every industrial sector. There are already commercial attempts at using AI to improve the UX. VUI (Voice User interfaces) are increasingly used to improve end user experiences.

The enterprise world is also growing fast and moving towards the agile environment, where UX needs to be agile to support the rapid movements. UX is evolving towards CX (Customer Experience), which covers more breath and depth to fulfill the needs of enterprises.

7. Finally, what advice would you like to give the budding developers/UX engineers?

  • Patience: becoming a great UX engineer does not happen overnight. It is a long, steep journey. But it is worth it. There is a plethora of online material that you can refer to get things started.
  • Stay inspired: follow UX specialists in the industry and keep yourself updated about new trends and strategies related to UX.
  • Sharpen your skills: constantly improve your design skills, domain knowledge, business acumen, interpersonal skills, and presentation skills.
  • Be open to feedback: always be open to feedback from your colleagues, your clients, and others.. An open mind helps you to see things from others’ perspective, and assess the viability and applicability.
  • Empathy: be willing to provide help and guidance to your colleagues by getting in to their shoes.
  • Maintain a portfolio: it’s important to maintain a good portfolio with case studies to showcase your track record as well as your potential.
  • Passion: be passionate about the subject, and this is also important as you need to identify with the psychology and cognitive behavior of people.

Dakshika dressed up as the Joker at a costume party!

Announcing the WSO2 Serverless Solution

Most enterprises today looking for serverless solutions have few options without cloud lock-in. Remember that public serverless offerings will capture a customer’s data, lock out external event streams, and likely limit developer language choice. This lock-in hinders application migration, multi-cloud scaling, and the use of private cloud resources. A more palatable solution ought to allow organizations to tap serverless for disaggregated architectures, and allow them to utilize both public and private cloud resources, event models, and programming paradigms.

In response, customers today are mostly forced to use public serverless offerings from AWS (Lambda), MSFT, GOOG, etc., with limitations placed on the supported programming languages for each. Users are further locked-in because of the need to use adjacent proprietary services like the cloud’s storage services. And if a company wants to use an alternative, they’ll require considerable investment to manage.

Enter the WSO2 serverless solution

Today we’re introducing the WSO2 Serverless Solution, a private function hosting environment based on Apache OpenWhisk and Kubernetes. And it’s immediately available, though on a limited-access basis.

To develop the solution, WSO2 has been working with Rodric Rabbah and Perry Cheng, co-founders of CASM LLC and co-creators of Apache OpenWhisk. They bring in-depth knowledge on custom deployments and backend optimizations to the overall solution, and both continue to be active members of the OpenWhisk community.

The solution allows organizations to leverage their existing event sources and programming languages. Underlying the open source function platform, Apache OpenWhisk allows developers to plug existing event sources into the solution. It also allows developers to use their preferred programming language as a function runtime which will allow them to re-use most existing code, and allows users to define their own custom resource limits. These combine to provide greater overall agility to a serverless solution. And you’ll have freedom from cloud lock-in.

And the best part is that the WSO2 Serverless Solution is a private hosted platform managed by WSO2, so it ought to significantly reduce learning, set-up and maintenance overhead for DevOps teams.

A little more detail…

The serverless solution is fundamentally powered by Apache OpenWhisk and Kubernetes to allow IT orgs to provide a uniform, elastic, and secure platform for reactive, event-based, and batch workloads.

The Solution offers several unique capabilities:

  • Private function platform – powered by Apache OpenWhisk deployed on top of Kubernetes
  • Managed hosting environment – provided by WSO2, mapped to internal private resources and events, with customized elasticity.
  • Private, dedicated servers and operations – provides segregated tenancy
  • Support for any programming language – broader support than any single public cloud vendor
  • Leverage any existing event source – no matter where you deploy
  • Transparent computational elasticity – to support both short and long running computation
  • Guaranteed computational capacity – because it is a private function environment
  • Secure platform, plus service isolation, and encryption of data in motion
  • Local development environment – for developer teams
  • Dev tracing and operations of event-driven apps with logging, monitoring, and analytics

Why did we do this?

WSO2’s mission is to help digitally-driven organizations become integration-agile. And we do that with a platform of open-source Integration, API Management, Identity Management and related products. One core motive of ours (and of the overall open source model) is freedom from lock-in… So it stood to reason that if we wanted to simplify integration tasks, it would require simplifying deployment tasks too. So we developed this cloud-vendor-neutral deployment approach to complement our products.

Availability

As mentioned, the solution is immediately available on an early-access basis. Pricing is offered at a flat rate, on either a monthly or annual billing. For more information see the WSO2 Serverless Solution.

Ask an Expert: Catching up with Srinath Perera

Srinath Perera is vice president of research at WSO2. He is a scientist, software architect, author, and speaker. He is also a key architect behind Apache Axis2 and WSO2 Stream Processor. We caught up with Srinath recently to get his take on the significance of Streaming SQL, the future of open source stream processing solutions, and why we must learn to think, question, and see beyond the obvious.

1. What has your journey at WSO2 been like?

This is my ninth year at WSO2, but I have been working with Sanjiva Weerawarana on similar technologies since 2003. Yes, it’s been close to 15 years, and it’s been a lot of fun. I have worked on a wide variety of challenging problems, and have worked with many brilliant individuals who will make good stories for one’s grandchildren one day. I have done a lot more than I imagined years ago.

2. For agile digital businesses, the availability of business insights is a significant factor in gaining a competitive advantage. How does WSO2 Stream Processor help?

Our product can easily plug-in to a user’s system and collect data. You could then write queries using Streaming SQL to detect important conditions. Streaming SQL is similar to SQL, but works on data streams instead of data tables. The former is flowing, while the latter is stored on a disk.

Compared to what our competitors offer, we have very powerful Streaming SQL with operators most others do not have. We enable you to use machine learning models within Streaming SQL itself. Also, if you are looking for a small deployment, our server can run a HA deployment with only two nodes and process about 100,000 events/second. If you are looking for a large deployment, we can run on top of Kafka. In the event you are unsure or undecided, you can always start small and later switch to Kafka without changing any code.

Streaming SQL is similar to SQL, but works on data streams instead of data tables. The former is flowing, while the latter is stored on a disk.”

3. What does the future hold for open source stream processing solutions?

In my opinion, stream processing has not become mainstream yet. People are still figuring out analytics. It’s not easy to find developers who excel in analytics. Stream processing has to wait for that adoption to play out. No one will try to do real-time before they figure out basic analytics; that is unless you have specialized use cases such as for stock markets, surveillance, and anomaly detection.

People are still figuring out analytics. It’s not easy to find developers who excel in analytics. Stream processing has to wait for that adoption to play out.”

4. What are the benefits of an open source stream processing solution?

I think there’s a growing trend for middleware as an open source model. They use complex code, support a wide variety of use cases, and are used by many. We are increasingly made aware that products are best built using the open source model. I think there’s no better testament than Microsoft, a company that hated open-source, but has now embraced it.

I think there’s a growing trend for middleware as an open source model. They use complex code, support a wide variety of use cases, and are used by many.”

5. How did you start working in stream processing?

A long time ago, in 2007, while I was doing a Ph.D, we worked on a paper comparing Complex Event Processors (or CEPs, which is an older name for stream processing) and rule-based systems. I was fascinated by the technology, and after I joined WSO2, I supervised an undergraduate thesis project to build an open-source CEP engine. This was in 2011 – well before stream processing became cool! It was called WSO2 Complex Event Processor back then and was later renamed WSO2 Stream Processor.

6. What is your proudest accomplishment in recent times?

In general, it is the role I have played with Apache Axis2. However, if you want me to choose something recent, I suppose my work with the WSO2 Research Team stands out. Some good work will be made public soon. I have also worked with Paul Fremantle, WSO2’s CTO, to build a framework to evaluate different emerging technologies. You will hear more about this too soon.

7. What advice would you like to give a budding developer or an architect to better their career?

I would say learn to think, question, and see beyond the obvious.”

There is this quote that I love, “Wisdom is tolerance of cognitive dissonance.” It took me awhile to understand what it meant. We all interpret how the world works, but when we discover things that do not match our way of thinking, we ignore them. However, the world is more complicated than that. By understanding those mismatches and by learning through struggle and discomfort, we achieve true wisdom. That is what that quote conveys.

I would say learn to think, question, and see beyond the obvious. I refuse to tell people I work with how to solve something. Instead, I tell them, “Tell me how you will solve it and then I will complain.” I think they are used to it now. That way, we all use put our critical thinking skills to good use and one day, they will not need me for guidance.

To learn more about Srinath’s work, follow him on Twitter and read his blog.