Moving Targets

We’re glad that the Orlando area is having a temporary break from its drought, because it forced us to stay inside the walls of our faux Italian villa resort complex while attending Pegaworld 2007 to stick around and see how a few Pegasystems customers are actually implementing BPM.

One shouldn’t generalize, but when we look at BPM, customers expect it to either (1) provide a more business-focused approach to integrating applications, or (2) offer a more flexible, reusable framework for developing custom applications that are simply too complex or address requirements beyond the scope of conventional packaged software. Call it a freak of sampling, but at the conference, most of the customers we sat down with were trying to pick up where the ERP folks left off.

Pegasystems provides a rules-driven approach to BPM that it recommends be implemented using iterative, rather than waterfall development. Among those we spoke to today, one customer, Helphire Group plc, took that advice to the extreme with an approach that fused principles of agile development and lean manufacturing called Lean Software Development.

Their presentation raised an interesting riddle: to what extent can you apply agile principles to implementing a technology whose hallmark is agility?

Helphire is a UK business process outsourcing firm that performs various services for auto insurers who are dealing with policyholders who have had accidents. The project was to replace the 15-year old core business system that dated back to the company’s founding. What’s interesting is that the company’s IT managing director, who championed the lean techniques, knew well what he didn’t want. In a previous life in the employ of the UK government, managing IT director Richard Edwards was involved with development of SSADM, a mother of all waterfall development processes.

Helphire benefited from having an entrepreneurial culture, where the CEO and founder remains very hands-on, and business users are encouraged to engage with IT and vice versa. And it benefited from having an IT director who was also a process expert — and knew how to pick his targets. In this case, selecting a bare bones implementation of the core end-to-end process, but without all the branching. OK, you couldn’t use the software, but at least business users could be impressed that the thing could work.

Six months, and four more release cycles later, the system went live.

A hallmark of lean manufacturing and agile development is that you postpone final decisions to the latest possible point so you can stay sync’ed with customer demand — which in this case is software project requirements (or “stories’ in agilespeak). A “master engineer” who is supposed to retain the vision is supposed to play final umpire, so the project doesn’t stray or get weighed down with scope creep as users get greedy.

Not surprisingly, we encountered a wide spectrum of reactions to Helphire’s lean approach. Among them was another attendee that had dabbled with agile, but unfortunately picked the wrong target and failed. Not that his company was the only one vulnerable to failure; in an earlier incarnation of this project, Helphire itself failed with an aborted 18-month ERP implementation.

The skeptic speculated that in an age of SOX and related corporate governance regulation, no CFO in his or her right mind would sign off on a project whose goals are moving targets. What’s interesting is how Edwards compared classic waterfall vs. lean development. In one of his metaphors, he described waterfall as a process where you aim, re-aim, then shoot, while lean is more a process of shoot, then redirect.

Our advice? When shooting first, you’d better know your target.

Oracle Pulls a Fast One

By now it’s no secret that Oracle’s made M&A one of its core competencies. What interesting about this week’s grab is that this one appears to be directly at SAP’s expense.

The company in question, Interlace Systems, offers something that Gartner terms an “Integrated Planning System.” In other words, a planner of planners. The guiding notion is that manufacturing enterprises have separate planning silos in sales, operations, and finance that have traditionally proven difficult to reconcile. That is, marketing may want to boost overall penetration, sales may target specific customers, while the financial side has profit goals. Yet, a strategy to target customer A could come at the cost, not only of operational efficiency as certain orders gain precedence over others, but that it may be at cross-purposes to increase overall market penetration and wind up killing margins.

Interlace’s tool provides an Excel spreadsheet interface atop a federated data model where you can test drive different planning assumptions or strategy against the big picture. It is intended to pick up where Sales & Operations Planning (S&OP) tools typically leave off.

For Oracle, the acquisition is pretty logical. It would beef up the financially-oriented EPM (Enterprise Performance Management) tool that it picked up with PeopleSoft.

But here’s the rub. Today, the day that the Oracle deal was announced, Interlace’s own partner web page continues to give greater prominence to SAP. That is, SAP appears to be a greater than equal partner for a company that otherwise appears to be playing it straight down the middle. It is a logo’ed IBM business partner, an Oracle technology partner, and has several SAP logo certifications. More importantly, the page also includes a link to another page on Interlace’s own site describing its SAP support in more detail. As of the date of Oracle announcement, no such page existed for Interlace’s Oracle support.

