Why do so many SOA adopters moan about low reuse levels?

I was reading a recent post from Joe McKendrick the other day on measuring SOA success…

…and it reminded me of a related issue – that of measuring services reuse. SOA adopters often moan to me that despite having implemented SOA and deployed many services, reuse rates are down at the 1-1.2 level – in other words, virtually no reuse. They seem to want to pick a fight with me because as an advocate of SOA I have often pointed to reuse as one of the more measurable benefits. After all, achieving a high level of reuse is a clear indicator to business executives that efficiency is increasing, since the implication is less development is required to do new things.

I am starting to get pretty short now inthese conversations. I wish, wish, wish that people would heed my previous advice – don’t think of SOA delivering reusable services, think of it as a great tool for SHARED services. Obviously reuse will come through services being shared – so what point am I trying to make? The problem is people are choosing to build ‘reusable services’ with SOA and assuming that others will start reusing them. It is the old ‘Build and they will come’ philosophy. This rarely works – it is worse than a scatter-gun approach. If users instead think about what services would be good candidates for being shared first, and then develop these as SOA services, reuse levels will definitely improve.

So, when getting started with SOA, don’t encourage everyone to start building code into services and hope that reuse will come as if by magic. Start off by deciding on the logical services to build that will be shared – things like get customer history, or create new customer. Then go ahead and build these shared services candidates, and see reuse levels climb….hopefully making it easier to justify your SOA investments to the business.

Steve

A practical approach to Open Source (part 1)

I am often asked about OSS (Open Source Software) – I am not sure whether it is because I have been somewhat outspoken in the past…

…or whether it is because users are not completely sure whether they can trust the marketing messages put forward by different OSS projects and their supporters and are looking for an independent perspective. However, I have decided to jot down a few thoughts around OSS, based on a practical and logical assessment. I have gathered these observations into four areas

  • What are the user benefits of open source?
  • What are the risks?
  • How does the particular open source project business model work?
  • What needs to be done to achieve the benefits?

This first post deals with the first area – what are the user benefits of open source?

I guess the most common one users bring up is that OSS is free! No license fees has got to be good, hasn’t it? Just one work of warning here – it is worth checking the exact terms for the specific OSS software to validate that it really IS free. Strange as it may sound, some ‘OSS software’ is NOT free of charge.

However, there are other potential benefits to consider. For example, some users find that having access to the source code is a benefit. This may be because the user can now make changes to customize the software so it is more effective for the company, or the confidence it brings that a failure can be resolved locally without having to wait for support organizations to respond. Once again, however, check the small print. Some OSS Software projects do NOT distribute the source, and others require any updates and new developments to be fed back into the project.

Another appeal of OSS is the fact that it can pool the ideas of thousands of technical minds across the globe. Hopefully this will mean that the code is usable and effective. Since these minds will also be available to check the code, it should also give a higher code quality. The caveat in this case is to make sure that the particular OSS project of interest really IS a broad community, and not just a small interest group or worse still a single vendor pretending to be pushing a widely supported OSS project.

Finally, there is the hoped for standardizing effect of OSS. That is, if an open source project takes off and gets wide industry backing, then all vendors are likely to find it easier to support because there is no hidden agenda of favouring a particular vendor. This can stimulate a much wider and more rapid acceptance of the particular code-based, resulting in it becoming at least a de facto standard if not one supported directly by standards bodies.

More to come – the next post will be about the risks of open source….

Steve

Pegasystems points the way forward

There is a lot of chatter in the blogosphere at the moment about whether SOA (service-oriented architecture) has run out of steam – whether companies have stopped investing in it, got disillusioned with it or cast it aside for the latest new thing.

For me, this is a silly discussion – SOA is about a way of doing things more sensibly, just as structured program was many years ago. It is really all about architecting system design around the concept of a pool of shared services, and cleaning up the linkages between different programs and applications.

