Insights and Challenges from Mulesoft Connect 2019

#CONNECT19 @MuleSoft is a significant player in the Integration Platform as a Service (iPaaS) market. I've just spent some time at their annual customer event in London.

Over the years, I've been to many events like this. A technology company organizes an event, possibly repeated at several locations around the globe, attended by customers and prospects, business partners, employees and others. After an introduction of loud music and lights shining in your face, the CEO or CTO or honoured guest bounces onto the stage and provides a keynote speech. Outside, there will be exhibition stands with product demonstrations, as well as information about complementary products and services.

At such events, we are presented with an array of messages from the company and its business partners, with endorsements and some useful insights from a handful of customers. So how to analyse and evaluate these messages?

Firstly, what's new. In the case of Mulesoft, the core technology vision of microserves, networked applications and B2B ecosystems has been around for many years. (At the CBDi Forum, we were talking about some of this stuff over ten years ago.) But it's useful to see how far the industry has got towards this vision, and how much further there is to go. In his presentation, Mulesoft CTO Uri Sarid described a complex ecosystem that might exist by around 2025, including demand-side orchestration of services. There is a fair amount of technology for supply-side orchestration of APIs, but demand-side orchestration isn't really there yet.

Furthermore, organizations are often cautious about releasing the APIs into the wild. For example, government departments may make APIs available to other government departments, local governments and the NHS, but in many cases it is not yet possible for citizens to consume these APIs directly, or for a third party (such as a charity) to act as a mediator. However, some sectors have made progress in this direction, thanks to initiatives such as Open Banking.

However, the technology has allowed all sorts of things to be done much faster and more reliably, so I heard some good stories about the speed with which new functionality can be rolled out across multiple endpoints. As some of the technical obstacles are removed, IT people should be able to shift their attention to business transformation, or even imagination and innovation.

MuleSoft argues that the API economy will drive / is driving a rapid cycle of (incremental) innovation, accelerating the pace of change in some ecosystems. MuleSoft is enthusiastic about  citizen integration or democratization, shifting the initiative from the Town Planners to the Settlers and Pioneers. However, if APIs are to serve as reusable building blocks, they need to be built to last. (There is an important connection between ideas of trimodal development and ideas of pace layering, which needs to be teased out further.)


Secondly, what's different. Not just differences between the past and the present, but differences between Mulesoft and other vendors with comparable offerings. At a given point in time, each competing product will provide slightly different sets of features at different price points, but feature comparisons can get outdated very quickly. And if you are acquiring this kind of technology, you would ideally like to know the total cost of ownership, and the productivity you are likely to get. It takes time and money to research such questions properly, and I'm not surprised that so many people rely on versions of the Magic Sorting Hat produced by the large analyst firms.

By the way, this is not just about comparing Mulesoft with other iPaaS vendors, but comparing iPaaS with other technologies, such as Robotic Process Automation (RPA).


And thirdly, what's missing. Although I heard business strategy for APIs mentioned several times, I didn't hear much about how this could be done. Several speakers warned against using the term API for a non-technical audience, and advised people to talk about service benefit.

But how to identify and analyse service benefit? How do you identify the service value that can be delivered through APIs, how do you determine the right level of granularity and asset-specificity, and what are the design principles? In other words, how do you get the business requirements that drive the use of MuleSoft or other iPaaS products? I button-holed a few consultants from the large consultancies, but the answers were mostly disappointing.


I plan to attend some similar events this month, and shall write a couple of general follow-up posts.

---

Notes

Here's an article I wrote in 2002, which mentioned Sun Microsystems' distinction between micro services and macro services.

Richard Veryard, Identifying Web Services (CBDI Journal, February 2002)

And here are two articles discussing demand-side orchestration.

Richard Veryard and Philip Boxer, Metropolis and SOA Governance (Microsoft Architecture Journal, July 2005)

Philip Boxer and Richard Veryard, Taking Governance to the Edge (Microsoft Architecture Journal, August 2006)

See also CBDI Journal Archive

Link to MuleSoft presentations https://library.mulesoft.com/mulesoft-connect-london-2019/


Related post: Strategy and Requirements for the API Ecosystem (October 2019)

Wikipedia 2

Looking at the Service Engineering Vendor category in Wikipedia, I noticed that there was no entry for Cape Clear, so I added one and was immediately challenged by one of the Wikipedia editors - was Cape Clear "notable"? A quick Google search produced a handful of newspaper articles and independent analyst reports, which appears to be enough to satisfy the notability criterion.

Several other SOA companies were challenged, including IONA. Some are still under threat, and two companies (Polar Lake and Layer 7) have been deleted from Wikipedia altogether. At least for the time being.

A number of SOA companies have disappeared in the last couple of years, through merger and acquisition. But the small companies often yield interesting and exciting innovations, and it would be a great pity if Wikipedia is biased towards the large companies .

Update: the Service Engineering categories have now also been removed from Wikipedia.

The Death of Java EE?

I wanted to add something to David Sprott's post on the Death of Java EE.
My take on this is that we are moving further away from the old-fashioned idea of a single all-powerful general-purpose programming language/environment. The complexity (and sometime popularity) of PL/1 and ADA resulted from the expectation that you could (and should) code everything you ever wanted in a single syntax.