As the deal gets closer, we’ll be interested to see how fast these links get broken.

As we’ve noted previously with Oracle’s offer for BEA, SAP right now is otherwise occupied with the pending Business Objects deal that represents a totally new acquisition model for them. Maybe we’re splitting hairs or parsing too many pixels. But the fact that Interlace actively promoted SAP support makes this look like the deal that SAP let slip away.

Virtual Musical Chairs

In the days following Citrix’s announced acquisition of Xensource, rumors flew as to whether this deal would in effect provide a back door for, of all players, Microsoft to step up to the plate and challenge VMware. Just this week, Citrix upped the ante with announcement of the new Xen 2.0 desktop offerings. We added our two cents to the issue in a recent BriefingsDirect podcast led by moderator Dana Gardner with our colleagues Jim Kobielus; Neil Macehiter; Dan Kusnetzky; Brad Shimmin; Todd Biske; and JP Morgenthal.

Gardner has now released the podcast; you can click here to listen to the discussion, or read the transcript.

Table Scraps

By now, you’ve probably grown pretty jaded to all the hype touting the benefits of open source. But a recent poll of members of the Independent Oracle Users Group (IOUG) provided some hard numbers explaining how one pillar of the market – Oracle database users – views the role and prospects for open source.

Just to clarify, IOUG is the Oracle database users group, and should not be confused with OAUG, which serves the ERP and CRM base.

By the way, did we neglect to mention that this open source survey of Oracle database customers was sponsored by MySQL? It conjures up an image of a mouse sneaking into a kitchen during Thanksgiving dinner and feasting on the scraps. In fact, that’s exactly the picture that was painted by the survey.

Open source use is wide but not terribly deep. Roughly 90% of respondents said they used open source software or were planning to, but it’s mostly for the commodity stuff sitting below the application layer where most organizations imbed their real value-add. Only 4% said they used open-source-based enterprise apps, like SugarCRM. Not surprisingly, the most popular open source offerings were the Apache web server, which happens to underlie most J2EE middle tier products like IBM WebSphere; and of course, Linux. In essence, customers look to open source for cheap plumbing that simply works.

And that certainly applies to databases. This being a survey of Oracle database users, it’s obvious that nobody’s replacing Oracle with MySQL or any of its open source cousins. But if you’ve got a satellite web app, there’s little risk – or cost – in using MySQL. Significantly, 20% of Oracle users surveyed reported having open source databases larger than 50 GBytes. That 20% is kind of a funny figure. If you’re an optimist, you’ll point to it as proof positive that open source databases are getting ready for prime time; if you’re a cynic, you’ll claim that the figure proves that they will never rise higher than supporting roles.

One of the survey’s conclusions was that customers embrace open source because it’s cheap, but that there are limits to that embrace because customers perceive that support or security are not yet at parity with established commercial offerings.

So how then to explain the fact that the series of freebie “Express” database offerings from the usual suspects – Oracle, IBM, and Microsoft – hasn’t dented open source use? If you’re only in it for the cost savings, theoretically Express should give you the best of both worlds: cheap and proven. Yet, 80% of Oracle Express users in this survey said they are still using open source databases as well. Evidently, Express users view these products as stepping stones where vendors strictly limited scalability so as not to cannibalize their core product, whereas they believe that open source vendors won’t purposely cripple their products going forward.

Obviously, nobody dismisses the viability of open source for basic commodity tasks, but when it comes to mission critical systems, Oracle users still know whose throat they really want to choke.

Oracle Bids for BEA

As if acting on cue to relieve us out of our misery, Oracle finally stepped up and made its expected bid for BEA. It’s no mystery that BEA’s been an acquisition candidate, as its stock -– and new product sales -– have largely languished over the past year.

Clearly BEA has hit a wall. Each of its rivals -– from Oracle and IBM to SAP, and even JBoss -– are part of larger technology stacks that venture beyond middleware. While J2EE/ Java EE appservers are hardly a growth business anymore, Oracle and IBM have been poaching around the edges of BEA’s base, while JBoss has provided a lower cost alternative to, with Red hat, is now also part of a larger stack.

