Progress appears to have finally thrown in the towel in a number of the market segments that it competes in. From the press release that accompanied the announcement, it is clear that some deep corporate soul searching has gone on over the past several months and that somebody finally had the balls to introspect and ask “What is Progress Software good at?”. Having the corporate balls to ask the question is one thing, but today it appears that Progress has decided to act upon the answer.

In a previous post I asked whether corporate DNA existed, such that an in-built set behaviours and attitudes exist and pervade despite the changing business models and staff. Well perhaps my DNA observation was prescient because Progress’ news release used the term, stating.

Progress Software Corporation (NASDAQ: PRGS) announced today a new strategic plan designed to enhance growth, profitability and shareholder value. Under the plan, Progress will become a leading provider of a next-generation, context-aware application development and deployment platform in the Cloud for the Application Platform-as-a-Service (aPaaS) market by investing in its core OpenEdge, DataDirect Connect and Apama Analytics and Decisions products and integrating them into a single, cohesive offering. The strategic plan leverages the Company’s inherent DNA and vast experience in application development and deployment established over 30 years.

Aside from the 10-15% of its workforces’ lives and careers that this announcement will impact, I am pleased that Progress has looked at its DNA, mapped that to what the market needs and has tried to structure a company that can thrive in the Cloud. For too long Progress forgot its core values and differentiators and instead aimed to ape other vendors. The result was that Progress often had superior technology that was built or bought as much for the intellectual exercise as any commitment to commercial success.

Progress watched competitors in the integration space build out broad SOA portfolios and felt it should do the same. But it was OK for the likes of Oracle to diversify and buy another product line because as a company a) it was doing it because it wanted to make specific commercial gain and b) it is brutally efficient at selling software. Having a piece of functionality in the product portfolio because other vendors also had it appears to have been more important to Progress in recent years than actually having the wherewithal to persuade customers to part with the cash.

As anyone that ever worked at Progress will tell you, this technically-led DNA ran deep within the organisation. No company that I have worked for before, or with since, has had such an imbalance in the control structures of the company. For Progress, sales and marketing were seen as support functions for the product arm of the company. Today we’re seeing the impact of not putting sales at the centre of its universe.

With my analyst hat on, It’s been a while since I had an update from Progress and perhaps I need to fix that. I’d better declare an interest here – well several in fact. I’m an ex-customer, an ex-employee, I’ve consulted to the company and worked with them since I left in 2006. I used to get updates from friends that were still at the company but time has seen many of those leave to take better opportunities or fall victim to another round of RIFs.

I think this is a good move for Progress and I hope it works out. I’m also very interested in the aPaaS product strategy that Progress is embarking upon because PaaS is an area that really interests me at the moment. I’m also keen to see what might be behind this claim…

Progress is poised to create the industry’s most capable and language-agnostic aPaaS offering with multi-tenancy, Big Data connectivity, and real-time analytics in a new generation category that is experiencing explosive growth.

…because on the surface each of those product areas looks like it already exists and, dare I say, is dominated by others. What will also be interesting is who will pick up the product lines that are being divested: Actional, Artix, DataXtend, FuseSource, ObjectStore, Orbacus, Orbix, Savvion, Shadow and Sonic?

So Progress has made some huge decisions here but I think the most telling part of the press release is that it highlights that Jay Bhatt is the company’s first external CEO. I feel positive for the company for the first time in a long while. Why? Because Progress Software needed some diversity in its gene pool.

Danny Goodall

Related posts that you might also be interested in...

A mate of mine who works for Salesforce.com suggested I look at Heroku after I told him that I’d had some good and bad experiences with Google’s AppEngine and Amazon’s EC2. I’d been looking for somewhere to host some Python code that I’d written in my spare time and I had looked at both AppEngine and EC2 and found pros and cons with both of them.

As it turns out it was a good suggestion  because Heroku’s approach is very good for the spare-time developer like me. That’s not to say that it’s only an entry level environment – I’m sure it will scale with my needs, but getting up and running with it is very easy.

Having had some experience of the various platforms, I’m wondering where Heroku fits in. My high-level thoughts…

Amazon’s EC2 – A Linux prompt in the sky

Starting with EC2, I found EC2 the simplest concept to get to grips with but by far the most complex to configure. For the uninitiated, EC2 provides you with a machine instance in the cloud which is a very simple concept to understand. Every time you start a machine instance you effectively get a Linux prompt, of varying degrees of power and capacity, in the sky. What this means is that you have to manually configure the OS, database, web infrastructure, caching, etc. This is excellent in that it gives unrivalled flexibility and after all, we’ve all had to configure our development and test environment anyway so we should understand the technology.

