Lustratus LiteBytes

Archive for the ‘Industry trends’ Category

Lustratus has just published the 2010 edition of its popular infrastructure software market predictions. This year, highlighted areas include BPM, BRMS, Cloud Computing, SOA Appliances, Integration, Security and even software patent litigation.

Every year Lustratus goes through this exercise, trying to identify the key trends for the year. Perhaps the most traumatic part of the forecast is the scoring of the predictions from the previous year – always an opportunity for embarassment. Fortunately, Lustratus has had a pretty good record over the years.

This year Lustratus is highlighting trends such as the continuing success of business alignment software like BPM, the effects that Cloud Computing is likely to have on the market, the resurgence of interest in good old integration. The Lustratus predictions can be downloaded at no charge from the Lustratus web store.

Steve

So Progress Software has bought yet another software company; this time a BPM vendor, Savvion. But is this the right move for Progress?

Progress Software has spent most of its life growing through acquisition, making use of the piles of cash generated by its legacy mid-range database product to find new areas of growth. After all, the legacy business may be highly profitable, but its returms are dwindling by the year and Porgress desperately needs something else to shore up its balance sheet. Unfortunately its acquisitions have had a bit of a patchy record of success. Perhaps it will be different this time.

Savvion is a credible BPM (Business Process Management) software provider, and 2009 was a bumper year for BPM sales. Specialist companies like Pegasystems and Lombardi showed huge growth rates, bucking the downward trend triggered across many technology sectors by the economic upheaval. On top of this, Progress has been trying to establish itself as a viable SOA (Service Oriented Architecture) and business integration vendor ever since it launched the Sonic ESB in the early years of the last decade, and BPM was a glaring hole in its portfolio. For these reasons, it is easy to see why Savvion would seem a good fit.

There seem to be two problems for Progress, however. Firstly, BPM is now rarely a solution bought in its own right – hence the rapid consolidation of the BPM market with Pegasystems more or less the only major oure-play BPM left standing following IBM’s acquisition of Lombardi. Instead, BPM is deployed more and more as part of a business transformation strategy involving components such as SOA, application and data integration, business rules, business monitoring and business events management.  Secondly, the gorillas in the space are now IBM, Oracle and SAP. These companies all offer a full suite of products and more importantly services based around BPM and the rest of the modern infrastructure stack. Companies such as Software AG, TIBCO and Axway form a credible second tier, too.

In previous acquisitions, Progress has treated each acqusition as purely software products. This is not surprising, since selling databases is more about selling products than selling solutions. However, it is this factor that has been at the root of the patchy performance of Progress acquisitions. For instance, the Data Direct division of Progress, where it placed a number of acquisitions in the data space, has fared reasonably well. This is because it is more of a product business. However its attempts in areas such as ESBs and SOA governance have suffered due to a seeming reluctance to embrace a more industry-specific, services-based solution model.

With its acqusition of Savvion, Progress once again has the chance to try to show the market that it has learnt from its mistakes. BPM is absolutely an area where companies need to be offered solutions – products together with services and guidance to develop effective and affordable business solutions. It will be hard enough for Progress to cut a share of the BPM pie with all the big players involved, but it does have one outstanding advantage; it has a strong and accessible customer base in the mid-range market where the larger companies struggle. However, if it fails to take on board the need to hire industryvertical skills and solution-based field and service professionals then this acquisition could prove to be yet another lost opportunity.

Steve

IBM’s acquisition of ILOG has resulted in a great new opportunity to unlock the business value of CICS applications by turning the COBOL logic into easy-to-read/edit ‘business rules’.

IBM has taken the ILOG JRules Business Rules Management System (BRMS) and made it part of the WebSphere family. But even better for CICS users, IBM has made this business rules capability available for CICS applications too. This whole subject is discussed in more detail in a new and free Lustratus Report, downloadable from the Lustratus web store, entitled “Using business rules with CICS for greater flexibility and control”. But why is this capability of interest?

The answer is that many of the key business applications in the corporate world are still CICS COBOL mainframe applications, and although these applications are highly effective and reliable, they sometimes lack in terms of flexibility and adaptability. Not unreasonably, companies are loath to go to the expense and risk of rewriting these essential programs, but are instead looking for some technology-based answer to their needs for greater agility and control. The BRMS idea provides just that. Basically, the logic implementing the business decisions in the operational CICS applications is extracted and turned into plain-speaking, non-technical business rules, such as ‘If this partner has achieved GOLD certification, then apply a 10% discount to all transactions’. This has a number of benefits:

• It becomes easy for rules to be changed
• It becomes easy for a business user to verify the rules are correctly implemented
• If desired, business users can edit operational rules directly

