Lustratus LiteBytes

Archive for May, 2009

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

I have to confess up front that I have never been desperately comfortable with Enterprise Architecture (EA) frameworks and disciplines, and therefore the opinions I am about to express should be taken in that light.

However, I do worry that EA may be handcuffing some companies to the point where potential benefits are strangled at birth.

I was recently reading an interesting article by Nagesh Anipindi, entitled “Enterprise Architecture: Hope or Hype?”, which discusses the lengthy presence of EA as an innovation and considers the reasons for its failure to move into the mainstream of acceptance. As Nagesh writes,

For 2009, Greta has predicted that more than half the existing EA programs are at risk and will be discontinued in the near future. Remaining ones that survive this economy, per Greta, will struggle with framework and information management problems.

Nagesh goes on to postulate that the current pressures on IT budgets will result in a lot of EA efforts being abandoned, not because they are unworthy but because they fall below other more critical areas such as Operations and development of new business solutions. He then goes on to say that once the industry realizes the massive benefits that EA can deliver, he believes this situation will turn around and EA will become an essential part of every corporate IT organization.

I think Nagesh may have missed the point slightly, although I agree with a lot of what he says. Look at one of the many definitions of Enterprise Architecture, as Nagesh records it -

Gartner defines EA as: “Enterprise Architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.

This definition epitomizes the problem as far as I am concerned. The basic purpose of EA is there, but clouded with the sort of mumbo-jumbo that frightens off potential decision-makers. What is EA REALLY about? It is about tying the IT architecture and implementation to the business vision and needs, both now and in the future. It is about making sure IT really serves the business. Does this require communication? Of course. Does it require principles and practices – yes. But the complex phrasing of this definition is typical of ‘EA Experts’. These people talk of EA Frameworks, of EA Models, and of rigid procedures. From an intellectual point of view, this is all absolutely fine. If you were writing a thesis on how to architect an enterprise IT system to match business needs and to be able to continue to do so, it might be perfectly acceptable to introduce loads of models, a single tool-driven interface, definition language and frameworks.

However, this is the real world. The danger I see is that this over-enthusiastic approach can tie the hands of professionals and organizations so tightly that they cannot achieve anything. There is also the danger that when this approach is considered over time, it introduces a real skills problem, with the need to train new people on all these tools and methods which do not actually contribute to delivering new business value. In effect, the mechanisms to deliver the effective enterprise architecture develop a life of their own and start to consume development resources for their own purposes as opposed to business needs.

A small example may illustrate my point. In the old days, when I worked with IBM, a purist movement pointed out that because we wrote our design documentation in English, we were impacting quality and accuracy by introducing the potential for misunderstandings as to what a passage of English might actually mean. As a result, IBM worked with Oxford University to develop a mathematically-based specification language to eliminate the problem. This made complete sense at an intellectual level. However, although this language was adopted for a time, there were always new people coming onto the team who didn’t understand it, and training began to be a real overhead. Eventually, the language was dropped. Although it made intellectual sense to use it, it did not work at a practical level.

I am all for Enterprise Architecture – at least in spirit. I believe the role of an Enterprise Architect is exactly to ensure that the technology correctly delivers on the business needs, and is architected in such a way to enable new business changes to be implemented quickly and effectively. But I don’t think this requires a complex framework of models and requirements tools and so on. In fact, I think a strong EA edicts the minimum, but offers a loose framework that allows departmental innovation. In truth, there is nothing new about EA – it is all about doing things sensibly and remembering that IT is there purely to serve the business and not itself. All the rest of the formal EA clutter is a set of handcuffs that can hold organizations back.

Steve

There have been many reports recently on the problems with SAP’s Software as a Service (SaaS) offering, Business ByDesign – see for example the article by Timothy Morgan here.

To summarize, SAP is backing off its initial, bullish claims on SAP Business ByDesign, saying that it is now going to proceed at a much slower pace than originally planned. Of course, the SAP trade show Sapphire, which is being held this week, might provide more info, but I somehow doubt it.

So, what is going on? Why the sudden backtrack? After great trumpeting 18 months ago from SAP about Business ByDesign being the magic bullet for SMEs, offering the ability to run remote copies of SAP applications on a per user basis without having to cough up for a full license, why the hesitation?

I suspect the truth of the matter may be partly political, partly execution oriented and partly financial. There are those who would argue that SAP does not really WANT a SaaS market for its packages to come rushing into existence. After all, from a supplier point of view wouldn’t you prefer to sell more expensive licenses that lock the user in rather than a cheap usage-based service that the user can walk away from at any time?  So the conspiracy theorists would say SAP deliberately tried to freeze the market for SAP SaaS offerings to discourage competition and slow down the emergence of this market.

On the execution side, perhaps it is possible that SAP did not realize that selling SaaS solutions is a world away from selling large application suites directly to big companies. SaaS solutions are low-cost high-volume as opposed to high-cost low-volume, and hence need much more efficient and layered distribution channels – and SMEs are used to picking up the phone to ask someone whenever they have to change something, not a great strength for SAP’s support structure.

Then finally, the financial side. Many SaaS suppliers have discovered an uncomfortable truth – while in a license model the user pays a substantial sum of money for purchase followed by maintenance, in a SaaS model the risk position is reversed, with the supplier having to put the resources in place up front to support the POTENTIAL usage of the infrastructure by all those signed up users and then receiving revenues in a slow trickle over time. Is it possible that SAP just didn’t like the financial implications of having to continually invest while looking at payback times of years? Did they therefore decide to deliberately throttle the number of new customers, giving them a chance to make some money before making more investments?

Maybe SAP will tell all at Sapphire … or maybe we will just have to keep guessing.

Steve

As one might have expected, Microsoft tried to ignore the Enterprise Service Bus (ESB) movement for a long time, but eventually it had to do something to answer demands of its customer base looking for SOA support.

Its response was Microsoft ESB Guidance, a package of

architectural guidance, patterns, practices, and a set of BizTalk Server and .NET components to simplify the development of an Enterprise Service Bus (ESB) on the Microsoft platform

Let’s be honest. This is a typical Microsoft ‘fudge’. Microsoft ESB Guidance is not a Supported Product, but is instead a set of guidelines and one or two components. It is a Microsoft Patterns and Practices offering – in other words, you are on your own. This may be fine if you are a Microsoft development shop, but far more worrying if you are real business user with extensive Microsoft presence. It has a lot of the disadvantages of Open Source, but you still have to pay for Bizt Talk etc..

So what does the future hold? Will trying to bring the Microsoft server world into the SOA domain always be a matter of risk and going it alone? Will Microsoft productize Microsoft ESB Guidance? Are there any alternatives other than just consigning the Microsoft platform to run in isolation on the fringes of the enterprise?

Fortunately, the Microsoft model may actually be working here. I do not believe Microsoft will ever productize ESB Guidance – after all, they have had two years and are still maintaining there are no plans to do this. However, what this position does do is it encourages opportunists to jump in and develop products based around the Microsoft technology and guidance materials. An example is Neuron-ESB, from Microsoft specialists Neudesic.

So, while Lustratus strongly cautions users about the effort, cost and risk of using Microsoft’s own ESB Guidance package, the idea of utilizing a Microsoft-based supported ESB product from a specialist vendor is much more attractive. Of course, whether these new Microsoft-based ESBs are any good is yet to be seen….

Steve

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