But imagine that you’ve architected your system to have multiple machines hosting the database, multiple machines processing logic and multiple web servers managing user load; you have to configure each of these instances yourself. This is non-trivial and if you want to be able to flexibly scale each of the machine layers then you own that problem yourself (although there are after market solutions to this too).

But what it does mean is that if you’re taking a system that is currently deployed on internal infrastructure and deploying it to the cloud, you can mimic the internal configuration in the cloud. This in turn means that the application itself does not necessarily need to be re-archtected.

The sheer amount of additional infrastructure that Amazon makes available to cloud developers (Queuing, cloud storage,  MapReduce farms, storage, caching, etc) coupled with their experience of managing both the infrastructure and the associated business models, makes Amazon an easy choice for serious cloud deployments.

Google AppEngine – Sandbox deployment dumbed down to the point of being dumb?

So I’m a fan of Google, in the same way that I might say I’m a fan of oxygen. It’s ominpresent and it turns out that it’s easier to use a Google service than not – for pretty much all of Google’s services. They really understand the “giving crack cocaine free to school kids” model of adoption. They also like Python (my drug of choice) and so using AppEngine was a natural choice for me. AppEngine presents you with an abstracted view of a machine instance that runs your code and supports Java, Python or Google’s new Go language. With such language restrictions it’s clear to see that, unlike EC2, Google is presenting developers with a cosseted, language-aware, sand-boxed environment in which to run code. The fact that Google tunes the virtual machines to host and scale code optimally is, depending on your mindset, either a very good thing or close to being the end of the world. For me, not wanting, knowing how to, or needing to push the bounds of the language implementation, I found the AppEngine environment intuitive and easy. It’s Google right?

But some of the Python restrictions, such as not being able to use modules that contain C code are just too restrictive. Google also doesn’t present the developer with a standard SQL database interface, which adds another layer of complexity as you have to use Google’s high replication datastore.  Google would argue, with some justification I’m sure, that you can’t use a standard SQL database in an environment when the infrastructure that happens to be running your code at any given moment could be anywhere in Google’s data centres worldwide. But it meant that my code wouldn’t port without a little bit of attention.

The other issue I had with Google is that the pricing model works from quotas for various internal resources. Understanding how your application is likely to use these resources and therefore arriving at a projected cost is pretty difficult. So whilst Google has made getting code into the cloud relatively easy, it’s also put in place too many restrictions to make it of serious value.

Heroku- Goldilock’s porridge too hot, too cold or just right?

It would be tempting, and not a little symmetrical, to place Heroku squarely between the two other PaaS environments above. And whilst that is sort of where it fits in my mind, it would also be too simplistic. Heroku does avoid the outright complexity of EC2 and seems to also avoid some of the terminal restrictions (although it’s early days) of AppEngine. But the key difference with EC2 lies in how Heroku manages Dynos (Heroku’s name for an executing instance). To handle scale and to maximise use of its own resources, Heroku runs your code only for the specific instance that it is being executed. After that, the code, the machine instance and any data it contained are forgotten. This means that things like a persistent file system or a having a piece of your code always running cannot be relied upon.

These problems are pretty easily surmountable. Amazon’s S3 can be used as a persistent file store and Heroku apps can also launch a worker process that can be relied upon to not be restarted in the same way as the other Dyno web processes.

Scale is managed intelligently by Heroku in that you simply increase the number of web and worker processes that your application has access to – obviously this also has an impact on the cost. Finally there is an apparently thriving add-on community that provides (at additional monthly cost) access to caching, queuing and in fact any type of additional service that you might otherwise have installed for free on your Amazon EC2 instance.

Conclusion

I guess the main conclusion of this simple comparison is that whilst Heroku does make deploying web apps simple, you can’t simple take code already deployed on internal servers and git commit it to Heroku.com. Heroku forces you to think about the interactions your application will have with its new deployment environment, because if it didn’t, your app wouldn’t scale. This is also true of Google’s AppEngine, but the restrictions that AppEngine places on the type of code you can run makes it of limited value to my mind. These restrictions do not appear to be there with Amazon EC2. You can simply take an internally hosted system and build a deployment environment in the cloud that mimics the current environment. But at some point down the line, you’re going to have to think about making the code a better cloud citizen. With EC2, you’re simply able to defer the point of re-architecture. And the task of administering EC2 is a full time job in itself and should not be underestimated. Heroku is amazingly simply by comparison.

