LiteBytes from Lustratus Research

The forgotten SOA benefit - Visibility

There has been a lot of chatter recently about measuring SOA ROI - take a look at Loraine Lawson's recent blog for instance. or Gartner's results of a UK-based survey of SOA adopters. However, one of the benefits that I think a lot of people miss, or do not attribute enough importance to at least, is Visibility.

Basically, the visibility story goes that with SOA, since you break up operational components into discrete business services, then it becomes easy to monitor entry and exit to these services and hence business operations flow. This gives a clear picture in business terms of execution and performance - not just what is happening, or how many times, but HOW business is being carried out.

Gartner did touch upon visibility, 

"Improved Efficiency in Business Processes Execution - Isolating the business logic from the functional application work enables a clearer view of what a process is, and the rules to which it adheres. This can be measured by lower process administrative costs, higher visibility on existing/running business processes, and reduced number of manual, paper-based steps; better service-level effectiveness; quicker implementation of process iterative or of variants of the same process for different contexts."
 

However, the Gartner focus was only on visibility as it relates to execution efficiency. In fact, SOA-based visibility offers another benefit which, in today's tough times particularly, can be a real big hitter for executive management. It enables management to see how process are being executed - in other words, it provides the ideal tool to monitor compliance against a growing raft of regulatory requirements across just about every industry. In order to demonstrate that your systems comply, it is necessary to be able to see what they are doing and how they are doing it. This is what SOA delivers.

So how does improved compliance management fit into the ROI picture? True, it is very hard to attach a dollar amount to compliance - however it certainly matters. With the amount of public and political scrutiny of corporations today, it is absolutely imperative that executives can show they are faithfully adhering to regulations and guidelines. Failure to do so will not only risk severe penalties, but also probably lose them their jobs! Now THAT's a compelling business case....

Steve

BPM is flying off the shelves - at least at Pegasystems

It's always nice to be proved right. At the end of 2008, when Lustratus published its 2009 predictions for the infrastructure market, we highlighted BPM and predicted that 2009 would (at last) be its year. In March I discussed the impressive 2008 for Pegasystemsin a previous Litebytes post, and now the company has made its 1Q09 announcement of earnings. 

Briefly, we are talking about revenue increasing 29% YOY to $62.4M for the quarter, and license revenue up a storming 60% to $28M. Recession - what recession? Admittedly the results were skewed a little by a single large deal closing at around 12% of the total, which may put Pega under pressure for the next quarter, but this cannot disguise the point we made in our 2009 predictions - tactical, targeted BPM can deliver the real savings and flexibility to support broadening customer bases and types that businesses are looking for in the current economic downturn, or can respond to specific business channels such as tracking and reducing fraud.

The other point that these results reaffirm is that companies are looking for solutions that are geared to their own industry vertical needs - Pegasystems has a strong industry framework philosophy that responds to this need very effectively. The only possible 'cloud' on the horizon seems to be Peagsystems' tentative move towards the dangerous 'Platform-as-a-Service' (PaaS) market segment - this area is a minefield at the moment and it is to be hoped that Pega do not find themselves sucked into the abyss by getting to wedded to this idea. Just stick to what you do best, guys!

In summary, for all those companies who have heard about BPM and then shied away, put off by the thought of the effort required to deployBPM across the enterprise for all processes, take another look with a tactical, laser-focused mind-set. BPM really can be selectively applied at a reasonable price, with rapid payback and an attractive ongoing benefit stream.

Steve

    

What software buyers are looking for in 2009

With the global downturn in full swing, there are a lot of concerns over how software markets will perfom. However, one trend is emerging as a vital ingredient if software companies are to succeed, and those companies that have recognized it are already benefiting.

Software buyers in 2009 are finding an industry vertical specialization to be essential to support any investment justification. The problem for many users is that although the technologies and products available offer the same sorts of benefits as before, in order to get any purchase through the system it has become critical to have a strong business backing all the way. Nothing will move if a business sponsor is not pushing for it. Of course, investments have always had to be justified, and a business alignment is a key part of this process, but in the economic downturn this focus has moved from being part of the justification to being the overriding element. A business sponsor has to be brought on board right at the beginning if the particular project has any chance of success.

As a result, companies that do more than pay lip-service to describing business benefits are prospering. The software vendors that offer truly vertical solutions, tuned for particular industry needs and taken to market by field teams with the relevant industry domain knowledge, are the ones that are succeeding. One proof point is Pegasystems, who I blogged about a few days ago. Onereason that Pegasystems has maintained such strong growth in 2008 with its BPM offerings is a strong industry vertical sensitivity. 

