A new era.

Roughly a month ago, I left a great job @ WSO2 to start a new venture. It was scary and exciting at the same time.

I did not want to leave WSO2. I had an amazing role, was having a lot of fun, was learning everyday about many aspects of running a company and above all, was working with brilliant people, at all levels of the company.

Fate put a hard choice in front of me : drop everything and get a chance to create my own product or continue with my job. I decided to leave.

It was not an easy choice: I had much to loose and was jumping into uncertainty , not to mention that I would have no revenue until the company  was funded.

But so far, the choice has proven to be a great one. It’s been a hell of fun to work with my two other co-founders to define the product, the market, the strategy, play with new technologies and be back to coding !

Looking forward to the next episode of a new era!


On Women in Tech and Feminism.

I am tired to always be the only woman in the room. Well, almost always. Sometimes there is another woman. But usually in a meeting with 15/20 people, I will end up being the only woman. Does not matter where I go either: France, Spain, Italy, Nordics, Germany, UK, USA. Just one exception, at least that’s the way it was a few years ago when I was at IBM: Turkey (that surprises you, he?). In Turkey, there were a lot of women in IT, and this at all levels in the hierarchy. My company (WSO2) is pretty good too, around 1/3 of our engineers are women.

I recently went through the Frankfurt airport and visited the Business Lounge. It was packed, like 300 people. For some reason, it hit me: there were about 10 women in that huge room.

Few months ago, I was presenting at a conference in Spain. Journalists who were covering the event wanted an interview, and their first question was: “How come you’re the only woman presenting at this conference?”

This sucks. Bad time. When and where are we loosing 51% of the population ??! in IT careers. Where can I go, if not to this conference, to finally find a whole group of women working in IT. I would need to state clearly my intentions if I go! but I am sure it would be loads of fun 🙂

My experience though is that once you have proven in that meeting you know what you’re talking about, the respect you get is the same than if you were a man. Never have I faced a professional who would treat me differently because I was a woman. So the problem is not to be there, the problem is how to get there.

I love that campaign about #LikeAGirl. May be that’s when it starts:  working in technology is not  a “girl thing”, it’s a boy thing, and we loose most of people there.  The quote below comes from this article.

James Gross, a psychology professor at Stanford University, has a 13-year-old daughter who loves math and science. It hasn’t occurred to her yet that that’s unusual, he says. “But I know in the next couple of years, it will.”

I want to live in a world where girls can do what they want and not being restricted by social barriers or judged by not being “in the norm”. I like to work with my hands and build stuff, I like technology as I find it fascinating (it’s shaping the world we live in), I like to drive fast cars with plenty of torque, or fly a drone. I like to jump into conversations where nobody expects a woman to bring any value: I once explained to an Italian F1 fan what the  coanda effect  was, you should have seen his face. Priceless.

My take is that this is a manipulation of men to make sure we don’t get to play with their toys. Girls/Ladies, it’s a load of fun and very rewarding IMO to work with your hands. Yes, you’ll break a nail or two, don’t worry, they grow back 🙂 Try it and if you don’t like it, then leave it. But don’t restrict yourself just because somebody says so. And don’t think you can’t do it , because you’re not a man. There a very few things in this world a woman cannot do, and those are mainly related to physical strength. But being a carpenter or learning technology, there are no parts of the human anatomy that only men have required to do any of those things. You’ve equal chances than a man to be good or bad at it.

By the way, the same social pressure applies to men: you are expected to know things when you’re a man, for example changing a car wheel. You would not believe how many of my friends who would be in great trouble if they had to do that (and no, another cliché, most of them are not gay…). Same applies to knowing how to read a map or follow directions.

I see you coming: another of those feminists. I am not a feminist, at least not in the sense most people think about feminism. I like the feminism defended by Isabel Allende. I like the causes worth fighting for she describes in that talk.

I am for equal rights, across the board. I hate quotas, even if I can understand it’s a way to give people a chance they would not otherwise get, but I think positive discrimination as this is often called, is actually not serving women at all. When a woman is promoted, there is this little thing bothering many: “if she had not been a woman, would she have been promoted?” and even if everybody recognizes you’re brilliant and deserve it, there is this slight doubt hanging in there.That’s why I am saying I am for equal rights: same salary for all, same opportunities for all. The fact that some companies still pay women less for the same job just drives me nuts. There is no way to justify that.