While BRMS is a technology with a lot to offer in many scenarios, it seems particularly well suited to legacy environments, providing a way to unlock increased potential and value from existing investments.

Steve

I am doing a lot of research into Cloud Computing at the moment, and spent an enjoyable morning with Salesforce.com, one of the largest Cloud vendors.

However, one thing that particularly piqued my interest was the discussion on Cloud lock-in. One of the most frequent concerns I hear from companies thinking about Cloud is that they are worried about vendor lock-in. After all, with Cloud being so new, what if you lock into a supplier who does not survive?

The discussions with Saleforce.com highlighted an interesting aspect to this debate. One of its offerings, force.com, provides a ‘Platform as a Service’ (PaaS) cloud offering, where users are presented with an environment in the cloud complete with a whole host of useful tools to build their own applications to run int he cloud or customize existing ones. However, Salesforce.com offers its own programming environment which is “java-like” in its own words. This immediately raises the lock-in concern. If a company builds applications using this, then these applications are not portable to other Java environments, so the user is either stuck with Salesforce.com or faces a rewrite.

A bad thing, you might think. BUT Salesforce.com claims that the reason it has had to go with a Java-like environment is that this enables it to provide much improved isolation between different cloud tenants (users) and therefore better availability and lower risk. For the uninitiated, the point about Cloud is that lots of using companies share the same cloud in what the industry calls a multi-tenancy arrangement, and this obviously raises a risk that these tenants might interfere with each other in some way, either maliciously or accidentally. Salesforce.com has mediated that risk by offering a programming environment that specifically helps to guard against this happening, and hence differs from pure Java.

So, is this lock-in a bad thing or good? I don’t know whether Salesforce.com could have achieved its aims a different way, and I have to admit that to a cynic like me the fact that solving this problem ‘unfortunately’ locks you into the supplier seems a bit suspicious. However, this is irrelevant since the vendor is doing the work and has chosen its implementation method, which it is of course free to do. Therefore, the question facing the potential force.com user is simple – the strategic risk of being locked in to the supplier has to be balanced against the operational risk of possible interference from other tenants. Depending on how the user reads this balance, this will determine how good or bad the lock-in option is.

Steve

Software AG seems to be defying predictions and surprising the market at every turn.

Once seen as a sleepy European software house based largely around legacy system technologies, it has taken major strides to transform itself into a major global software industry player. Its acquisition of webMethods a few years ago surprised the market, with many analysts unconvinced that it could make a go of the move into integration / SOA middleware, but it has done a fair job of building some momentum by tying the webMethods portfolio up with its own CentraSite governance technology, providing service-oriented architecture (SOA) with integrated governance.

Then it once again shocked the market by snatching IDS Scheer, the well-known supplier of modelling tools, from under SAP’s nose. Given that the IDS Scheer technology is used by most of the major SOA suppliers across the world for modelling, and in particular is a key part of the SAP portfolio, this would appear to give Software AG lots of cross-sell opportunities across the two customer bases and throughout the SAP world.

Now it has announced its 2Q09 results, and they make pretty good reading ont he surface. A 9% increase in product revenues is particularly noteworthy give that so many companies are struggling to show any year-on-year growth in product sales. However, before getting too carried away it is worth delving a little deeper into the numbers. The product revenue numbers include maintenance as well as license sales. Licensesales actually fell, as with most other companies. Maintenance revenues jumped by 20% – does this mean that the company has built a much larger maintenance base, or is it actually a reflection of a more aggressive pricing policy? Then there is the split between the legacy business (ETS) and the SOA/BPM business(webMethods). License revenues in this segment were down 15% – not very encouraging since this is the strategic business unit. Also, it is noticeable that maintenance revenue in each segment increased by about 20%, suggesting that this rise does indeed reflect a price hike.

However, taking all this into consideration, Software AG is still looking to have moved forward substantially from a few years ago, and assuming the IDS Scheer acquisition goes through OK there should be lots of opportunities for the company. Of course, a cynic might point out that by adding IDS Scheer to the webMethods portfolio, the company has made itself a highly attractive acquisition target to someone – perhaps SAP?!

Steve

Micro Focus announced its latest mainframe migration tool, ReUZE yesterday – and once again it has completely missed the point.

The background is that for companies looking to move off the IBM mainframe, Micro Focus has been offering solutions for a number of different target platforms, but in each case the solutions have been based around the old emulation concept. Once again, it seems the company has fallen into the same trap. As the press release states

Unlike other solutions which insist on rewriting mainframe application data sources for SQL Server, or removing mainframe syntax from programs, the Micro Focus solution typically leaves the source code unchanged, thereby reducing costs, risk, and delivering the highest levels of performance and reliability.