Anyway, those are my top of mind thoughts on the relative strengths and weaknesses of the different cloud hosting solutions I’ve personally looked at. Right now I have to say that Heroku really does strike an excellent balance between ease and capability. Worth a look.

Danny Goodall

Related posts that you might also be interested in...

And in doing so I was reminded of the ‘parable’ about the child and the ice cream…you know the story. It goes something like this.

A mother and her six year old daughter are out shopping and as a treat for her well-behaved daughter, the mother buys her an ice cream. But the mother is worried that her daughter’s elder brother, who is at home, will be jealous that his sister got an ice cream but he didn’t.

So the mother says…

When we get home, don’t tell your brother that we had an ice cream.

The daughter agrees to the subterfuge. But when the she gets home, what’s the first thing she says to her brother?

We didn’t have an ice cream.

Doh! And now the brother ‘knows’ that his mother and sister have had ice creams and they didn’t buy him one.

The problem is that to the six year old girl…

Don’t tell your brother that we had an ice cream

and

Tell your brother we didn’t have an ice cream

…seem pretty much commutative. The lesson? If you want your child to avoid talking about a subject, avoid the subject. And so it is with marketing. A general rule – if you want to keep something potentially negative from your prospects, avoid the subject. Alternatively, be upfront and tell it like it is.

So in looking at early market software vendors, it’s like someone told them “Don’t give away how small your company is”. So being desperate to hide the fact that they are really 3 men and a dog in a garage in Boston, instead of ignoring their size in their outbound communication they try to spin and exaggerate their company size. Large companies tend not to mention their size all of the time. They’re comfortable with it so they leave it as unsaid. But smaller organisations try to talk their size up and this simply comes across as “We are a tiny company in a garage in Boston and we’re trying to appear bigger. Oh and did I mention we also have a dog?”.

If you’re small revel in it. It means you can do many things that other vendors can’t. You’ll get found out at some point in the sales process anyway. Someone will have to assess the risk of doing business with you and if you don’t pass that test, then you’re unlikely to get the deal. It doesn’t matter which prestigious building’s 19th floor washroom you’ve set up office in. Neither does it matter that you’ve just opened your second sales office in Nowheresville and that this is evidence of your continued expansion plans – even though Nowheresville is the home town of the CTO and has a population of 247.

Prove you can do what you claim and make sure that what you claim you can do is important to your target customer. The rest will take care of itself. Don’t tell your prospects that you didn’t have an ice cream, and whatever you do, don’t put on a pair of Cuban heels.

Danny Goodall

I thoroughly enjoyed the event – except that it overran and I had to miss the Q&A panel to run and get a flight. That aside, it’s really gratifying to watch a large-ish vendor execute on marketing strategy with a single vision. I’ve long admired Informatica’s marketing, having worked alongside a couple of their ex-senior marketing folks and seen the disciplines they learned at Informatica. And it’s clear that the company is focussed, knows who it sells to and why they buy.

But I thought I’d share a couple of observations that reminded me that the Informatica marketing machine is not infallible.

On Audience Strata Mismatch

Audience strata mismatch is the term I use to denote when a vendor is saying all the right things to the all the wrong people. Much of the content from the event centred around the business pains created by a poor data integration strategy and, obviously, the benefits that would flow to the business if the data integration strategy were fixed with, say, Informatica’s products. All good.

As marketeers, we’ve all seen this before. And we’re used to sitting through slide after slide of business benefit bingo which is usually pretty boring. Except that Informatica is able to point to case studies with quantifiable benefit and ROI which makes it slightly more interesting. Again, all good. The problem came during the excellent presentation by John Radcliffe of Gartner where he asked the audience to define their role in their company as either on the business or the technical side. I was surprised to see that, in John Radcliffe’s words, “That’s about 99% of you on the technical side.”. Hmm I thought. So Informatica built an excellent agenda, excellent speakers and excellent content, but perhaps not targeted completely accurately. Don’t get me wrong, there was technical content during the day and I don’t want to suggest that all people ‘on the technical side’ do not care about the benefit of the technology to their business. But, I’m sure they were expecting a different balance.

On Evangelism