Another excellent example is IBMand in particular its Information Management division. Information Management software is regarded as unsexy - although still important, it has tended to be neglected in the rush towards application-oriented strategies and initiatives. Enter a new IBM management team that has restructured the go-to-market approach for Information Management software to an industry-vertical one, generating models of particular industry challenges and processes, looking at the specific needs of these industries and carrying the industry-vertical business messages to prospective buyers. Whether serendipitous or the result of impressiveexecutive insight, this approach has almost exactly dovetailed with the software buyers' needs for a more relevant, industry-related message in order to secure investment. The result is that IBM is claiming significant sales and successes in its information management software business segment, even in the current environment. 

Other software companies would do well to take note. If you want to sell software this year, you have to help your prospective buyers by going to market with clearly aligned business vertical offerings and messages.

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

Justify BPM with a free night in Vegas?

In today's climate, investment for IT is extremely hard to come buy. BPM (Business Process Management) may promise a lot, but how can it be justified? With a free night or two in the Las Vegas MGM Grand Hotel perhaps?

The Integration Consortium, a not-for-profit consortium of users, suppliers, implementers and academia focused on all aspects of business integration, is hosting its annual Global Integration Summit this year in Las Vegas, 3rd-4th June, open to allcomers, and as a special incentive it is offering free rooms to the first 200 people to register for the event. So there's the free night(s) in Las Vegas...but what about BPM? Well, for my sins I will be giving the 'Featured Presentation' at the event on how to justify BPM based on the idea of identifying the BPM Sweet Spots - that is,a range of use cases for BPM that each respond to a different investment policy. The idea is that depending on whether a company is focused on restricting resource requirements, or driving payback very quickly, or getting the biggest bang for the buck in the short term, or whatever, then there should be a BPM Sweet Spot that fits the bill. Well, that's the theory, anyway.....!

At least the free room (if you are lucky enough to get one) is one bet you can't lose on! 

Steve

Private power for BPM

Yesterday I had the pleasure of having lunch with Jan Baan, a serial achiever in the IT industry and currently Executive Chairman and CEO of Cordys, a BPM vendor. I went to the meeting wondering whether the BPM space really needs another player - my personal view is that the market is still immature in demand terms, but there are a number of well-established vendors already.

However, as a private company with a rich backer, Cordys benefits from something that public companies can often only dream about - the freedom (time and money) to do what needs to be done to deliver a 'Version 2' offering. Most public companies build a version 1 that most of us would call a version 0 (or even -1!). The pressure is on to justify the investment by delivering returns quickly. Even a VC-backed private company suffers the same problems, with anxious investors looking for assurance that their money is working for them.

But as Jan explained to me, he has been happy to bankroll Cordys with a desire to build a solution that addresses the real-world operational issues that many Version 1s ignore. As a result, Cordys tells an impressive story on subjects like performance, fault tolerance, scalability and usability. Perhaps BPM is about to benefit from a dose of Private Power.

Steve

The BPM vendor view of SOA

Oh dear. Once again I am about to be drawn into a row about vendor claims around SOA. Oh well - so be it.

I saw a link recently to a White Paper available through Information Week, by Metastorm Inc., which started off

"While an SOA can go far in addressing the important security, reliability, and re-usability of services, SOA is nonetheless a technical approach. Thus, the challenge of SOA — and the key to achieving business value — is elevating service enablement beyond just technology functions. The reality is that SOA has limited value unless it encompasses disparate applications and platforms, and most importantly, it moves beyond technology and is orchestrated and controlled in the context of business processes."

OK, I see where the BPM vendor is going with this. But there is a glaring issue here in my mind. Stating that SOA is a technical approach, and discussing the need to move beyond technology (via the use of BPM) creates the false impression that SOA services are technical pieces of functionality as opposed to business services, and that implementing an SOA is jsut a technical exercise. This is absolutely not the case. I have discussed this many times, even in this blog. SOA services lie on business rather than technical boundaries - they execute a piece of business functionality as opposed to a technical one. Indeed, as I have also stated previously, this leads users into a position where they may be 'backing into' BPM through building orchestrated SOA services, but this does not require a BPM suite. In addition, a successful SOA implementation is almost NEVER just a technical exercise - it has to involve all sorts of disciplines.

I am not against BPM suites - in fact, I think they can add a lot of value when users have the enterprise-wide maturity to realize the full range of benefits they bring. But let's make sure we keep the facts straight.

Steve 

BPM: Untangling the terminological mess

One of our missions at Lustratus is to remove the confusion that gets in the way so often in IT - in the way of understanding what technology can do for a business, in the way of understanding how to select the right product and in the way of making the right IT investment decision.  As spaces get hotter the confusion just seems to get worse!  This is certainly the case with BPM - which  usually standards for Business Process Management (although sometimes stands for Business Process Modelling which I will ignore for the moment).  As a term it can be considered from a pure business perspective or (almost) a pure technology perspective - and really fits somewhere in the middle.