As we’re writing this on Friday morning, investors don’t think that the game is over by any means. Other potential suitors like SAP and HP have for now remained mum.

Of course, you could say that SAP is now going to be a bit preoccupied with digesting Business Objects, which as we noted, is a break in the pattern for them. As deep as SAP is as an organization and in resources, can they pull off two parallel learning experiences simultaneously? We’d be a lot more bullish had SAP done the B.O. acquisition a year ago, we just don’t think they’re ready at this point.

As for HP, can you say the word “Bluestone?” Obviously, post Mercury, HP Software is a more agile creature now, and under CEO Mark Hurd, more focused on the fundamentals. But HP Software’s focus is clearly more aimed at ITIL; BEA would likely prove a distraction and have relatively few synergies with its core Business Technology Optimization focus.

We won’t rule out competing bids by HP or SAP, but we’d assign it maybe a 10% possibility.

For Oracle the upside is more obvious as it’s clearly part of a strategy that has worked: take out or pre-empt the competition. Given its flush earnings sheets, that strategy, however messy at first, has clearly proven a winner.

So what would a BEA technology stack look like under Oracle? We believe that CEO Charles’ Phillips’ strategy of continuing to invest in existing product lines will largely be the model, with the possible exception of WebLogic Server, whose market has seen much better days. Unlike ERP systems, which are their own self-contained universes, there are standards involved here, so potential migration from WebLogic to Fusion server makes sense.

Brighter parts of the AquaLogic line, like BPM and ESB, would likely find homes under the Fusion umbrella, which is based on an architecture of federation.

And as for development tools, adding WebLogic Workshop, which has recently been updated and migrated thanks to reverse acquisitions, will provide Oracle an opportunity to rationalize its otherwise schizoid Eclipse product strategy. (Oracle is a member of the Eclipse board, leads a couple projects, but JDeveloper is clearly not going to ever be Eclipse compliant). WebLogic Workshop will become another onramp to development for the Fusion middleware platform.

What’s kind of funny is how some folks are having fun with Icahn’s $6.66 billion figure. It’s for a company whose stock symbol is BEAS.

But we’re not superstitious.

Innocence Lost

While open source has drawn a halo for the community development model, recent findings from Fortify Software are revealing that some worms, snakes, and other nasty creatures may be invading the sanctuary. They have identified a new exploit that they have assigned the arcane name “build-process injection.” Translated to English, it means that Trojan Horses may now be hiding inside that open source code that your developers just checked out.

Our first reaction to this was something akin to, “Is nothing sacred anymore?” We recalled crashing some local Linux user group meetings back in the 90s. And we walked away impressed that somehow the idealism of Woodstock had resurfaced in virtual developer communities who were populating, in the words of Eric S. Raymond, bazaars of free intellectual property around the closed cathedrals of proprietary software. Open source developers develop software because that’s what they like to do, and because they wanted to seize the initiative of innovation back from greedy corporate interests who guarded IP with layers of barbed wire.

And, as success stories like Linux or JBoss attest, open source has proven an extremely effective, if occasionally chaotic development model that opens up the world’s largest virtual software R&D team. Doing good could also mean doing profitable.

Well we shouldn’t have been so naïve to think that reality wouldn’t at some point crash this virtual oasis of trust. Heck, you’d have to be living under a rock to remain unaware of the increasingly ubiquitous presence of worms, virus, Trojan Horses, and bots across the Internet. How can you be sure that at this very moment, your computer isn’t unconsciously spewing out offers to recover lost fortunes for some disgraced Nigerian politician?

Designers of open source Trojan Horses had it figured out all too well, targeting the human behavior patterns prevailing inside the community. Like the infamous Love Bug back in 2000, they both took advantage of the fact that in certain situations, we’ll all let our guard down. With the Love Bug, it was the temptation to satisfy some feeling of unrequited love.

Yup, we were one of the victims. In our case, the love bug came from a rather attractive public relations contact, who had a rather melodic name. Oh and by the way did we say that she happened to be quite attractive? Well, the morning after found us cleaning up quite a proverbial mess.