Long, long ago when the Internet was just starting to be considered as a platform across which business to business commerce could be transacted, I went on a European speaking tour promoting a reliable computer to computer messaging product. I remember getting on my feet in front of audiences from London to Prague and from Paris to Milan evangelising how this messaging product would revolutionise the way business was conducted. I told them that the very fabric of the way business to business trade was conducted would change, I told them that they should show vision and leadership in their market and use our product to gain the march on their competition. I used examples of similar paradigm shifts from the past that companies had used to disrupt their markets. I implored them for the sake of the families to grab the wave and not miss out on this opportunity. Well perhaps I didn’t go quite that far, but I certainly played up the role that B2B e-commerce would have.

Was I wrong? No. Was I premature? Well, only by about 5 years.

 On BIG-DATA

Why am I sharing this fact from my past? Well BIG-DATA appears to be Informatica’s ‘reliable computer to computer messaging’ and social networks, Informatica’s ‘B2B commerce’. Informatica sees the exploitation of social media and the resultant mining of the massive amounts of data by-product of our twittering, liking and plus oneing; as a massive potential opportunity for their clients and prospects. You see, for a company that is all about data integration and that has a solution for every conceivable current (budgeted) data integration project type, where do you go next? The answer appears to be that you get into BIG-DATA integration, ahead of your competition, but also apparently ahead of demand.

So why do I say ‘ahead of demand’? Well because the level of evangelistic fervour with which Informatica approached this massive, future, potential opportunity, reminded me of my good self all those years ago. When the (excellent by the way) presenter drew a comparison between the competitive motivation the United States used to start its space program in the late ’50s and the current competitive market opportunity that presented itself to the audience, I sensed we might be ahead of the curve.

That’s not to say that there isn’t an opportunity right now for organisations looking to mine the BIG-DATA created by social media mechanisms to interact with the customers. I’m sure there is. But for the majority of folks in the audience this is likely to be some way off and, as a result, some way down their list of priorities. It’s clear that BIG-DATA is going to give data integration vendors headaches and opportunities in equal measure, but it was also clear that the demand for BIG-DATA solutions is nascent at best.

Anyway, an excellent and educational event and I’ll be back in 5 years to check on just how ahead of the curve Informatica is/was.

Danny Goodall

Disclosure: I advise an organisation in the MDM space and Informatica acquired a company that I previously advised.

Related posts that you might also be interested in...

REPAMATron automates my REPAMA competitive marketing intelligence methodology and is currently in Alpha. I’m using the ESB market, a market I know well, to help to tune the algorithms at the heart of REPAMATron.

In my previous entry I looked at 3 Enterprise Service Bus vendors’ marketing strategies (WSO2, Talend and FuseSource) and compared them to the computed market mean. I’ve now added another 6 ESB vendors to the study from the long list of ESB vendors produced by Gartner. These new vendors are TmaxSoft, JBOSS, Axway, Seeburger, JBOSS, InterSystems and iWay. So the complete list of vendors and products currently under scrutiny is:

I’ve also categorised the list into open source and closed source ESBs. This has allowed me to pull together Marketing Element Distribution (MED) charts that show the difference in marketing strategy between the average open source strategy and the average closed source strategy.

Which features are important for Open Source ESBs versus Closed Source ESBs versus the ESB average?

The PIPESCOM Marketing Element Distribution (MED) chart below shows the features that are promoted most prominently by vendors in the ESB space. Each of the 3 chart series shows a different market mean. The ESB market mean shows the 12 vendor average of all of the vendors in the table above. The closed source ESB vendor average features the average of the 7 closed source vendor results whilst the open source ESB vendor series aggregates the results of 5 open source vendors.

This is an interesting set of results for a couple of reasons. Firstly because there is a great deal of similarity between the open source and closed source vendors. Taking an ESB to market, be it closed source or open source, appears to be about focusing on communicating the same basic set of features. Interfaces, process and management features are all promoted strongly in keeping with the very nature of an ESB.

However, a number of differences (differentiation) exist. As one might expect the open source ESB vendors place extra emphasis on the packaging of their product as well as the commercial characteristics. There is also an additional focus on ease-of-use by closed source vendors although the reason for this is not immediately clear. It appears that closed source vendors believe that stressing the ease-of-use characteristics of their products is more important than their open source contemporaries.

Which value propositions (benefits) are important for Open Source ESBs versus Closed Source ESBs versus the ESB average?

The MITICOR Marketing Element Distribution (MED) chart below shows the value proposition (benefit) categories that the vendors in the study stress in their outbound communication. The chart series are as described in the PIPESCOM chart above.

Again, this is an interesting set of results. It appears that when it comes to expressing the value (or benefit) that the vendors feel they deliver to their customers there is significantly more differentiation between open and closed source ESBs than with the PIPESCOM features chart above.

