LiteBytes from Lustratus Research

Do we need a Wii for SOA?

Nintendo over the last year has achieved an incredible turn around – turned a stalling market back into an exciting one and completely outflanking its competitors – in particular Sony.   It did this by creating a product which took a very different direction to the increasing tired direction of the market leaders.  Looking around the SOA software market today, it is hard to tell the difference between most vendors’ offerings and to a large degree they are simply improvements over previous versions.  Perhaps we need a similarly innovative approach to addressing the development issues I have discussed or the skills issue that Steve covered.

If you look back to before its launch in early 2006, all analysis of the next generation games console market assumed it was Microsoft versus Sony and the battleground (if you excuse the pun)  was who could give the most ”accurate” violence/car racing experience for the core market: 25-35 males.   The market was mature and there was simply no way, Nintendo (or any other entrant) would get a significant slice off the big two.

Nintendo went in a totally different direction – focusing on the user interface with its novel take on the controller.  This totally changed the market – drawing in females and younger gamers as well as providing games that were actually different.  This has allowed Nintendo to make profits, sell many times more units than the ‘old rivals’ Sony and Microsoft – and become much more valuable as a company than Sony itself. 

At the risk of stretching the point, looking at the SOA software market, most analyses assume that nothing radically new can happen to break the strangle hold of the big stack vendors (IBM, Oracle et al).  This may well turn out to be the case – but let’s not assume that there can be nothing truly disruptive will not happen.  Furthermore, I would suggest that something truly disruptive is actually needed to shake off the productivity and skills issues that threaten to derail SOA.

Ronan

The revolving door of SOA

I was speaking with an executive from a major global bank recently, and he introduced me to the SOA revolving door problem. This is a serious issue, particularly for larger, leading edge SOA implementers. The problem is that SOA is not easy - despite numerous claims to the contrary, SOA skills have to be developed. Just understanding Java, for example, does not make someone immediately able to deliver value on SOA projects.

The complexity of SOA and the growing need for specialists was the reason I specifically called out the emergence of SOA-related business cards in the Lustratus forecast for 2007. Unfortunately, this prediction seems to be coming true. I say unfortunately, because the combination of the time to train someone to become productive in developing SOA-based solutions and the current furore around the subject is creating the revolving door concept for early SOA users.

Within these companies, new programmers are taken on to staff the increasing number of SOA projects, and it appears that it is taking around 12 months for these people to become reliably effective. But once they ARE effective, they find they are a precious commodity with a high price tag, and as such these people then move on to new companies that are earlier in the SOA lifecycle and desperate for SOA skills. As a result, the company responsible for the -on-the-job training of these personnel now has to recruit another batch of trainees who start off life unproductive, only to see them walk out after another 12 months. As one expert leaves, a junior comes in, is trained, and then in turn leaves - hence the revolving door.

Of course, this is fine for the programmer - his or her value climbs rapidly over a 12 month period, resulting in a rapid jump in salary. It certainly seems like SOA is a good career choice, at least int he short term. But this problem is clearly becoming a major headache for the more mature SOA adopters.

Steve

Open Source = Community = Japanese documentation

As the OSS movement grows. companies are spending more time thinking about open source and whether it might be an option for use in their solutions. I have always believed that the holy grail for open source is to achieve an active community, contributing and assisting the growth. In this way, requirements can be met that a commercial offering might struggle to satisfy in an acceptable timeframe.

This was brought home to me when I came across a contribution to MuleForge, the community repository for the Mule open source SOA offering. I noticed that someone had contributed Japanese documentation for the Mule ESB. This is a perfect example of my point - even the largest vendors struggle to deliver such things as multi-language documentation. at least until quite late. The issue is justifying and prioritising the necessary resource based on the relatively small market potential addressed by some developments.

But when a community is leveraged, it can contribute many things, even if they are only going to be of interest to a small number of people. So here, one assumes a Japanese user has picked up Mule and decided to write some documentation, presumably for internal use. This has then been contributed to MuleForge, and the result is anyone can benefit from it immediately.

If the power of a worldwide community can truly be unleashed, OSS becomes a highly attractive candidate for product selection shortlists.

  Steve

   

Sofware as a service (SaaS) and the new frontier of integration

A report quoted in Computer Weekly at the end of June found that 17% of SMBs are using more than 1 application delivered as a service.  This, as the article notes, brings the problem of integration back into the frame.  However, the problem is a tougher one in the sense that SMB are typically not equipped with IT departments capable of handling integration projects and are cost averse. 
One approach is to rely on your SaaS application vendor to do the integration for you.  As Mike West of the firm that produced the report, Saugatuck, puts it:

“If you're exclusively on a platform like Salesforce.com and using Salesforce.com plus other cooperating companies on AppExchange, they have their own platform that offers integration," West said.