With the new open source exploits, the attack targeted the level of trust that normally exists inside the community. While developers might be wary, or prohibited by corporate policy, from downloading executables from outside the firewall, many typically trust that development server. In this case, downloading what you thought was a fragment of code from the repository, only to find (at some point) that it’s a Trojan Horse that is going to wreak some havoc when it decides to.

Given the success of the open source development model, it was inevitable that reality would bite at some point. Given the maturity of the open source world, the community will hopefully start engaging in the software equivalent of safe sex.

SAP Plays Defense

Until SAP broke the news late Sunday night, its offer to buy Business Objects had to be one of the poorest kept secrets since… the time when Oracle did not buy JBoss. It points to the reality that in a consolidating software market, it’s hard not to tamp down rumors no matter how discreet (or in JBoss’s case, not) you strive to be.

But all you have to do is do the numbers. The BI space is one of many that have lost its rationale for remaining separate. As we noted last spring when Oracle snapped up Hyperion, the BI folks have been caught between a rock and a hard place: it’s increasingly difficult to draw the line between analytic and transactional applications, or between data transformation and migration, and middleware.

And once Oracle snapped up Hyperion (the only surprise was that IBM didn’t act first, as Hyperion’s products were far more closely tied to DB2 than Oracle), conventional wisdom was when, not if SAP would follow up with Business Objects.

The obvious hang up for SAP is that such acquisitions are alien to its culture of acquiring small technology startups and rapidly absorbing them into the mother ship. B.O. hardly fit that mold, given the multi-billion dollar size of the deal and the reality that its business is too diversified for SAP to adhere to its usual acquisition script.

In hindsight it’s evident that SAP dragged itself kicking and screaming into this one. And it’s also evident that SAP wasn’t exactly in practice for megadeals, given the market’s reaction that it overpaid here. It did so because it was playing pure defense.

But SAP had little choice. Its existing BI offerings were considered to rigid to support the needs of most customers. And with Oracle raising the bar on expectations that BI analytics should be an extension, rather than an island form core transaction systems, it came down to the question: B.O. or Cognos. B.O. was considered to have the inside track because, like SAP, it’s also a European company.

SAP realizes it has to break the mold if it’s to avoid riding on last decade’s growth engine. Observers such as Enterprise Irregular Josh Greenbaum believe that SAP’s Business By Design shows that the company is willing to embrace change by embracing a highly SOA-driven approach to midmarket to delivering Software-as-a-Service. But it could be argued that SAP already prepped for this change through its TopTier acquisition, which provided much of the impetus for its current SOA strategy (not to mention former chief technologist Shai Agassi).

B.O. will be a whole new creature for SAP in more ways than one. SAP is not simply embracing BI technology, but a new corporate management style outside its core DNA.

Behind Every Successful Mashup…

The cool thing about mashups is that they are quick and easy, with the results becoming highly visible and accessible. And because of their relative ease of assembly, mashups are often thought of as disposable apps, and therefore, not typically designed with the same degree of rigor as more formally designed applications.

Admittedly, given the ease by which you can overlay your contacts list atop a Google map, issues such as architectural integrity, customer privacy protection, or access control may not necessarily be forefront on your mind. Who cares about data breaches if this mashup remains your own individual, private productivity tool?

Like a game of telephone, life gets complicated once somebody else grabs your idea, adds a new refinement, which in turn prompts somebody else to spruce up that mashup. Soon, that modest little screen that you thought would remain ephemeral suddenly morphs into the enterprise equivalent of a runaway YouTube video. And once that happens, now it’s time for someone to start worrying about issues like data currency, reliability, and access privileges. And when you take the next step and start mashing up feeds from your inventory system and UPS to start making delivery promises, you have to start exercising the same discipline that you would if this were a regular enterprise application.

We were reminded of this after a conversation with Informatica’s Ashutosh Kulkarni, who recently delivered a presentation at the AJAXWorld West conference on the role of data services in enterprise mashups. His message was that enterprise mashups face the same integration challenges as enterprise applications. Coming from a company that specializes in data integration and transformation, Kulkarni emphasized that you have to pay special attention to the data that you mash up. Call it the Web 2.0 equivalent of the old axiom, “Garbage in, garbage out.”

Mashups are simply the latest in a long line of technologies that have democratized software development and data access.