Also of interest is the Cost value proposition. As you’d expect this is where a vendor feels they can save, reduce, offset, mitigate of remove cost for their customers. One would naturally think that an open source ESB proposition might focus heavily on the cost benefits of an open source solution over a comparable closed source ESB. The chart above bears this out in that the open source Cost proposition scores higher than the closed source equivalent. However the difference is very small and the Cost value proposition for closed source vendors already scores strongly. This would suggest that with their closed source ESB counterparts already focussing on the cost benefits of their solution, it will be difficult for the open source vendors to differentiate and sell using cost alone as a proposition.

In my next blog I’ll share the results of a direct comparison between an open source ESB vendor and a closed source competitor. I’ll also continue to add vendors and additional tests to these studies and will share the results in future blogs.

Please post any feedback you may have in the comment section below or contact me here.

Danny Goodall

Related posts that you might also be interested in...

The previous post described what REPAMA and REPAMATron are all about so if you’ve landed here and have no idea what this is, then I’d recommend that you read the first post in this series. Having taken a look at how a section of the Enterprise Service Bus market (WSO2, FuseSource and Talend) communicates benefits or value propositions, I’m now going to share the research into the product features that each vendor communicates most prominently. To allow a comparison to be made between the vendors and to the market mean (the average strategy of all vendors in the segment), I first have to examine how each vendor communicates product features and determine which of the PIPESCOM categories the feature fits into.

What is PIPESCOM?

The PIPESCOM classification allows one vendor’s marketing copy to be compared to another’s with respect to how they communicate product features. This is achieved by categorising the features that are described in the vendor’s marketing copy into the following broad categories. Packaging, Interfaces, Process, Ease of use, Speed, Commercial, Operational, Management. So for example, if a vendor describes their product as having “the ability to interface with other systems” then that would suggest they are making a claim about the product’s Interfaces. If a vendor talked about their product being available as a service then this would relate to the Packaging category of PIPESCOM. Similarly if the product is described as ‘inexpensive’ or ‘commercial-off-the-shelf software’ then that would fall into the Commercial category. You can read more about PIPESCOM here.

PIPESCOM (Product features)

The following series of charts shows the relative support for each of the PIPESCOM product feature categories found in the vendor’s marketing materials. The esb market mean displayed in the chart is the aggregate or average strategy of the 6 Enterprise Service Bus Vendors in the table below.

This market mean allows a comparison to be made between the results of WSO2, Talend and FuseSoruce and the ‘average’ approach vendors take to the Enterprise Service Bus market.

FuseSource

^*The chart below shows that FuseSource stresses the interfaces the product has to other technologies. This is not surprising since an ESB exists to interface to other technologies. That said, it is clear that FuseSource’s reliance on communicating Interface features is much higher than the esb market mean (the aggregate of the 6 ESB vendors above). FuseSource does not focus on ease of use, or at least not significantly enough to register with REPAMATron.

Talend

^*Talend’s product feature focus mirrors very closely the esb market mean. The exception is that Talend focuses significant effort on ease of use features – significantly more than the market mean.

WSO2

^*WSO2 shows an above average focus on packaging (the way the product is configured for sale/use) and the management features of the product. Similarly to FuseSource, WSO2 places little discernible focus on the ease-of-use features of its products.

FuseSource, Talend and WSO2

^*The combined chart shows how each vendor stresses different product features in their outbound marketing. The differentiation between them and to the esb marketing mean is shown by their relative commitment/lack of commitment to one of the PIPESCOM categories. It appears that differentiation exists between the vendors around how Packaging, Ease-of-use, Commercial and Management features are communicated.

In future posts I will expand on the vendors in this ESB study and will also share some additional MED and text analysis tests. I’d welcome feedback about vendors that should be included in these studies and indeed what market segments I should look at next. In addition to rounding out the ESB study I plan to look at high performance messaging and master data management as I am working on client projects in those areas at the moment. Please post feedback in the comment section below or contact me here. Danny Goodall ^* – This is alpha software. The results and conclusions are indicative at the moment and are in no way definitive.

Related posts that you might also be interested in...

If you’ve been following this blog you’ll know that I analyse the marketing tactics and strategies of high-tech vendors – mainly in the infrastructure software space. It’s…

