LiteBytes from Lustratus Research

Selling EDA and SOA to the business

The second Integration Consortium conference call on EDA was held yesterday - kicked off with a short presentation by Lustratus. These conference calls are primarily discussions by practioners and how the discussion pans out can be very different to what might be expected at the beginning. Yesterday was no exception, the starting point was how to build a business case for EDA but moved to a more specific issue: How do you (and even should you) introduce the concept of EDA to an organisation already committed to and busy with a SOA strategy.

There is no simple answer to this: Much of what a good SOA programme brings to an organisation in terms of enterprise architecture and governance is immediately transferable to EDA. And I have previously written about how EDA can be used in conjunction with SOA. The more general issue is how do you translate a technical architecture into business benefit. Much has been written about this in the context of SOA over the last couple of years and it is easy to formulate generic approaches that sound plausible (my favourite in SOA arena is the recipe proposed by some that starts "get a senior management sponsor" - sounds easy, right?).

However at the end of the day, business cases are business specific and quite often EDA or SOA will slot into an unexpected project (as is highlighted by Mike Kavis here - ) because the capabilities EDA or SOA delivers match the project goals, not because having SOA or EDA is a requirement. If you want to get a EDA or SOA kicked off, it is often a matter of understanding the value delivered and matching these values to projects that have to happen anyway.

Ronan

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

Trouble with evaluating SOA ROI

I was trying to think how to get another TLA in that title, since I think you get a prize for having three three-letter-acronyms in a row. However, the topic is definitely getting a lot of attention as companies try to decide whether SOA is worth the effort. The problem is, SOA benefits span a wide range, and are often difficult to assess. And yet, as John Soat notes in Information Week, real customers are showing major gains with SOA.

My take is that it is important to sort benefits into a spectrum of tangibleness (if such a word exists). So, reducing redundancy should have an actual dollar value reduction in maintenance costs - a tangible number. Delivering the agility to deal with new regulations more quickly is difficult to estimate in dollar terms, but could even be a survival issue. Seems to me the key is to find a way to include the full range of elements in any justification or evaluation.

Perhaps one way to add a dollar value benefit on some of the intangible benefits is to ask the executive in charge of the area most affected how much they would be prepared to pay to solve the issue. So, it might be interesting to ask the CFO how much he would invest to ensure the company could comply with new regulations within the assigned deadlines. This, then, becomes a tangible number that can be plugged into the case.

Steve

IBM's Information on Demand streamroller gains speed with the Princeton Softech acquisition

IBM announced the completion of its acquisition of Princeton Softech - a company which focused on data archiving, classification and discovery software.  All of which sounds quite specialist until it is put into the context of IBM's Information on Demand (IoD) strategy.  Back in March, Ambuj Hoyal, who heads us IBM's Information Management division (with responsibility for the Information on Demand strategy) explained:

"... an inflection point occurred in 1996 when there were many techniques to create Web sites or do Web-based business... We are at a similar inflection point in 2006. We have myriads of techniques – metadata management, ETL (extraction, transformation, and loading) tools, data creation tools, Federation tools, cleansing tools, profiling tools. People use these tools to solve the information challenge."

To translate, IBM see a huge opportunity and are putting serious money into it - this acquisition is the latest of 21 which are part of this strategy (to see the list go here).  The opportunity is to build an information management platform which allows organisations to create, maintain and (most importantly) extract value from the myriad of data sources which flow around the enterprise.  Data cleansing, data distribution, data integration and master data management (among other areas) are each expensive activities but often have clear budget and value associated with them - this even before getting to semi-structured information which is also with the Information on Demand remit.  While there are best of breed solutions to different parts of the puzzle, there aren't single integrated solutions - which is what IBM hopes to offer.  Interestingly, IBM has yet to move on Business Intelligence vendors - it appears to have correctly realised that the major task is not creating dashboards; it is ensuring that what goes into the dashboards is correct and timely. 

Any familar with the area of enterprise data management will realise that the challenges inherent in building and deploying such a platform are formidible.  At a recent briefing IBM gave Lustratus, the whole area of data governance in particular was highlighted:  how do you organise structures and responsibilities to ensure that coherent and consistent data definitions can be used and reused through the enterprise (this should sound very familiar to anybody involved in SOA - just switch the word service for data!).  To figure out how to do this right IBM set up the Data Governance Council back in 2005 with many leading financial services and telecoms companies (among others).

