Skip to main content

Innovation World 2008 Israel


I attended Software AG's Innovation World 2008 held in Israel this week. I haven't had a chance to take a look at Software AG's strategy since about 2 years ago, when I was working intensely with Webmethods which Software AG purchased.

Attendee's are pretty firmly divided between Software AG's mainframe product lineup, namely Adabase and Natural, and Webmethods customers (or those looking forward towards SOA technologies). While Software AG has been extending their legacy product line to offer mainframe transactions as web services, they're clearing focused on Webmethods as an ESB and BPM provider as their future.

While the conference lineup had a number of senior Software AG people, including some technical Ph.d's, the tone of the conference was decidedly marketing. Customer success "movies" were presented throughout. Presentatons were very high level overviews with much marketing fluff.

The only presentation with any technical information was the final one, where a demonstration of webMethods mainframe link products was shown, with some mainframe green screen apps turned into web services with "a few clicks". Once the whole environment is set up - which is not a trivial task - exposing mainframe transactions or scraping green screen apps really can be a click through process. It is impressive, but rarely goes as smooth as the magic demo.

There was much high level talk of BPM (Business Process Management) and BAM (Business Activity Monitoring), which are the focus up-market tool sets of webMethods. While BAM truly is impressive and a very flashy ability to show to the business, it relies on the key business processes and key data points of those processes being exposed as services already (and better via the webMethods ESB). The setup time for this runs from months to even years (for a comprehensive picture), though a focused project can expose a key point or two within weeks if the existing app structure allows for it.

While there is some excitement in the market about the latest webMethods tool announcement of webMethods Insight Runtime Governance, there was no info presented at the conference. There was a presentation on SOA Governance as a high level discipline, but it was the most hollow presentation on the topic I've seen. To sum it up in one sentence, "Process Control aka Governance is required for SOA success." Umm, yep.

I had a brief conversation at the end with the head of the local Software AG office about webMethods presence in Israel. He stated that basically webMethods products had yet to penetrate the local Israeli market, but they were hopeful this would change in 2009 and were focusing upon very large scale deployments. It waits to be seen whether the "start small and grow the footprint" or "start big and make your SOA toolset THE SOA toolset for your customer" approach" will be more successful.

The crowd was surprisingly large given the size of the local market. Two speakers were locals, but the vast majority Software AG management.
Labels:

Popular posts from this blog

Integration Spaghetti™

  I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of th
Read more

Solving Integration Chaos - Past Approaches

A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology
Read more

From Spaghetti Code to Spaghetti Connections

Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider
Read more