But I am drifting away from the original topic: women in tech. Let’s work with the young generations and educate girls and boys so that in 20 years from now, I can look at this text again and hopefully see some progress. Happy to volunteer to help change that!

I can promise you that women working together – linked, informed and educated – can bring peace and prosperity to this forsaken planet.

Isabel Allende

What does it take to build a platform ?

At WSO2, we pride ourselves to have built a very strong runtime platform, which is called Carbon. All products are based on Carbon, no exception. For Carbon V5, we rebooted the architecture to make it leaner, as it had grown a bit of a fat belly over the last 8 years, but the principles remain the same: modular, composable, extensible architecture. We continue to leverage OSGi, which has served us well, but we are removing the dependencies on technical components which also served us well, such as Axis2, but have unfortunately grown old and are not so fit for the new IT world.

Then we took a step back and asked ourselves if we could extend that principle. What is a product after all ? It’s 3 things: a server/runtime, some tooling to create the artifacts to be deployed on the runtime and out of the box analytics to monitor the runtime. The key advantage of Carbon is giving consistency in terms of administration, installation across all products at the runtime level. What could we use to play the Carbon role for tooling and analytics ? ProductDefinition Simple. Developer Studio and Data Analytics Server.

Developer Studio, which is based on Eclipse, already has a modular/extensible architecture. In V4, we are just changing the packaging so that each product team can release their tooling individually. Starting very soon, you will see appearing dedicated tooling for each product (such as Dev Studio for ESB) on every product page but of course, as for Carbon, you will be able to combine the ESB features, for example with the DSS and CEP ones if you need to to have a single IDE across all the WSO2 products.

For analytics, Data Analytics Server (DAS) is our combined offering for all types of analytics: batch (analyzing data at rest), streaming (analyzing data in real-time) and predictive (learn from existing data and predict behavior). Again , Data Analytics server serves well as a platform, since applications to be installed on top (aka toolboxes) are packaged individually and deployed. So Data Analytics for API Manager will be nothing more than the DAS product with pre-installed toolboxes for log analysis, API activity and technical monitoring. Similarly to Carbon and Dev Studio, analytics for multiple products can be combined on a single DAS server.

In fact, in order to provide consistent experience across a large number of products, you have no choice but thinking about the underlying components first. What I explained above extends to our stores (API Store, Apps Store, Processes Store, etc.) . To do that right, we first created an enterprise store, which is really a framework for building your own store. To build dashboards for analytics, we needed a dashboard product, on which our teams could build their own visualizations and gadgets. That was User Engagement Server, now renamed as Dashboard Server.

This philosophy can be represented in the diagram visible below: at the bottom, you find the foundation servers and frameworks. On top of those, product teams build extensions and don’t have to worry about the core functionality of the framework. Of course, customers can also create extensions, or modify the default ones, typically adding their own analytics and own visualizations.


At WSO2 we are committed to this approach, as it has allowed to quickly evolve and innovate in the past 10 years. Customers benefit from this in many ways, primarily on consistency in installation, behavior, or operational management.


A tale of passion and culture…

If you live in the United States, you probably can’t escape the SuperBowl phenomenon. As a French citizen, I can’t really relate, but I know one thing: it’s BIG!

About a month ago, one of the WSO2 marketing team members launched what he thought was a crazy idea: use our products to predict who would win the big game. And what happened next is a great example of how WSO2 works. We just love crazy ideas 🙂

A bunch of people reacted and not only marketing people. Why? Because 99% of internal communications are public ones, meaning everybody has access to them. The WSO2 Machine Learner team of course, but also Kern from Sales, a football fan: his knowledge was critical to gather the necessary data to build the prediction model. One in particular: injuries are one of the critical factors which decide the fate of a team.