…an emotional day for me as I share the first output from my automated competitive marketing intelligence gathering system – REPAMATron. Well perhaps it’s not that emotional, but it certainly represents a significant milestone in a project that has been in development in my ‘spare time’ for a little while now. Below you’ll find my first tentative steps at automated analysis of the Enterprise Service Bus market.

REPAMA is a research methodology that allows me to categorise and compare the marketing strategies of high-tech vendors inferred from the language they use to take their products to market. REPAMATron automates this manual methodology and generates competitive marketing intelligence that allows competitive differentiation to be visualised and benchmarked.

Before I share the first research results, here is some of the background alternatively you can go straight to the research.

It’s Alpha. It’s Alpha. It’s Alpha.

Taking inspiration from Google’s legendary ‘Beta’ logo that it uses so well to reflect a bit of geek chic onto their latest features, I feel the need to do the same. The difference is that one suspects that Google’s beta code is pretty much commercial quality with a beta label stuck on it for marketing purposes, but with me it’s important to say that this really is alpha software.

The technology and logic behind REPAMATron is at a very early stage. The rules that it uses to determine whether a vendor is following a certain strategy or not will be continually refined over time and as such it will take a little while until results stabilise enough to be ‘accurate’. That said the general inferences that it arrives at are broadly accurate today.

What’s the big idea?

This is competitive differentiation Visualised and Benchmarked.

Visualised - I wanted to create technology that would visualise the competitive differentiation between different vendors’ products within a given market segment. This is especially important in markets where little apparent differentiation exists between the competing vendors. Developing REPAMA taught me that even amongst vendors that have broadly similar products; the way they describe, promote and generally take their products to market can be very different indeed. I wanted to develop a system that could identify ‘hidden’ differentiation and present it graphically so that it could be easily understood.

Benchmarked – By grouping together the a number of vendors’ results it is possible to create an average set of results – I refer to this as the market mean. It is then possible to benchmark and compare each vendor’s strategy to this market mean as well as to specific competitors in the market segment. Understanding how your own strategy differs from the market mean or from a specific competitor can be a very valuable insight.

How does it work?

If I told you that I’d have to kill you. But in general terms, ScrewTinny, the technology behind REPAMATron collects examples of marketing communication from vendors – usually marketing and product collateral from web sites, press releases, emails, etc. This text is analysed using phrase matching, natural language processing and statistical likelihood methods to determine if a specific marketing strategy is present or if a specific claim is being made. All of these inferences are then processed as if being read by a human so text found on popular web pages ranks higher as does text near the top of a document as do multiple clusters of the same inference, etc.

There are currently two main types of analysis. MED Charts and TextAnalysis charts. TextAnalysis charts are not shown below but I will post more on them in a future blog entry.

What is an MED Chart?

The MED Chart (Market Element Distribution), is used to show the relative commitment a vendor has to a specific strategy. A score of 11^* is apportioned, or distributed across the various different marketing strategies in the chart. Vendors that focus their marketing communications on a small set of strategies are rewarded with a higher score. However vendors that water down their focus by aiming at many strategies will score less for each strategy.

Let’s take an example of a two vendors that are describing the value proposition (the benefits) that their respective products confer. Let’s say that vendor A makes one claim repeatedly that his product reduces the cost associated with some task or other. Vendor B also makes repeated claims that her product reduces cost, but in addition she also claims that her product will increase her customers’ revenue and will also reduce the risk of project failure.

Now both vendors make a value proposition to their audience associated with reducing cost but for vendor B her cost claims are watered down because she also makes additional claims about value propositions (or benefits).

What is MITICOR?

MITICOR is my acronym for defining the major categories of value proposition. Think of MITICOR as capturing the category of benefit that each vendor believes their product provides. Broadly speaking I have categorised business to business value propositions for infrastructure software into the following broad categories: Market, Income, Time, Institution, Cost, Operational, Risk. So a Market value proposition might be a claim that you will increase your customers’ market share or that they will get some form of competitive advantage whilst an Institutional value proposition might instead talk about delivering improved company image or reputation, increased shareholder value, better corporate governance, etc. You can read more about it here.

What PIPESCOM?

So if MITICOR captures the claimed benefits associated with a product then PIPESCOM captures the features that the vendor communicates most prominently. As I explained in this previous PIPESCOM blog entry, it’s difficult to compare vendors product marketing strategies without first trying to categorise the types of features that are promoted.