The highlighted end to this statement is where I have a problem. Micro Focus seems to think that by offering an emulated environment for mainframe applications, it is reducing risk and delivering the best possible performance and reliability. But this is a load of rubbish. Think about it from the point of view of the mainframe user that has decided to move away from the mainframe – in this case to a Microsoft environment. This is a big step, and the company concerned must be pretty damn sure this is what it wants to do. It has obviously decided that the Microsoft environment is where it wants to be, and as such surely this will include moving to a Microsoft skills set, Microsoft products and tools – database, security, and all the rest. So why settle for an emulation option?

The point Micro Focus has missed is that emulation is a way of propagating the old. After all, it originally stemmed from terminal emulation, where the object was to make sure that end users still saw the same environment even when their workstation technology changed. This was very sensible, becuase it focused on the right priority – don’t force the end users to have to retrain. But let’s be clear – emulation costs. It provides an extra layer of software, affecting performance and scalability, and puts future development in a straightjacket because it propogates the old way of doing things. However, in this case the cost of retraining end users would far outweight these implications.

But in the situation where a user is moving off the mainframe to a Microsoft world, why would the user want to propogate the old? Yes, the user wants to reuse the investments in application logic and data structure and content, but surely the user wants to get to the destination – not be stuck in purgatory, neither in one place nor the other. Why restrict the power of .NET by forcing the user to operate through an insulating emulation environment? Why hold the user back from moving into the native .NET database system of SQL Server and thereby leveraging  the combined power of the operating system, database and hardware to maximum effect? Why force the user to have to maintain a skills set in the mainframe applications when one of the reasons for moving may well have been to get to a single, available and cheaper one?

Yes, the Micro Focus approach may end up reducing the risk of the porting process itself, since it tries to leave mainframe code unchanged, but that is a long way from reducing the risk of moving from one world to the other. And as for the comments on leaving everything unchanged to ’deliver the highest levels of performance and reliability, that is just laughable. What makes Micro Focus think that the way an application is designed for the mainframe will deliver optimal performance and reliability in a .NET environment? The two environments are completely different with totally unlike characteristics. And when has an emulation layer EVER improved performance/reliability?

I see this ReUZE play as like offering someone drugs. If you’ve decided you want to move off the mainframe to .NET, I have a drug here that will reduce the pain. You will feel better …. honest. But the result is you will be left hooked on the drug, and wont actually get where you want to be. If you have decided this migration is for you, don;t try to cut corners and fall for the drug – do the job properly and focus on the end goal rather than the false appeal of an easy journey. Just Say No.

Steve

I was recently pointed to an article in Mainframe Executive magazine written by David Linthicum on the subject of “Mainframe SOA: When SOA Works/When SOA fails”.

I think the friend who suggested I read it was making mischief, knowing my views on the subject of SOA and guessing (correctly) that this article would wind me up.

In summary, the article says that SOA is a large and complex change to your core architecture and working practices and procedures, and that the success or failure is dictated by questions such as executive buy-in/resourcing/funding/skills, and not technology selection.

The truth about success with SOA is that it has little to do with the technology you want to drag into the enterprise to make SOA work, and more to do with the commitment to the architectural changes that need to occur

I have two problems with the opinions stated in this article. The first is to do with changing attitudes to SOA, and the second with the technology comments.

Let me first state that I am well aware that if a company wants to adopt an enterprise-wide SOA strategy designed to take maximum long-term benefit from this new way of leveraging IT investments, then this requires all ofthe areas brought up in the article to be addressed – skills, management buy-in, political will, funding and a strategic vision coupled with a tactical roadmap. I have no beef with any of this.

But I would contend that the world has changed from two years ago. The financial constraints all companies are experiencing have more or less forced the long-term strategic play onto the back burner for many. Some analysts actually like to claim that SOA is dead, a statement designed to be controversial enough to gain attention but to some extent grounded in the fact that a lot of companies are pulling back from the popular SOA-based business transformation strategies of the past. In fact, SOA is absolutely not dead, but it has changed. Companies are using SOA principles to implement more tactical projects designed to deliver immediate benefits, with the vague thought of one day pulling these projects together under a wider strategic, enterprise-wide SOA banner.

So, as an example, today a company might look at a particular business service such as ‘Create Customer’, or ‘Generate Invoice’, and decide to replace the 27 versions of the service that exist in its silos today with a single shared service. The company might decide to use SOA principles and tools to achieve this, but the planning horizon is definitely on the short term – deliver a new level of functionality that will benefit all users, and help to reduce ongoing cost of ownership. While it would have been valid a few years ago to counsel this company to deliver this as part of an overarching shift to an SOA-oriented style of operations, today most companies will say that although this sounds sensible, current circumstances dictate that focus must remain on the near term.