And then frantic work began: while our engineers and data scientists worked on building and proving the model  with the historical data they had found online, the marketing team worked relentlessly to build the web site that would host the prediction, mostly on their personal time. After all, this was not a planned activity! But everybody bought into the idea and helped as much as they could. Logo design, the web page implementation, the first model.. all is completed in just 3 weeks, including over the holiday period.

The reason I love this story is because it reflects so much on how we work: the open culture which has empowered Saliya to step up and throw his idea, the commitment of the engineering team to help realize the idea, the passion of the marketing team to release this on time for the first games. We had not planned for this, we just did it. Well, they did it, because all I have done personally is watching in awe the deployment progressing at giant steps.

Stories like this are one of the many reasons I love my work.

Want to play and try some predictions ? Connect here . Want to know how we did it ? Read this.


WSO2: The Disruptive Company

Disruptive is probably the adjective that best describes WSO2. We take a different approach on many fronts:
  • When other open source companies have community and enterprise versions, we only have a single, complete, enterprise-ready version. No hidden features or agenda.
  • When other companies grow by acquisition, we grow by innovation and have built 25 products in just 9 years.
  • While other companies rarely expose their engineers to customers and do not usually give them the opportunity to deploy the products they devolve in real situations, we do. 
  • When other companies charge you according to the number of cores and processors of your servers, we charge you for what you use: active production instances.
  • While other companies have dedicated support engineers, we have a small permanent team and get our engineers to support the products they build.
  • While other companies try to sell you all-you-can-eat contracts and get you to buy products that end up on a shelf, we sell you just what you need. Start small and grow organically.
Disruptive can also be used to characterize our customers. Many decided to change the established order: by introducing Open Source against traditional vendors in financial organizations, by revolutionizing the way they do business in the airline industry or starting a digital transformation in government agencies. They faced resistance and they kept believing that doing things differently was possible. They are succeeding.
We don’t believe in: “That’s the way it’s always been done” . We don’t fit in pretty much any box.  Quoting Tim O’Reilly in his WSO2Con keynote, I believe we are the “Uber of Middleware Vendors.”

Step1 : Integrating Services with the WSO2 platform

This is a follow-up to the platform overview post about the overall WSO2 platform and its capabilities. In this post, we focus on Integration. The diagram below depicts the various integration components and their relationship.


Accessing Data: should your enterprise be small or large, you have data to manage. Data can be stored in many different places: spreadsheets, CSV files, relational databases, NoSQL databases. Traditionally, applications have been using JDBC and standard APIs to access the data, and there is nothing wrong technically doing that. However, this poses few management problems:

  1. Code accessing the data (SQL queries for example) is spread across many apps, and any change to the data implies a change in all the apps.
  2. There is no way to centrally scale/optimize the access to data.

From an architecture point of view, the recommendation is to create a data access layer, which encapsulates all the data access (creating DAO and DTOs  which abstracts the underlying database and data model). The Data Services Server allows you to do just that, but also provides:

  • A user-friendly interface to build services from data. Those services can be SOAP-based or REST-based, return XML or JSON. You can provision a service in minutes if you choose to generate the services straight from the data model
  • Support for data security: you can assign a role to a certain data column: for example, hiding sensitive information from the Employees database for non-HR people.
  • Support for nested queries, that is the ability to use the result of one query as input to another one.
  • And of course, the usual transactional support you would expect connecting to a database.

Managing Services: now that we have services, either existing ones or created with DSS, we need to proxy/virtualize them to decouple the consumer layer from the producer layer. You may not see this as useful at first, especially is all you do is just proxy the service and nothing more, but experience proves that this decoupling will become useful as your architecture evolves and applications start requiring enriching, transforming or composing services. Back-end services can stay as-is, while the mediation layer does the ground work and makes that totally transparent to the consumer. You may also be worried about latency, which is why you need to evaluate ESB products carefully, to ensure they will scale while keeping transactions duration in a range that is satisfactory for your business.

Adapters are one of the key requirements for an ESB. As the central backbone to connect to anything, for traditional ERP such as SAP to popular cloud offerings such as SalesForce or Concur, ESB needs to be able to talk to all . We have launched a major effort end of last year to build dozens of adapters, and we are publishing them on your WSO2 Store, build on our Enterprise Store product.