PIPESCOM allows one vendor’s marketing copy to be compared with another vendor’s by categorising the claimed features of the product into the following broad categories. Packaging, Interfaces, Process, Ease of use, Speed, Commercial, Operational, Management. So for example if a vendor describes their product as having “the ability to interface with other systems” then that would suggest they are making a claim about the product’s Interfaces. Similarly if the product is described as ‘inexpensive’ or ‘commercial-off-the-shelf software’ then that would fall into the Commercial category. You can read more about PIPESCOM here.

What’s Next?

I’ve only automated a couple of the 20+ different studies found in the manual REPAMA methodology so I will add those that can realistically be automated. In addition having access to statistical information about the marketing copy that each vendor uses opens up many more possibilities that can’t, or at least can’t realistically be done manually.

The Research

When looking at the vendor comparison below please bear in mind that I’m not looking at the actual capabilities of the products – this isn’t a product review. Instead I’m looking at the marketing claims each vendor makes for the capabilities of their products as embodied in their outbound marketing communications.

As I mentioned in a previous blog post I chose the ESB market to help hone and develop the algorithms behind REPAMATron because it is a market I know well. I will continue to add vendors from this long list of ESB vendors over time and ultimately will cover all market segments in infrastructure software, but for the moment the vendors and products included in the analysis are:

From that list, the Talend, FuseSource and WSO2 results are shown below. The esb market mean comparison that is shown on the charts is the notional average of all 6 ESB vendors from the table above.

The charts are interactive in that if you hover over or click the various datapoints you should be able to see the specific values.

MITICOR – Value Propositions (Benefits)

The following series of charts show the value propositions or benefits found in each vendor’s marketing copy. The MITICOR charts show the relative importance that each vendor attaches to that category.

FuseSource

^**In the chart below it is clear that FuseSource stresses the cost and operational benefits of its software. No other value proposition was found that scored highly enough to be recorded in the chart. This shows a clear focus which interestingly, is quite a departure from the market mean of the 6 ESB vendors. Fuse Source’s focus on Cost is considerably higher than the market mean whilst their their claims about the operational benefits of the product is considerable below the market mean.

Talend

^**Talend’s value proposition appears to centre completely around Operational benefits. Any other value proposition that might appear in its marketing copy didn’t register highly enough to score on the chart. This type of result, where a only single value proposition is recorded is quite common amongst vendors that focus on features without linking them through to benefits that their customers might derive from the feature.

WSO2

^**Interestingly, WSO2′s value propostion most closely follows the market mean. The implied benefits for WSO2′s products are that they will save time, reduce cost and improve operational efficiencies.

FuseSource, Talend and WSO2

^**The combined value proposition chart for the three vendors shows the differentiation found in their marketing materials – differentiation between the 3 vendors in the chart as well as differentiation versus the the ESB market mean.

Well that’s the MITICOR value proposition charts, I’ll post the PIPESCOM product features analysis in a separate blog entry.

I’d welcome feedback about vendors that should be included in these studies and indeed what market segments I should look at next. In addition to rounding out the ESB study I plan to look at high performance messaging and master data management as I am working on client projects in those areas at the moment.

Please post feedback in the comment section below or contact me here.

Danny Goodall

^* – Why 11? Everyone knows that the best amplifiers go up to 11.
^** – This is alpha software. The results and conclusions are indicative at the moment and are in no way definitive.

Related posts that you might also be interested in...

In a previous post I mentioned that I would follow-up to with a calculation for how much jargon WSO2 uses in its ESB marketing when compared to Talend and FuseSource. I’ve now calculated the Arcanicity Index score for WSO2′s ESB marketing copy; and whilst not quite being the answer to life, the universe and everything, it’s not far off – see below.

The Arcanicity Index looks to measure how much jargon a text contains and by extension how much specialist knowledge a reader would need to posses in order to understand it. I’d previously scored both Talend and FuseSource which had shown that Talend’s marketing copy was much less arcane than FuseSource’s but oddly did require a much higher level of grade education to understand it.

It should be said that in a sector of the market where all three of these vendors are presumably targeting overtly technical people, having highly arcane content is not necessarily a bad thing. In fact it’s almost self-selecting. If you’re audience can’t understand your marketing copy then they’re probably not you’re audience. But we do have to recognise that we might be excluding some from understanding the text we write.

Anyway, the results are in and first I have to say that I’ve had to adjust the previous score for FuseSource. I’m now using a different algorithm to detect the number of sentences in a text as well as new code to more accurately estimate the number of syllables in a word. This new algorithm counts less paragraphs for FuseSource which in turn increases the Arcanicity ratings ( as it is a function of acronym density per paragraph ).