Or to put it another way, rely on a single integrated stack from a single vendor – which sounds rather similar to the old enterprise software vendor approach.  For the same reasons as larger enterprises don’t put all their applications in a single vendor’s basket (functionality mismatch, over-dependence on a single supplier), many firms going the SaaS route will probably want to mix and match SaaS offerings from multiple vendors or combine in-house applications with SaaS.  While SaaS vendors do claim to provide integration hooks, this simply brings them back up to the same mark as in-house hosted applications.  This isn’t any more daunting than the other integration issues facing large organisations –and fit well into SOA programmes.

However, for smaller organisations this may be new territory and they are faced with two alternatives:

• Do the integration in house as part of a SOA strategy for instance suffers from the problems I covered last time around the lack of support for development life cycle.  For larger organisations with sufficient in house IT expertise, this may be acceptable.  For smaller ones, it is a far from simple decision.  And the decision becomes exponentially more important and potentially painful as the number of applications to be integrated increases the problem exponentially. 
• Alternatively, you can go to a third party integration SaaS which offers to host the integration logic for you - such as BT (among others) has offered since last year.

Deciding which to go for will require a significant investment of time and effort as the decision will have far reaching consequences.

Ronan

WS-Madness

OK, I think it is time to stop all the WS-Madness. Web services standards have become a complete joke. As far as I can see, there are now at least 70 (seventy) web services standards and drafts - more than anyone could humanly want, and enough to create chaos, and completely negate the advantages of standards in the first place. Standards are supposed to increase choice, but with so many the likelihood is it will actually REDUCE choice (do you support standards 27, 39 and 40? no, I support 23, 42 and 63 though, any good?).

So, who is to blame for this debacle? Well, the blame is pretty evenly spread. Perhaps the most obvious target is the vendors, who have unashamedly used WS standards as a battleground to try to create differentiation from competition. So, by creating a standard that fits in with ones own design, it is then possible to use this as a reason for rejecting other players. However, vendors are easy targets - but are they really the villains here? After all, you could argue that they are just doing what they have to do - trying to compete, to win business and pay their employees / shareholders. The next obvious choice is the standards bodies themselves. Sadly, there are many 'professional' standards body members who get intellectual kudos from defining standards - whether they are worth anything or not. But even this may be missing the point.

Perhaps, instead, blame should be turned on users. The vendors have stepped in because of two things - the opportunity created by the desire for standards in the SOA space, and the vacuum resulting from the failure of users to take an active role. Similarly, standards bodies have leapt into the void because in a way they have to generate standards to have any worth in the world. But the real accusation is that the standards are rubbish - most are immature, many are useless or pedantic. In other words, they do not add value for SOA users and implementers. And isn't this a case of users getting what they asked for? If users don't want to get involved to ensure the RIGHT standards are created, that really mean something to users, then they cannot complain when others jump in to fill the vacuum.

My advice to users on web services standards is to ignore all but the important ones - SOAP, WSDL, WS-Security, and maybe WS-Addressing although this is not as mature as the other three. Then take a more active role to ensure these standards mature into what you actually NEED.

Steve   

Software AG and webMethods - part II

Previously I have blogged on the SoftwareAG acquisition of webMethods, and what it might mean. Lustratus also produced a paper on the subject, here. I thought it was time for an update. now things are becoming clearer.

I congratulate SoftwareAG on listening to my comments! Well, at least partially....the company has brought together pieces from both the webMethods and SoftwareAG sides in the area of SOA, and has come up with its suite, offering an ESB (well, actually more than one), adapters, BPM, BAM and legacy and user interface integration support into an SOA suite, called - wait for it - webMethods SOA Suite!

The company has wisely decided to leverage the strength of the webMethods brand name, both in the integration/SOA space and also geographically in the US. My only criticism is that in fact I have been slightly misleading. In fact, I believe the full name is 'Software AG webMethods SOA Suite'. I just hope leaving the Software AG name so prominently does not backfire.

It seems that the suite will be made up of webMethods BAM and BPM, together with a combination of SoftwareAG and webMethods integration infrastructure products. For example, Software AG's CentraSite deals with registry/repository needs, and use is also made of Software AG's connectivity power. So, for example, webMethods EntireX deals with turning legacy code into SOA services. The ESBs are a bit confusing - there appear to be 3. One is a regular ESB, one is an ESB+ (basically the webMethods integration backbone) and one is a lightweight integration tool aimed at partner network needs.

So how is the merger going down? Well, it seems that at least some webmethods customers are glad to see the combination. Apparently this is because webMethods was actually a mature start-up - that is, innovative but not necessarily strong in internal development/delivery/maintenance processes, whereas Software AG has a reputation for being a solid, experienced and mature software brand. So presumably webMethods customers hope Software AG will bring some additional discipline to product delivery and support. 