Our ESB is one of the most mature products WSO2 has, and our customers have chosen it for :

  • Being configuration-driven as opposed to coding
  • Its extensibility (connectors, transports, business logic)
  • Its performance
  • Its scalability

Messaging-based integration: if you need to integrate in an asynchronous manner with another application, inbound or outbound, you need a message broker system. A message broker provides support for point-to-point and publish-subscribe integration, messages persistence and supports standard protocols such as JMS, AMQP or MQTT. You can plug any messaging systems into our ESB, as long as it supports those standards. WSO2 Message Broker is based on the Apache QPid project and offers unique distributed architecture.

Business Process management: the mediation layer must not contain business logic or state. They act on the message format and contents, but do not “understand it” at the business level. Nor will an ESB remember anything about what happened if the system crashes for example. Moreover, ESB transactions are measured in milliseconds, not hours or days. If you need to model complex interactions between services, that processes are long-running and you need to keep state, you are entering Business Process Management (BPM) territory. A BPM layer uses the services exposed by the mediation layer and as such, “sits on top” of it. In many processes, a human needs to be involved, through the use of Human Tasks.

In summary, using our Integration products, you can :

  • Expose any data source as a service
  • Proxy any service
  • Compose, transform, enrich services at the mediation layer
  • Orchestrate services in long running processes, including human intervention
  • Relay messages across applications in a reliable and scalable way.


WSO2 Platform

Finally back to the blog – I can’t believe I did not write any for more than a year, time absolutely flew by – New products, new responsibilities – Exciting times!

To restart blogging, I decided to start with a platform presentation. At WSO2, we often state that we have a platform and not a set of individual products. I explained that months ago when I described Carbon. This is still true (more than ever), but our products also constitute a platform – A platform you can build upon.

So what do we offer ?

Most of the enterprises we talk to have the same necessity : connect applications, people and devices. Let’s take a concrete example: imagine you create your own company. You will most likely need to provision a CRM, on-premise or in the Cloud to manage your clients and day-to-day activities. Rest of information you can manage in local databases or even spreadsheets. In order for your sales employees to be more efficient, you need them to go to customers and have their information available at any time. Best solution: you give a tablet to each of your employees. But how does the CRM data gets there, securely, in a controlled way ?

Let’s progress step by step :

  1. Wrap all the backend functionality as services. This may already be done by the CRM itself – If not, or if you have some custom business logic you want to reuse, r data you want to share, you’ll have to create those services. SOAP/REST/XML/JSON, Java/PHP/Scala, you choose. Once services are created, it won’t really matter, so choose what you’re comfortable with.
  2. Best practices recommend that you decouple the consumers of those services from the producers. In other words, you need a mediation layer between your existing services. This layer may be very simple in the beginning ( i.e. act as a simple reverse proxy) but once this is in place, the transformation, enrichment or guaranteed delivery use cases can be easily handled.
  3. Expose those services as APIs – The APIs are your contract with the consumers. APIs have their own life cycle, are managed ( for security and rate control ). Service is the implementation. If you are not convinced, read this : http://sanjiva.weerawarana.org/2012/08/api-management-missing-link-for-soa.html.
  4. All right, now you have APIs – How will people find them ? Think about the all the Apple apps, but without the Apple Store. How would we know which apps are available, what other consumers think about them, how would we interact with the apps authors ? Same applies to your APIs. If they are not socialized through a store, you won’t achieve the reuse level you are targeting, nor will we engage with your clients.
  5. Your APIs are deployed and people use them. But do you know who uses them? Which is APIs is the mostly used, which one is not ? Analytics are a core part of this strategy, but they give you visibility into the system.
  6. And of course security: not only do you need to secure the access to your APIs, but you may also have to support single-sign on to applications, or allow your employees to use their emailID to view CRM data.

The WSO2 platform allows you to address all of these aspects; you may consume the whole platform or just parts of it. You may have existing services deployed on various systems or an existing ESB. As long as all of they use standard approaches ( which most of them do ) , chances are you can plug one of our components into your architecture.

Middleware platform


In subsequent posts, I will detail each of the platform themes: integration, API management, Assets socialization, Analytics and Security.