So on this basis SOA is not dead, but an active and important architectural underpinning of a number of different initiatives, many of which have been rolled into the ‘SOA’ term – things like BPM (Business Process Management), SaaS (Software as a Service), Business events management, BAM (Business Activity Monitoring and many others. But has the failing world economy stopped the whole SOA family juggernaut in its tracks anyway?

The answer Lustratus picks up from its clients is a resounding NO. BPM in particular seems to be seen as a powerful way to respond to the needs of operating in an economic recession. Indeed, Lustratus pointed to BPM as a shining light in its forecasts for 2009. Validation of this claim is evident when looking at the performance of Pegasystems a major provider of BPM solutions and technologies. Pegasystems is an important indicator of BPM health because it is one of the few remaining pure-play business process software vendors left. In its recent annual results announcement earlier this month, it showed a revenue increase for 2008 of over 30% to over $200M, and importantly a 50% increase in new license revenue. It is in such good financial shape that it has even just announced a quarterly cash dividend! Admittedly it is only paying 3 cents a share, but in these times this is not to be sneezed at.

Of course, these results in isolation may not be conclusive. After all, the Pegasystems rise in sales might simply indicate it is stealing market share from its rivals. However other big BPM players such as IBM are also claiming strong performance in the segment, so it is much more likely these figures shine a light on the way forward for users as they struggle to do more with less, and get a better level of control and governance over their processes.

Steve

Will Swordfish make its point?

The ECLIPSE organization has finally made its announcement of the first release ofSwordfish, the open source ESB (Enterprise Service Bus) framework.

A lot of the work for Swordfish has come from Sopera, a German open source company that has developed an offering around the DeutschePost service bus development. Sopera offers a valid and competent framework for service integration, and therefore it is assumed that Swordfish might also work.

So, will Swordfish make a successful strike at the ESB market? So far, open source ESB projects have not had a great deal of success, and as far as 2009 goes Lustratus has forecast that open source projects will suffer due to the lack of the necessary people resources to turn open source frameworks into a useful user implementation. However, Swordfish has the backing of the influential ECLIPSE organization, which has done a lot to standardize the look and feel of many software infrastructure tools.

Looking at the initial marketing thrust for Swordfish, things don’t look to good. From the announcement letter, the top functional bullet reads

Support for distributed deployment, which results in more scalable and reliable application deployments by removing a central coordinating server.

Well – duh! This is not new – it is part of the basic definition of what an ESB does! However, this initiative is still worth watching, despite the ill-fated marketing attempts so far. ECLIPSE has significant industry backing for its GUI look-and-feel stuff, and indeed most of the big industry names like IBM, Oracle and SAP are involved in the running of ECLIPSE, and provide a lot of the financial backing.

It is this that might be the source of most excitement with Swordfish. Oracle and IBM both actively market and sell their own ESBs, and SAP offers its own equivalent functionality as part of its NetWeaver set of offerings. I wonder how they feel about ECLIPSE driving an open-source ESB version that competes on functionality and is free? I would love to be a fly on the wall in internal ECLIPSE meetings about the future of Swordfish.

Steve

Is the time right for Progress Software to be bought?

In the course of my ongoing analysis of software infrastructure vendors I was intrigued by the recent earnings release from Progress Software…

…and it caused me to dig a bit deeper. Basically, Progress is holding its revenue stream although not growing it, and I guess in today’s environment that is OK. But when the performance of the company over the last few years is considered, a different picture starts to build up.

Basically, Progress made a lot of money from its OpenEdge database product, and this business is still providing a rich ‘cash-cow’ revenue stream. However, not only has this stagnated but it is starting to decay, with Q109 showing a sharp drop. Admittedly this is probably in part due to currency movements, but the trend is clear – this is not a growing business ans the writing is on the wall, at least in the longer term. Progress knows this, and so over the past few years it has been on the acquisition trail, trying desperately to find a new business that can grow sufficiently to become the new OpenEdge. It has tried the area of Data, with its DataDirect division growing through acquisition, but this business has reached a steady state with little or no growth. It tried the area of messaging, being the company that brought the term ESB (Enterprise Service Bus) to the world through its SONIC line of business, but having got a great mindshare and market position it lost focus and this business is now fatally damaged, with others such as IBM, Oracle andMicrosoft taking up the mantle. Recently it acquired the APAMA complex event processing business, Actional (SOA management) and IONA (a datedintegration business based in Ireland). It has since found some success with the excellent APAMA offering in the heartland of financial market data processing, but has struggled to replicate this success in other industries and use cases. Actional has also had some success but it is immutably tied to the SOA star which is having its own problems. And IONA, similarly to Progress, has a nice legacy integration business based around Orbix but has failed utterly over the years to create anything else worthwhile.

The result is that although the IONA purchase has increased revenues in the Progress ‘integration infrastructure’ business unit, this is likely to be a one-off improvement and once again Progress is going to be stuck with an aging cash-cow and no clear rising star to take over responsibility for driving growth.

This might seem a recipe for Progress itself to be acquired. Up to now, this has been unattractive due to the share price, but in thecurrent climate the acquisition looks a lot more interesting. My view is that there are probably two strong candidate acquirers for Progress:

  • Companies looking for attractive maintenance businesses where profit can be maximized by cutting expenses and taking the money until the product line sunsets
  • Companies not currently in the integration space but wanting to get into this lucrative area and looking for a ready-made product set (perhaps to underpin a professional services business)

Who knows what will happen in the current turmoil? I may be way off the mark, but if I was a company fitting either of these two categories, and I had the money, I think now would be a good time to strike. After so many false dawns, I suspect the Progress management team might not resist too hard….

Steve

    What use is technology without flexibility?

    I was reading a post today from mainframe integration vendor GT Software…

    …about its support of IBM’s mainframe speciality engines, and I was suddenly hit by the realization that in order to really add value for users, technology almost always has to be accompanied by flexibility. The two need to go hand in hand if returns are to be maximized and business risk minimized.

    The specific example discussed relates to an IBM mainframe invention called a speciality engine. For the uninitiated, think of a logical processing box within the overall mainframe environment where processing is much cheaper, with different boxes being aligned to specific activities such as running LINUX operations, data access or Java-type activities. What this basically means is that if part of your workload is doing something that is supported by one of the speciality engine types, then you can choose to run it more cheaply by moving it into this engine, and in fact this can often improve performance too.

    This is neat technology, offering the opportunity to reduce costs and improve effectiveness, and various mainframe software suppliers have jumped on the opportunity this offers by moving eligible workloads onto these specaility engines. However, as with any new technology development, things are not quite as simple as they seem. In the IT industry there is a terrible tendency to jump for a new technology and push everything onto it, without appreciating the implications. But, in this example, as pointed out in the referenced post,

    There are many use cases where it is much more efficient to NOT shift workload to a specialty engine. Why — because, there is overhead associated with moving workload

    This is typical with just about any new technology. It is great in SOME circumstances, but loses out in others. iPODs are great for listening to pop music, sounding little different to CDs and being very much more convenient, but try them on classical symphonies and you will wonder what has happened to the color and magic of the piece. The key is to use new technology for WHAT MAKES SENSE, as opposed to what is possible. There is another angle to this flexibility too. IT vendors often ignore the fact that users are not starting from a clean sheet of paper; they have existing investments and technologies that cannot just be written off. Therefore, it is important to have the flexibility to operate with whatever is in place rather than demand a specific new technology component. This is not a static need, but a dynamic one – it may be that a company might change its approach further down the line, and a rigid, inflexible technology implementation can cause terrible future headaches.

    While new technology may promise a lot, it is only when coupled with flexibility over which technologies to use, for what, and when that technology can REALLY deliver its full value.

    Steve

    Don’t be afraid to ask for SOA help

    While the number of SOA success stories grow, there are a lot of companies that are finding SOA a struggle.

    As often happens when something gets heavily hyped, managers are almost embarrassed to admit that they are having trouble. But the truth is that for many, getting outside help may be the best way forward and end up giving great returns.

    There seem to be three common SOA ‘failure’ scenarios.

    • This SOA-based project is blowing its schedule/budget/SLAs
    • We are diligently implementing SOA, but we just aren’t getting the returns we expected
    • Everybody agreed SOA was a great idea, but now nothing is actually happening

    It is easy to feel that these scenarios must reflect badly on management or technical efforts, since other companies seem to have succeeded with no problems. But in fact, it is perfectly natural to find SOA difficult. In essence, SOA is REALLY different – it is a different way of working, the tools are different, programming is different, design is different…..and so on. However, an important corollary of the success of SOA in other companies is that there is a growing pool of knowledge around SOA procedures and best practices. Already, there are some professional services organizations that have embraced all this accumulated knowledge and developed service offerings specifically designed to unblock the SOA logjam – getting projects moving again, finding why the SOA strategy is not delivering, and clearing up any organizational or procedural blockages.

    Companies should not feel bad about asking for help. It really can be worth it, even if there is an initial investment hit. And fortunately, once IT and business professionals get the hang of SOA, they wont need the outside help, so the cost hit does not have to be an ongoing one. The key is to make sure companies choose the right partner. This is a subject that is discussed more in a recent Lustratus Report, “A little help goes a long way”, that can be downloaded for free from the Lustratus web store.

    Steve

    Message-driven SOA – what goes around?

    Starting from when I was running IBM’s MQSeries business, in the 1990s, I learnt a big lesson about seeing things from the user point of view.

    We had a great messaging product, and it started the EAI (Enterprise Application Integration) market rolling. Soon, vendors were pitching the wonders of business integration through an all-encompassing EAI framework….and users started moaning about it being complicated and too hard. Vendors brushed off these concerns and just shouted louder, and I was an evangelist in this….and then I started actually listening to users. I remember pitching for all I was worth on the strategic value of EAI, and then a user saying to me, “Steve, we believe you. But we can’t get there in one jump – at the moment, what we really need is to hook this application up with that one, that’s all”.

    For a moment my strategic eye was offended. How could you take this wonderful, clever, strategic software and then just hook two applications together? What a waste! But of course, I then learnt the practicalities of life, and the imperative to focus on the business need. If the business needs Application A to talk to Application B, then that is what it will fund, and that is what it wants to achieve. Sweeping frameworks are all very well, but for most companies practical considerations come first.

    Now I am having deja vu, all over again. I believe in SOA – I am an evangelist. I can see the huge benefits it promises as a strategic platform for business agility, business visibility and cost-efficiency. And yet, talking to users it has finally sunk in that while some of the more lucky companies have the funding and resources to go the whole hog with SOA, there are a large number of users who ‘just want to link A to B’, but want to do so in a way that is consistent with a goal of enterprise-wide SOA some time in the future.

    The new Lustratus report, free from the Lustratus web store, discusses a more tactical approach to SOA – “message-driven SOA”. It points out that even for those companies who are terrified by the prospect of having to work out their process implementations and flows, change the way they work and deal with business transformation issues, there is a way to leverage SOA ideas in a tactical, simple way that is at least a step on the road to overall SOA adoption. Message-driven SOA is almost a reprise of the tactical use of messaging in the 1990s, but with an SOA spin on it. So, message-based flows loosely couple applications and programs together, delivering the benefits of business integration without necessarily having to get tangled up in full-scale process re-engineering and modelling. And yet, the reuse concept of SOA is also leveraged, together with the ability to expose these message-based integrations as SOA services.

    Message-driven SOA may not be the answer to every problem. As a rule of thumb, it will be most attractive for integrations that are primarily of the application-to-application kind, where human interaction is limited and tasks are of short duration. But it is well worth a look to see if this simpler approach to getting tactical SOA benefits might be useful.

    Steve

    Will Intel’s attack on appliances work?

    At the recent Gartner SOA show in London, I was surprised to see a stand from Intel.

    Turns out Intel are striking back at the burgeoning SOA Appliances market. The Intel claim is that its ‘software appliance’ performs at least as well as Appliances, and is therefore a better option.

    The Intel argument is based on the fact that when you buy an appliance, you are locked in to the platform eg the box. So, as time passes, your appliance misses out on latest hardware or chip developments since it is hard-wired. In contrast, if the same performance can be obtained in pure software, then this has the advantage that it can be moved onto a platform with more power if needed, or as platforms are upgraded it can benefit. And Intel claims that its sexy software can match or exceed appliance speeds because it is so highly optimized.This optimization is apparently all around the XML parser. This makes sense in the SOA Appliance space because most SOA Appliances are seployed to deal with high volumes of XML conversions. The Intel claim is that it has a super-slick parser and that is how it can beat the Appliance.

    This certainly throws up a new consideration when looking at the case for appliances, but of course it should be remembered that performance is not the only reason people buy them. Off-loading from the production platforms is another reason, and not having to worry about the platform management is another (install, config, etc). However, the Intel argument is a good one. Perhaps the biggest worry I have, however, is that whatever one company has done in software, someone else can do too, and unless it is patent protected, there would be nothing to stop an appliance maker coming up with a super-fast parser, and then putting it into microcode. It seems to me that in the end hardware will always be faster than software.

    Steve

    IBM events make an impact on SOA

    IBM certainly seems to see SOA as a key initiative, if its annual SOA show is anything to go by.

    The IBM Impact 2008 even in Las Vegas attracted more than 6000 attendees, and they can’t all have gone just for the weather! But the most salient aspect of the event as far as I was concerned was the ‘event’ support – not the army of people ensuring the party ran smoothly, of course, but the addition of the WebSphere Business Events product.

    Event handling has always been possible with WebSphere, but it was messy. Triggers could be set on different queues, and conditions could be detected in various ways, but the whole thing was pretty technical and complex. However, IBM’s new product, based around its acquisition of AptSoft technology, delivers exactly what business users are looking for; the ability to write business rules in their own language that can control operations.

    One of the key characteristics of SOA is that it breaks monolithic application stacks into individual services, each executing a discrete piece of business functionality such as ‘Get Customer Details’ or ‘Book Delivery Date’. In addition, information flowing in and out of these services is cleanly architected in a standards-based fashion, and is therefore easily accessible. But this opens up a magnificent opportunity to deliver business control over operations through the use of business rules that implement corporate policy by changing execution and flow.

    For example, if a bank wants to offer students the opportunity to make payments from their accounts with no charge, a business rule could be written that says ‘If account holder is a student, then skip the charge calculation step’. This is a simple example, but with the addition of a correlation capability IBM has ensured that much more complex rules can be put in place. Consider the type of rules needed to mitigate the risk of fraud, for instance, where multiple conditions from a range of different systems would need to be assessed to detect suspicious activity patterns.

    The key is that these things can be achieved with the use of business rules that the business analyst can understand. This makes change quicker, and reduces the risk of misunderstandings between the analyst and IT technical staff.

    With the addition of WebSphere Business Events support, IBM SOA has finally grown up. I guess the next step could now be a comprehensive BAM solution……we can but hope.

    Steve