Starting with the PC, which replaced dumb terminals with real computers on end users’ desktops, succeeding innovations such as visual IDEs broadened ownership over software development from computer scientists, creating new career paths for underemployed liberal arts majors. Later, visual reporting tools freed business users from having to constantly bug IT to get routine or ad hoc reports, while the web thrust graphic designers when it came to creating corporate image. And let’s not forget Linux, itself initially the domain of departmental web developers finding new uses for decommissioned 486 PCs.

In each case, these democratizing technologies were not taken terribly seriously at the start. It took several years for IT to start exercising control over procurement of PCs, and it took several more years for IT to impose corporate standards over renegade 4GL and web development, and so on.

Web 2.0 is obviously the heir to this long tradition of back door innovation. Ajax-style development has sufficiently simplified matters that assembly of dynamic web pages has become an extremely causal task. Some of the latest tools let you pull it all off without having to learn JavaScript.

The result is that with each new wave of technology democratization, you can no longer assume that your practitioners are computer scientists. You can no longer assume that those churning out new apps, mashups or not, are necessarily internalizing architectural best practices or considering the compliance implications of their work.

Consequently, it means that all the rigor must now be made explicit. But at the same time, you don’t want to tie the hands of those who are innovating with red tape. You need a middle tier that prevents the folks innovating at the operations level from wreaking havoc, yet enables them to remain productive.

To take an obvious case, suppose you’re trying to promise same day delivery to a client in downtown Boston. If you relied on Google Maps for your routing, getting an accurate result could be a matter of chance. For instance, while the map of downtown Boston has been updated to reflect Boston’s recently completed Big Dig highway project, the satellite imagery hasn’t. You might be scheduling a delivery to an address that might not yet exist in that image.

The same concerns of course also rely to enterprise data. Just because it’s there doesn’t mean it’s reliable. Naturally, these are the problems that have long faced anyone with experience in classic IT projects ranging from ERP to data federation, business process management, and BI applications. As enterprises embrace mashups as new forms of PDQ development for more casual applications that may or may not be disposable, they still need to exercise the same vigilance when it comes to the data that populates the screens.

At the end of the day, mashups that evolve to enterprise mashups are not like enterprise applications. They are enterprise apps. The only difference is that they piece together much much faster.

Dialing Direct

For the past several years, SAP has been one of the usual suspects in pushing various standards efforts impacting Business process management (BPM). Yet to date, SAP has lacked an explicit offering, if you don’t count earlier efforts like xApps.

Of course there are loads of third parties that are profiting by exposing and integrating processes painstakingly exposed using SAP’s Business APIs and its more recent Enterprise Service-Oriented Architecture (ESOA, formerly ESA). But if you know SAP, it likes to boast an extensive third party ecosystem, but it also likes to boast its own all-inclusive wall garden of basic core building blocks.

This week at its 2007 TechEd developer conference, SAP finally let the other shoe drop. At this point, its BPM, plans are vague, but we’ve got a pretty good idea of SAP’s architectural approach.

Some of the pieces of SAP’s BPM architecture are hardly surprising. Yes, SAP BPM will layer atop NetWeaver, SAP’s middle tier platform. It will utilize a new SOA repository that, like its rivals, will support UDDI and store relevant non-web service artifacts. And it will generate BPMN, an emerging process modeling language from OMG.

What’s intriguing is how SAP will deploy, or execute business processes that are modeled in its tool. SAP wants to avoid the “roundtripping” where you’re constantly synchronizing the model with the software code and vice versa. Instead it wants to dial direct. SAP’s BPM modeler will generate BPMN, which in turn will generate Java byte code. Not Java, but the binary bytecode that runs against a compiler, or in Java’s case, a virtual machine (JVM).

In other words, SAP wants to cut developers out of the loop as much as possible. Business analysts would design the model, generate the BPMN, push a button, and poof! It’s executable. If it sounds too good to be true, it is.

For years, the notion of fully automating generation of software from models has been the stuff of pipedreams. CASE was justified based on the notion that all you had to do was generate an enterprise data model, and then you could automatically spit out consistent C or C++ code. More recently, UML modeling tools that automatically generate Java or C# have become practically ubiquitous. But in most cases, you’ll still require software developers to tweak or refactor the resulting code. And none of this dealt with byte code.