All sorts of three-letter acronyms (TLAs) have already taken a swipe at this expectation - including MDA and CBD. Now SOA takes a further swipe.

So what future use is Java EE in the SOA world? David says:

"Our customers tell us that Java EE is the only sane choice when really high performance and criticality are required."

Of course this is right - today. But looking ahead, surely we may predict the emergence of future languages/environments specifically designed for high performance and criticality, but without some of the other stuff that is presently in Java EE. Something better will come along - possibly simpler, or possibly complex in ways we cannot imagine today.

Of course Java EE is not dead. PL/1 and ADA survived long after they were fashionable, and there are doubtless many people still coding in these languages today. But just as the long-term survival of the polar bear is threatened by the shrinking of the polar icecaps, surely even Java fans must acknowledge that the long-term survival of Java EE is threatened by SOA.

From Oracle to SOA Governance

Consolidation: Oracle acquires Siebel

Oracle's acquisition of Siebel (together with its previous acquisition of PeopleSoft) is attracting a great deal of interest. Some stakeholders and observers have made interesting comparisons. 

 

§	Oracle is the new Computer Associates	Marc Benioff (SalesForce.com)
§	Oracle is the new Microsoft	Dana Blankenhorn (ZDNet), Paul Roberts (eWeek)

 

Both of these statements need to be taken sceptically in my view; each large IT company has its own style of acquisition, its own style of managing (and possibly integrating) its expanding product portfolio. 

Nicholas (Does IT Matter?) Carr comments on the duality of this event: consolidation and disruption. At one level, enteprise software becoming a mature commodity ripe for consolidation; at a higher level enterprise solutions becoming decomposed and recomposed according to SOA principles. See also commentary by Dan Farber (ZDnet). 

 

Disruption: Salesforce

If there is to be disruption, the business model being promoted by SalesForce.com seems like a good candidate. A number of commentators (see above) have been convinced by Marc Benioff's bullish statements at DreamForce (the SalesForce.com conference). However E. Schwartz (InfoWorld TechWatch) posts a sceptical note. The key question here is whether large corporate users will be willing to rely upon a smaller service provider, and how long can SalesForce.com remain independent. (Many commentators have been unable to resist speculating about a possible future acquisition of SalesForce.com; and it is always fun to imagine various win-win permutations.)

 

Asymmetric Rationalization

Industry consolidation involves a form of supply-side rationalization: rationalization of the vendor by the vendor for the vendor. Of course, acquisition is only the first step of this process. There are various possible outcomes in terms of the consolidation of sales and marketing, the consolidation of brands, the consolidation of underlying technologies, components and platforms. Large software companies are generally trying to get a good balance between extracting maximum revenue from cash-cow software products and/or services, and developing new markets for new products/services. 

Meanwhile, large corporate users are also under pressure to rationalize their IT provision - to achieve maximum economies and value-for-money while continuing to support the complex and changing IT requirements of the business. 

The relationship between these two rationalization processes is a complex one. While there are some obvious conflicts of interest, there are also many opportunities for collaboration: between vendors, between users, as well as across the vendor-user divide. OpenSource and ApplicationExchange (which Nicholas Carr sees as a reincarnation of IBM SHARE) can both be regarded as forms of sociotechnical collaboration. 

 

SOA Governance

Which somehow brings us to Service-Oriented Architecture (SOA).

James Governor (Redmonk) suggests that the Oracle consolidation provides a trigger for user organizations to sort out IT governance - as a defence against the growing monopoly power of Oracle. Perhaps now is the time to sort out your relationships across the IT vendorspace, sort out your platform and procurement strategy. This is the user side of vendor rationalization. 

Radovan Janecek (Systinet) (SOAG Starting Point, Ultimate Vision of SOA) explains why this is an SOA governance issue and not just an IT governance issue. The bones of his argument are like this: business goals ... IT services ... reuse ... trust ... contract ... control ... metadata. And for Joe McKendrick (ZDNet), SOA provides a vision of independence from any single vendor. 

At one level, standardization on a product or platform ties you to a specific vendor or vendor community. Software monoculture carries significant risk - both because it increases the likely impact of any security breaches, and because it may foreclose some forms of innovation. However, if you can standardize the interfaces at the right level, you may be able to combine software economies with requisite variety and software biodiversity. Doing this properly is a complex architectural trick, but if it is achieved it provides a great argument for SOA. 

The big picture is broader than a single organization. While large organizations will need internal SOA governance, they will also increasingly need to participate in external SOA-based collaborations. There are two kinds of interoperability involved - endo-interoperability (within a single enterprise) and exo-interoperability - and therefore at least two kinds of SOA governance. 

For more on SOA Governance, please look at my article on Metropolis and SOA Governance. written with Philip Boxer and published in the Microsoft Architecture Journal. We are currently working on a sequel, in which we will illustrate the concepts of endo-interoperability and exo-interoperability, and explore their implications for structure, process and organization. Any discussion would be most welcome.