The other issue I have with this article is the suggestion that SOA success is little to do with the technology choice. Given that the topic here was not just SOA but mainframe SOA, I take particular exception to this. There are a wide range of SOA tools available, but in the mainframe arena the quality and coverage of the tools vary widely. For example, although many SOA tools claim mainframe support, this may in actuality simply be anMQ adapter ‘for getting at the mainframe’. Anyone taking this route is more than likely to fail with SOA, regardless of how well it has taken on the non-technical issues of SOA. Even for those SOA tools with specific mainframe support, some of these offer environments alien to mainframe developers, thereby causing considerable problems in terms of skills utilization. It is critical that whatever technology IS chosen, itcan be used by CICS or IMS-knowledgable folk as well as just disributed specialists. Then there is the question of how intuitive the tools are. Retraining costs can destroy an SOA project before it even gets going.

For anyone interested, there is a free Lustratus report on selecting mainframe SOA tools available from the Lustratus store. However, I can assure companies that, particularly for mainframe SOA, technology selection absolutely IS a key factor for success, and that while all the other transformational aspects of SOA are indeed key to longer term, enterprise-wide SOA there are still benefits to be gained with a more short-term view that is more appropriate in today’s economic climate.

Steve

Recently I have been involved in a discussion in the LinkedIn Integration Consortium group on managing data in a Cloud Computing environment, and the subject has turned to security.

I had maintained that data security concerns may sometimes result in companies preferring to look at some sort of internal Cloud model rather than risk putting their data in the Cloud-

the concept that I find is intriguing larger companies is the idea of running an INTERNAL cloud – this removes a lot of the concerns over data security, supplier longevity etc.

This generated a reaction from one of the other discussion participants, Tom Gibbs of DiCOM Grid.

I hate to poke at other commentators but security is an overarching issue for IT and telcom as a whole. No more and probably less of an issue with cloud or SaaS.

It’s almost amusing to watch legacy IT managers whine that b/c it isn’t local it isn’t secure. I’m sorry but this is totally naive.

This brings up an important point. What Tom is saying is that the Cloud provider will almost certainly offer top-notch security tools to protect data from unauthorized access or exposure, and therefore what’s the problem?

The answer is that the executive concern with putting data outside the corporate environment is likely to be more of an emotional rather than logical argument. With so many topical examples of confidential information being exposed, and executives knowing that regulations/legislation/corporate policies often make them PERSONALLY responsible for protecting information such as personal details of clients/customers/citizens, for example, the whole thing is just too scary.

IT folk may see this as naive, just as Tom says. After all, modern security tools are extremely powerful and rigorous. But of course this depends on the tools being properly applied. In the UK, for example, there have been a number of high-profile incidents of CDs or memory sticks containing confidential citizen information being left on trains and exposed to the media. The argument allowing data to be taken off-site was based around the fact that policy required all such data to be encrypted, making it useless if it fell into anyone else’s hands. These encryption algorithms were top-notch, and provide almost total protection. BUT the users who downloaded the information in each of these cases did not bother to encrypt it - in other words, if the procedures had been followed then there would have been no exposure but because people did not implement the procedures then the data was exposed.

These situations have not only proved extremely embarrassing to the data owners involved, but have resulted in heads rolling in a very public fashion. So the concerns of the executive moaning about risk are visceral rather than rational – ‘Moving my data outside of the corporate boundary introduces personal risk to me, and no matter how much the experts try to reassure me I don’t want to take that risk’. Of course less sensitive information will not be so much of a concern, and therefore these worries will not affect every Cloud project. But for some executives the ’security’ concern with moving data into the Cloud, while not logically and analytically based, is undeniably real.

Steve

I have just returned from a couple of weeks around and about, culminating in presenting at the Integration Consortium’s Global Integration Summit (GIS), where I presented the Lustratus ‘BPM Sweet Spots’ paper.

One message seemed to come out loud and clear from the conference – pragmatism is the watchword for 2009.

There were two other analyst presentations apart from the Lustratus one, and I was surprised to see that both presenters pitched a message along the lines of ‘you will never succeed with SOA/Integration/BPM unless you get all the strategic planning and modelling for your enterprise done first’, combined with a suggestion that the presenter was just the resource to ask for help! This contrasted sharply with my own presentation of choosing tactical targets for BPM rather than going for a strategic, enterprise-wide, fully modelled approach.

I was wondering if I had read the mood wrong in the marketplace, but then the eight or so user case studies all proved to be tactical strikes for specific business benefits rather than the more extensive strategic approach more common a year or so ago. It was nice to be vindicated – it looks like 2009 really IS the year of pragmatism and short-term practical considerations.

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