Michael Dortch (a blogger at ebizq and analyst with The Robert Francis Group) had a good go at defining it from pure business perspective:

"BPM is a set of human-centric business problems that often masquerade as or are confused for decisions and issues focused on IT solutions and systems. And vice-versa."

While I think Michael is correct to drag the focus back to the business problem (particularly when addressing an IT audience), this applies equally to almost all enterprise IT issues.  I must admit that I found his argument confusing when after the statement above he gives as his first question to be answered by BPM: "What part or parts of the IT and/or business infrastructure are not working, and can they be fixed non-disruptively?".

However, attempting to define BPM from a pure technology perspective is equally flawed.  Unfortunately, Business Process orchestration standards (such as BPEL) are sometimes presented as providing BPM.  This view is flawed in two ways:

1.  BPEL does not provide process monitoring, analysis or reporting capabilities (as such it is only a part of a technology platform for BPM).

2.  It is an implementation language for technology domain processes which in turn will correspond to Business domain processes.  (Unfortunately, the colonisation of the term Business Process to mean an orchestration or sequencing of service invocations makes the previous sentence rather clumsy!) 

Therefore, BPEL and any other business process execution languages can only be part of BPM. 

Finally, I should admit that I don't really disagree with what Michael says (taking the liberty of reading between the lines a little): BPM is a balance between the business domain and the technology domain - and its purpose is the optimise the buisness domain.  As such it is really not so different to most enterprise IT concepts.

Ronan

BPEL4People: mad or not mad?

I have a lot of sympathy with Steve’s blog item on the WS-madness:  Vendors will sometimes (inevitably) cynically use standards only for differentiation, standard bodies and the professional standard writers will do what they are paid to do: write standards.  And finally end-users are too disengaged to make sure the standards solve the problems they want solved.  All of which was going through my mind when I was reading the recently published BPEL4People standard:  Is BPEL4People just another piece of WS-madness?  (BPEL4People is an extension of WS-BPEL to handle human involvement in business process modelling and execution.  BPEL is the WS specification for defining business processes.)

To answer my question, I came up with the following simple sanity test (which many WS-standards fail):

1. Does it address problems that users have today or reasonably expect to have tomorrow?

2. Is it the unique standard in addressing the problem?  Anybody following of the web services standards around reliable messaging will remember the complete mess caused by multiple competing standards( WS-reliable messaging and WS-reliability).

3. Is anybody actually going to implement it?  There are too many standards both WS and previous which are never quite implemented.

In fact, BPEL has itself struggled to pass the three tests for sanity:  While business processes sound all pervasive, BPEL addresses only a subset of all business processes:  Those which have a central controller (i.e. not peer-to-peer collaborative processes which are covered by another standard), where the central controller is in the middleware (i.e. not controlled within your SAP application).  It has also been heavily criticised by BPM specialists who prefer more formalism than BPEL attempts to provide.  Therefore, it struggles to pass points 1 and 2.  These limitations have meant that many users are slow to adopt BPEL and are sometimes happy to stick with non-standard approaches with better capabilities.  All of which led to vendors delaying implementing BPEL for a number of years - which is point 3.  (However, I believe that BPEL does now make the sanity benchmark for those who need it and on that basis would have to disagree with Steve’s exclusion of its from his sane list.)

Turning to BPEL4People, the intention of the standard is to create a “BPEL extension to address human interactions in BPEL as a first-class citizen“.  To put it another way, it attempts to tie human-workflow back into the BPEL standard which is mostly used for system to system workflow (or business process flow if you prefer).  This means that BPEL4People contains concepts such as human roles, groups and tasks.

Returning to my sanity tests:  On the first test, BPEL4People certainly addresses a problem I have seen where some human interaction is required in a system-to-system business process.  It is a subset of the set of users of BPEL itself – maybe less than 50% of all BPEL use cases. 

A bigger criticism is at point 2:  You could (and many have) solved the problem BPEL4People addresses with BPEL on its own.  Yes BPEL4People provides standards where people made it up as they went along but it is not clear that the overhead of a new standard justifies its creation.  Finally, is it going to be implemented:  On the face of it, SAP, BEA, Oracle and IBM’s backing makes it a simple answer: “Yes”.  We will have to see.

All of which means that for the moment BPEL4People scrapes a bare pass on the sanity test:  If you are sure that your problem domain needs this type of functionality I recommend watching how implementations develop and planning on transitioning to BPEL4People when they are mature.  Otherwise, you already have standards and solutions capable of muddling through with.

Ronan