Well, we’ve come across one company that has already pulled the trick off. E2E, a company out of Switzerland, was called on by UBS to unify disparate banking systems after the company was formed by merger nearly a decade ago. Using UML to structure the logic for linking disparate banking networks, E2E concluded that they could save development time by turning the model directly into an executable. Today, their solution, which they have productized as E2E Bridge, handles millions of transactions per hour. IDS Scheer, whose ARIS language is used by many SAP customers to model their business processes, has now teamed up with E2E to present a do-it-yourself BPM solution.

So SAP’s dial-direct approach might not be as off-the-wall as it sounds. There’s obviously a risk in jumping from model to executable in that you may lose the subtleties of business logic. But that’s something that SAP has gobs of, as it owns the application layer across its client base. So we’re not surprised that SAP would take an approach that intertwines BPM further into the wall garden. And we’ve spoken with several BPM pure plays with similar ideas.

That makes us wonder if and when SAP will come out with the next piece of the puzzle: an Enterprise Service Bus (ESB). It’s staying quite mum on the topic, but offering its own bus would remain entirely consistent with its strategy to own the environment above the database. Count it sheer coincidence, but the guy who directs marketing for SAP’s NetWeaver platform happened to have come from Tibco.

IBM Gets Microsofted

For a change, the EU is gunning for IBM, not Microsoft. Throwing a possible wrench into IBM’s plans, the European Commission has decided to investigate IBM’s offer for Telelogic based on its preliminary conclusion that such a merger might have adverse effects on competition. By that, the EU is likely referring to the combination of Rational Requisite Pro and Telelogic Doors, the top tools in the requirements management space. Things are now on hold until at least February 20, when the EU commission issues its decision.

Although the Doors might be closing, there might be a silver lining for IBM.

In a sentiment that’s widely shared, my CBRonline colleague Jason Stamper speculated that the deal if consummated would likely put ReqPro’s future in doubt, as it’s less scalable and less up to date than Doors.

But as we noted after the deal was announced, the real jewel in the crown for IBM was the System Architect tool that came to Telelogic through the Popkin Systems acquisition back in 2005. Covering enterprise architecture (EA), it’s a piece that’s been conspicuously missing from IBM’s Rational portfolio. And there are some smaller fill-in-the-gaps pieces, like embedded device modeling and software product lifecycle management, which would be thrown in as well.

Obviously, IBM doesn’t want to get Microsofted by the EU commission. But depending on the findings, IBM could still wind up with a useful consolation prize if the commission requires Telelogic (or IBM) to spin off either ReqPro or Doors. Forget about the huge market footprint, but add some depth where it’s now missing, in EA. Besides, neither Telelogic’s or Rational’s products are well integrated with the rest of their portfolios.

But there’s another reason why the potential loss of Doors (or ReqPro) wouldn’t be a showstopper. Both tools are aging, rooted in legacy practices that were largely top-down in nature.

Yet, the growth spot in application development today is with lighter weight processes often described under the umbrella of “agile” development. Although executed properly, agile encompasses a mix of long and short-range planning, the emphasis is on short-term user “stories” aimed at extremely short iterations. The upside is that agile methodologies could be highly responsive. But in responding to immediate needs, there’s the danger of losing sight of the big picture. Agile teams could wind up chasing their tails.

That leaves a vacuum — you might have enterprise architects promoting best practices, and you might have enterprise software architects promoting specific software development lifecycle methodologies, but do you have anybody with a “regional” view of the issues that individual development teams are facing?

Consequently, we’d like to see folks like IBM, Borland, Serena, Compuware, MKS and others concentrate on that great underserved “middle” that rationalize “regions” of software teams. It’s a part of the market that’s begging for solutions, as the success of upstarts like Rally Software attest.

For IBM, ReqPro is an obsolete tool, constrained by its ability to digest only certain kinds of Word documents. Maybe IBM was looking to Doors as the ReqPro successor. Why not instead focus on building a new web-based, lightweight tool in tune with the needs of federated development environments that require a slightly bigger picture. IBM/Rational has already pulled that off at least once with Rational Method Composer, the versatile successor to its RUP software development process tool.

Were the EU to cause Doors to slip through IBM’s hands, it could be a blessing in disguise.