Yet again getting into detail is beyond the scope of a normal blog - but I would recommend anybody with a passing interest in BI (or indeed enterprise architectures) to take a look at IBM's web-site on Information on Demand. Of course the strategy is not without obvious challenges:  The technology is from many different sources (even if it now all belongs to IBM) and there is a significant amount of complexity associated with solving such a complex problem.  Also, when there isn't a significant regulatory stick (Basel II for instance), I imagine it could be very hard to sell at a strategic level.  This is because while there are clearly valuable uses of Information on Demand, but there seems to be no common theme around which business momentum can be built.  And finally, its association with the term business intelligence may well go against it - already some analysts are wondering where IBM's query tools will stack up against Business Objects et al (not a relevant question as BO and others will sit on top of IoD) and in many cases the proposition is operational efficiency or regulatory compliance, not (to my mind at least) classic BI.

Ronan

Use a hot-house to get better productivity

I was keynoting at the DeutschePost SOA Days technical seminar held in Bonn, Germany last week, and while I was waiting to present I sat through a very informative presentation from a large telecoms company about its efforts with SOA. However, one point that really caught my attention was the fact that the company has had some success with improving productivity through focusing on 90-day cycles. This extremely challenging timeframe is assisted greatly by the SOA approach used by the company, but a key element is that new projects start off life with a 'hot-house' activity.

The idea is to gather the core team of people involved in the project in one room, for however long is required, to spec out the project and select the implementation approach. This looks at the business and IT requirements and implications. What I love is that this 'hot-house' is carried out in a special room where there is only local networking available (no internet or email), and it even has mobile phone jammers to block calls. Results appear to have been extremely impressive. The hot-house sets the scene for a rapid development effort. Admittedly not every 90-day cycle completes the project - it can determine that another cycle is needed for additional research for example, but project delivery has definitely speeded up.

As for me, I just want one of those mobile phone jammers - I would love to take one on the train, and turn it on intermittently.....

Steve

Does Microsoft need a SOA strategy?

Whether or not Microsoft actually has a SOA strategy is far from clear (in the sense of actually committed to SOA in a strategic way as opposed to covering the bases in sufficient depth to be credible through alliances and product tweaking). However, its latest announcements around BizTalk seem to have sparked off another wave of attacks from people who are deeply suspicious about its commitment and motives. For instance, Dana Gardener of Interarbor, really lets rip:

"My take is that inside of Microsoft its aggressor A-types are all about dissing SOA and promoting .NET ad nauseam. At the same time the Microserfs and developers must understand the inevitability of SOA for at last a portion of the most advanced and innovative enterprises’ and service providers’ architectures."

To quickly jump off the fence: I don't believe that Microsoft is as any way close to being as commited to SOA as most of the other industry majors (IBM, Oracle, Sun, SAP et al). However, this may not be a bad strategy for Microsoft right now. The reasons why this is so are well expressed by The CIO Weblog:

"Microsoft doesn't have to have an SOA strategy now, anymore than they needed an Internet strategy before Netscape or a search strategy before Google. ...A recent IDC research report shows them holding a comfortable lead in the architecture and platform development tools that will be used to build out whatever SOA most companies will bother to develop in the near future. And as frequently been pointed out, here and elsewhere, it's not so easy to break the inertia that large corporate IT shops generate when they make those initial choices. Microsoft has plenty of time to manuever, and as of yet, little need to do so, clamoring of pundits aside."

While many would argue that Microsoft's lack of internet and search strategies significantly damaged the company, it is not an unreasonable argument for SOA if you consider their customer base: The smaller Microsoft only shops aren't in the first waves of SOA adoption anyway, the larger Microsoft only shops will be bound to use Microsoft tools and finally the large enterprises which are a mix of Microsoft and others (I would suggest these are vast majority of the "the most advanced and innovative enterprises" mentioned above) will use Microsoft tools in their SOA strategy when needed.  Why? Because SOA is an architecture - not a product category: You can get started mostly using exsiting tools.  Therefore, Microsoft are guaranteed to be in the SOA programme frame anyway and so doesn't need to try "to win" its share of initial projects.