Anyway, the proof of the pudding will be seeing whether the combination gains traction. I think it has a chance, although if only they had dropped the SoftwareAG brand from the suite altogether....

Steve

The sad state of SOA development tools

I think it is becoming generally accepted that SOA presents some pretty big issues outside of the technology domain in terms of skills and organisation.  Even before a new SOA developer in a particular organisation gets to dealing with cool new technology, he or she must understand the additional layer of process and operational knowledge in order to work within the SOA-based world. 

One example is ‘service discovery’ which for the developer means finding services which work for their task in hand and understanding how to work with them.  I use the term service discovery with caution as I do not mean automated discovery of the insidious WSDL that Steve referred to here. Rather I mean the task by which an individual developer gathers sufficient information to make the decision to use a service in his or her project.   At some point WSDL may well be needed but the task really requires search capabilities and lots of human-centric information that explains and motivates the use of each potential service.

Let’s now step back for a moment and think about SOA and infrastructure software in general:

• Infrastructure projects (whether SOA based or not) require an understanding of many aspects of both technology and business domain unlike business applications which for the most part require understanding of the business domain alone.  This raises the technical skills bar for infrastructure projects. 
• SOA is meant to reduce the cost of development and maintenance.  As there is a global shortage of highly skilled developers and these are concentrated in a smaller number of large organisations, it can only do that if it allows less expert developers be productive.  It will be of some use if it makes the job easier for the experts but this won’t help most business departments and SMEs.

How well are the current SOA enabling products are doing? In particular, have they made the task of developing SOA easier than using EAI products 5 years ago which were held to be too difficult and expensive to use by many organisations? My opinion is that there has been some maturing of development tools but in general too little has changed. This means that SOA risks running into the same skill shortages that EAI ran into.

I think there are probably a few reasons why there hasn’t been a radical improvement in development tools:

1. SOA stacks tend to focus on run-time capabilities (such as SOA run-time registries stuffed full of WSDL instead of knowledge management systems designed to guide the developer to the right service).  The reasons for this may well be that software architects recognise that run-time problems (such as lack of scalability) can’t be got over as easily as development problems: Development problems will increase the cost and failure rate, but they won’t bring down the business.
2. It is much harder to create good tools for less skilled developers than more code generation wizards that plug into eclipse that appeal to experts.  Hence if you look at most SOA stacks, they will include forms-based user interfaces which help the already knowledgeable programmer with some routine tasks.  They do not allow the newbie to focus on the business logic instead of the integration logic.  Unfortunately, this point is somewhat obscured when people say they don’t need yet more new technology for SOA – they really mean they don’t need more new run-time technology.  They certainly need more productive development tools.
3. Middleware has put the premium price on run-time software and development tools have traditionally been sold for low prices or even given away. This may be because developers in early adopting companies tend to be more technically skilled and put lower value on easy-to-use tools.  They also favour tools which augment their own skills – rather than tools which make it easy for somebody less skilful.  What this means is that it is hard to fund or build a business selling really good development tools.

All of which leaves a significant challenge for SOA adopters and vendors.  In order to be successful with SOA, significantly better development tools are needed.  For this to happen, end-users need to push their vendors and be willing to pay them when the tools are delivered. 

Ronan 

p.s. If any readers want to point me at some good SOA development tools, I would be delighted to take a look.

SOA development is not so easy

I was reading Ronan's latest post, and something leapt out at me. Ronan was quoting a successful SOA adopter;

"Reflecting what is a common experience, Kershner highlights the biggest challenge as managing and coordinating as many as 30 different project teams over 15 to 18 months."

This made me think. SOA is all about loosely coupled applications and processes, where silos are cast aside in favour of building solutions consisting of multiple, distributed and diverse components. This seems to me to point to a real challenge for those trying to implement SOA-based solutions. Consider a company running a major application silo in a legacy environment such as a mainframe. When changes are needed, there is effectively a single team with much the same skills that has to be managed to achieve the results. Now move to an SOA picture. The new requirements will be satisfied by implementing a loosely coupled set of services, spanning multiple technologies, platforms and even locations. Granted, as the pool of reusable services grows, this will become faster, cheaper and lower risk. However, from a project management point of view, it provides a bit of a headache. Instead of managing one team of same-skilled people, the requirement is now to manage multiple teams, quite possibly in different parts of the organization, to achieve the same ends.

I am confident this problem is surmountable, but it is yet another factor of SOA to take into account when planning integration initiatives. To me, it underlines perhaps the most important success factor of all in SOA adoption - communications (the people sort!) are key.

Steve