And as the table below shows, WSO2 scores somewhere in the middle with an arcanicity score of 45.07 and an arcanicity rating of ‘moderately-high‘ for its ESB marketing copy. The sample text came from WSO2′s ESB product PDF as opposed to their web site because there wasn’t really enough of a sample there.

A couple of caveats for these results. Firstly, as mentioned above WSO2′s text came from a product PDF whereas for both Talend and FuseSource I used the ESB product page from their respective web sites. I’d expect product collateral like a mult-page PDF to be more technically-focused than a general product web page and so in all likelihood WSO2′s generic marketing materials would produce a lower result . Secondly, the WSO2 name is being picked up as an acronym in these results which again is certainly increasing the perceived acronym density of WSO2 here.

I’ve actually pushed some code up to Google’s cloud-hosted appspot.com domain that should allow others to calculate the Arcanicity of their own text – as well as a host of other text statistics. If you’re interested it’s at http://arcanicity.appspot.com. But be gentle as it’s alpha software and I’m not a real programmer!

Danny Goodall

P.S. Here are the respective acronym frequency distribution charts. Click to enlarge.

WSO2

FuseSource

Talend

Related posts that you might also be interested in...

I’m using this study to road-test Project REPAMATron – an automated system that infers a vendors’s marketing strategy from their marketing materials. I’ve decided to add WSO2 into the mix for a number of reasons. The main reason being that I spoke to a representative of one of the other ESB vendors on my long list who asked me “Are you going to be looking at WSO2?”. Which was good enough for me. If that vendor was concerned enough about WSO2 to ask if they’d be on the list, well, then they have to go on the list.

Secondly, in addition to Talend and FuseSource, it will be a third vendor that is building Open Source technology that relies on the Apache stack in some way. It will be good to see how ‘similar‘ products are able to differentiate themselves through their marketing.

Lastly, I really like the marketing approach that the company appears to be taking. It has gone for a “Paradigm-Shift – it doesn’t have to be this way” strategy. Ironically, when we introduced the ESB category at Sonic Software, that was the same approach we went for then – under the banner of

“Changing the Economics of Integration”.

Also, in step with the Sonic Strategy, WSO2 is trotting out the…

“We started from scratch therefore we don’t have the same bloated, overweight stacks as our older (and massively more succesful BTW) competitors”.

…line too. Sonic, and other start-up ESB vendors also levelled that differentiator at the established integration vendors of the day.

But underneath that the company does really seem to have embraced the energy, vibrancy and indeed the new paradigm of the Open Source world. Proof of their willingness to challenge convention is their CEO Sanjiva Weerawarana pictured on their web site standing on his head. Which at least challenges the age-old paradigm of standing on your feet.

So hopefully we’ll see how much the paradigm has shifted. The people there certainly seem to have good provenance. Andwhilst this process is not really about the ESB vendors but more about helping me test a piece of software to see if it is inferring the right meaning behind the marketing language that the vendors use to take their products to market, I can’t help thinking that I’d really like to see how WSO2′s fresh approach differentiates it in the market.

Just as I did with Talend and Fuse Source, I’ll run WSO2′s marketing copy through the Arcanicity Index later to see how much jargon they use in their marketing copy.

I’ll keep you posted.

Danny Goodall

P.S. If there any other vendors you think should be added to the project – let me know.

Related posts that you might also be interested in...

EDIT: Here’s a link to the Arcanicity Index Calculator I mention lower down in this post.

I stumbled across this site the other day when looking for information on the frequency of words used in common English. The site is the brainchild of Jonathan Harris and is wonderfully minimalistic. It almost feels as though this simple Flash plugin were an installation in a museum’s white room. A real lesson to us “more is more” types that indeed, less is more.

Anyway, take a look at wordcount.org and marvel at where your favourite words, your first name, your last name or your company name all fit into the rank of words. But be warned, it’s sister site Querycount watches you and ranks the frequency of searches in wordcount. Go on, have a guess how many expletives make it into the top ten of wordcount searches. Well the answer is three. And they’re three of the worst, or best, depending on your point of view.

I’ve been thinking about readability and ‘Arcanicity’ recently and have been trying to rate how easy a piece of text is to comprehend. Wordcount has made me think that a good place to start might be to look at how frequently each of the words in the text appears in common English usage. After all, if a sentence were full of very uncommon words it would surely mean that a reader would need greater knowledge / experience to comprehend it.

Hmm. Something to ponder.

Danny Goodall

Related posts that you might also be interested in...