So, are there risks for Microsoft and its customers associated with its take on SOA? Yes, I think there are major risks and these will become apparent over the next 12 to 18 months: Firstly, as customers who mix Microsoft with non-Microsoft get deeper into SOA, they will move beyond relying on existing tools and need more and more tooling designed specifically for SOA.  This tooling is more likely to come from vendors who have a deep SOA commitment. This will risk Microsoft's share of the pie in the large mixed accounts.

Secondly, as IBM et al create SOA-based solutions for common emerging customer problems (think the next Basel II or Sarbanes-Oxley or CRM), Micosoft will be disadvantaged because the SOA based solutions will be more consistent with the customers' existing architectural direction (i.e. SOA). This will not only limit their growth in the mixed accounts, it will also limit their ability to enter new large enterprise accounts. 

Of course, this is all predicated on SOA remaining a popular and growing architecture ... and however unlikely it may seem today to SOA advocates that SOA could hit a wall, this is probably Microsoft's real bet.

Ronan

The onward march of Linux falters - any lessons for OSS SOA?

Linux may be reaching a natural plateau with regards to corporate adoption as a UBS survey reported that 90% of CIOs not currently using Linux will not make the leap in 2007 (this is up slightly from 87% in 2006) according to a UBS survey reported on here and here.  In effect this means that those who are open to Linux are already using it and the hold-offs are mostly not about to change their minds any time soon.  This should not be regarded as some sort of 'peak Linux' type event as organisations already using Linux in some places will continue to extend their usage of the OS.  The report also reinforces the point that Linux is mostly replacing Unix rather than taking market share from Microsoft which is sometimes characterised as the target of Linux.  All of which really means that Linux is coming to the edge of its natural market - UNIX shops which can easily switch - and will struggle to break into organisations which are traditionally Microsoft only.  This does not mean that Linux is not wildly successful and making a lot of money for companies selling services around it.

Turning to OSS and Service Oriented Architectures, are there any lessons to be learnt?  At one level the Linux story bears very little relationship to SOA based projects - Linux was about the commoditisation of very mature specifications and technologies while software associated with SOA is comparatively immature (when compared to Linux/UNIX) and lacking in any specifications in many cases. Also, with Linux  the old established industry giants now rule (IBM et al with the exception of Red Hat as a new giant).  In contrast, OSS SOA is still mostly the preserve of startups (such as Mule Source , Bostech and  Sopera, as well as some integration specialists (IONA) and ... Sun and Red Hat. 

As I said above, Linux may be plateauing but at a huge scale.  Inevitably, OSS SOA will also reach its natural extent but the risk is that it may reach it before the service providers can achieve viable scale because right now the market for OSS SOA is large enterprises with java skilled developers who are willing to even consider the risk of replacing closed source integration products.  This is a finite market with a lot of incumbent solutions.  Moreover, this is a very tough market for any new solution:  evaluation processes are becoming more and more extended and even if selected the project may well be dumped as IT budget continue to be stretched.  [One could argue that the same challenges face the 'closed source' vendors but in their case they are able to extract more revenue from a small pool of customers and remain financially viable.]

Am I therefore saying that OSS suppliers are doomed in SOA?  Not at all - I believe that there is an opportunity for these businesses to succeed (and become the RedHat of integration perhaps?) but it will be a tough going.  In particular, it is a lot harder than suggested by most coverage of OSS which focuses on huge download rates and arguments such "Its free, developers love it, everybody will use it" and ignoring the real world issues around adopting any enterprise integration technology (which are mostly not related to the license fees). 

Of course the OSS suppliers already know this and are developing different strategies to address the problem.  For instance, Mule Source is particularly focused on promoting community based development of additional components such as application adapters and transports - thereby deeping their engagement with customers and making it easier for customers to get a 'complete' integration solution - and has recently launched MuleForge to support this effort. IONA has been buying OSS expertise and has relaunched its OSS efforts (now called Fuse) deliberately focusing on the most popular Apache SOA-related projects with the obvious benefits of existing customer base and large pool of developers.  RedHat is also acquiring technology to provide strong data management capabilities by open sourcing MetaMatrix which is currently closed source.  Other suppliers have different ways to crack this nut but whether any of these strategies will succeed or fail is of course more complex than can be easily covered in a blog entry of reasonable length - however we will be addressing the area in upcoming Lustratus papers.

Ronan

Reuse still seen as top SOA benefit

I was interested to see, in a recent survey carried out by PMP Research, that the top-scoring benefit expected from SOA adoption was still reuse. The research was documented in the September 2007 issue of Conspectus, and on 1 1-5 scale 'Business process service re-use' scored 4.1 on the benefit list, followed closely by 'provides a more effective integration platform'.

Many SOA advocates talk about SOA being fundamental in terms of building a flexible and adaptable infrastructure while aligning IT and business requirements more closely, resulting in a more agile and effective platform for supporting business needs - so how come reuse still tops the list?

My own view is that reuse is simply the benefit that is the easiest to take in. The others I list above are very powerful, and can promise significantly more overall business value, but they require more than just a technology change. They require changes to working procedures and practices, and much better communications between business and technical communities. So, perhaps, in the eyes of the pragmatic respondents, reuse suggests itself as a reasonably obvious gain which even has a fairly clear and measurable monetary return attached. Reducing redundancy should have a direct correlation on application maintenance costs, for example. And on top of this, it can deliver value from a purely IT point of control (although the value will increase if business departments are involved too).

Steve

Aberdeen report highlights need for proper testing of SOA: Surprise

I generally don't get too upset about surveys stating the obvious - what is obvious to me may not be to somebody else and vice versa.  However I think Aberdeen's report on SOA testing as reported on by Joe McKendrick in his ebizq blog needs some comment.  It should be said in the report's defence that it does make a valid if incredibly obvious point.  To quote Joe:

"New research from Aberdeen Group shows that to effectively test and provide QA to SOA, companies are testing not only vertically (using unit and functional testing as their benchmark for quality) but are also testing horizontally across an entire business process. In addition, in successful testing/QA environments, there is close involvement of the business user in more phases of the development lifecycle"

And from the report itself:

"It isn't enough to just deploy automation, and it isn't enough to simply rely on functional tests.  QA for composite applications needs a horizontal, process-oriented view, not the vertical unit-test methods used in the past."

The insight is what any professional software developer has known to be good practice for years: when you deploy a new system you need to do "integration testing" and "system testing" - testing all the pieces of the final system work together and checking that it works against spec (which should involve business users).  If the system is distributed the testing will need to cover that added complexity (the horizontal, process-oriented view as referred to).  That this is promoted as something new amazes me. 

Don't get me wrong on this: In SOA, testing is an even more important than usual aspect of your software development process because a fault introduced in one service may result in down stream problems across multiple systems which use that service.  As many organisations adopt SOA, they will need to scale-up the sophistication of how they test software and detect problems in live software.  These are areas which certainly justify survey based analysis.  However, Aberdeen's conclusions as reported by Joe seem to stay in the realm of the obvious.

Ronan

Don’t forget productivity when selecting SOA software

When I talk to vendors of SOA software about their offerings, I always focus on the tooling provided with the product – from development tools to deployment tools to life cycle management tools.  Of course vendors will claim that their products are easy to use and highly productive.  Unfortunately, these claims are often not properly challenged as products are being selected for SOA projects based primarily on functionality and ‘enterprise’ attributes.  This is partly because it can be quite hard to establish just how productive the software will be when used outside the demo or pilot comfort zone.  I said unfortunately above because anybody involved with integration projects (SOA or otherwise) will understand the high proportion of effort spent on dealing with the unexpected incompatibilities or consequential issues:  Effort which can be significantly reduced with good tooling.   

Another part of the problem is defining what we mean by easy to use and productive.   In particular, whether a tool is easy to use or productive is closely coupled with who will be using it.  A productive tool for an expert java developer is very different from a productive tool for a business analyst.  Without unfairly blaming our marketing friends, there is a tendency in the industry to assume anything GUI based must be suitable for business analysts and so long as it works in Eclipse, java developers will be happy.  (For instance, I remain to be convinced that the business process execution language, BPEL, is something any business analyst would use - pretty interfaces or not) Needless to say, reality is much more complex and when evaluating the tooling around your preferred product makes sure to match the capabilities against your developer base and not be fooled by the apparently pretty pictures (or lack of them).

Ronan