06.29.07
Posted in Application Development, BPM, SOA & Web Services at 2:31 am by Tony Baer
As we noted a couple days back, the SOA and BPM crowds both think that services and process management are valuable, but they just can’t agree on how processes should dynamically come together at run time.
At first glance, the arguments are over technology – what we’ll call the WS-folks have put their faith behind BPEL (Business Process Execution Language). It’s an XML-based language that’s an Oasis web service standard that provides the verbs for how services can be dynamically chained together, or “orchestrated” at run time. The WS-folks admire the design simplicity of a declarative orchestration scheme that neatly fits atop the web service stack.
Conversely, the BPM folks believe that their management tools are better equipped to design or dynamically compose those processes. While BPEL might be suited only for machines invoking services off each other, they claim it runs out of gas when it comes to orchestration complex, long-running processes. If you’re going to do serious orchestration, better do it upstream with BPM tools that are far more robust.
At the root of the hubbub is a cultural tug of war between IT and the business that has long predated this particular battle. It goes something like this: IT contends that it is the expert at run time automation, while business analysts claim they have a better handle on the subtleties involved in designing processes. IT complains about the unreasonable requests from business stakeholders who have no idea how their requests will tax the infrastructure. By contrast, the business folks often complain that IT bastardizes their ideas at implementation.
Fast forward to the present, and the WS-folks have proposed a couple new specs to add support of manual tasks, filling a major gap in SOA. The first is an extension of BPEL called BPEL4People that inserts a human task to an orchestration, and the second is a separate spec called WS-HumanTask which provides the semantics for describing the tasks. It’s prompted plenty of discussion, which my colleague Joe McKendrick summarized quite well.
You can imagine the response on the BPM side –- they view these are lowest common denominator approaches that won’t support the way people really work today. “This is where the workflow world was 5 – 7 years ago. In the modern world, people are starting to rely more on run time processes such as ad hoc collaboration,” claimed Rob Risany, vice president of product management for Savvion. Jon Pyke, director of the Workflow Management Coalition (WfMC) is concerned that task implementation conflicts with existing workflow standards, such as XPDL which dates back to the document management era.
But if you take away the polemics, there’s potentially more common ground than may meet the eye.
Yes, the WS- proposals are considerably simpler and won’t represent the richness that you get in the BPM world. But on the other hand, if you apply the 80/20 rule, chances are there are a few simple, commodity tasks that won’t require all the logic of BPM, which might be handled more economically with orchestration at the services, rather BPM level. For instance, a routine request to boost credit limits by 15% for good customers is probably a much simpler decision than one for a customer emerging from bankruptcy.
Admittedly, you might not want to split decision paths for the same process into two different buckets, but that might be doable if you split paths at the line of business or product level. Secondly, by splitting WS-HumanTask into a separate spec from BPEL, it frees the possibility of reusing those commodity tasks in other applications, avoiding the orchestration dilemma altogether.
There’s also another interesting idea coming down the pike that might bridge or bypass the issue – or further entrench the factions. It’s the idea of making process models directly executable.
Modeling provides a way of abstracting the design of a process or a piece of software at a level high enough that business analysts could understand it. It’s been done with UML for architecting software logic and structure, and it’s increasingly being done with BPMN, the business processing counterpart of UML, for business processes. But to get to code, you had to either manually interpret the models, or use a tool that automatically generates code.
But a small Swiss firm, E2E, is now making UML models executable by stealing a trick from Java in adding what’s called ‘byte code.” Lombardi is among the BPM crowd considering a similar idea with BPMN (although BPMN might require some fleshing out with semantics to make the notion doable). And BPEL-J might beef up BPEL with some Java logic that might fill some of its gaps.
Admittedly, these ideas remain for now pie in the sky. But if we can drop the culture wars for a moment, maybe there might be a way to get Venus (the process folks) and Mars (the SOA crowd) to stop sniping at one another.
Permalink
06.26.07
Posted in Application Development, BPM, Enterprise Applications, SOA & Web Services at 7:24 pm by Tony Baer
A truism about SOA is that it’s all about automating the interaction of processes that are already automated. In other words, an SAP or Oracle supply chain application might invoke a weather forecasting service from an external program and automatically adjust promised delivery dates without the need to get a human involved in a process.
But of course, if business only relied on automated processes, then the world would look like something out of a Jetsons cartoon. In actuality, sometimes you can’t fully automate processes such as that delivery date commitment decision. Suppose you needed to make a delivery commitment to the Gulf Coast just before Katrina was to strike? Short of possessing true AI and a crystal clear crystal ball, you’re going to have to call a person into the process where the scenario is so exceptional that it requires human intuition.
This week, IBM, joined by SAP, Oracle, BEA, Adobe, and Active Endpoints formally proposed a pair of specs for submission to Oasis, the web standards body, which would make human workflow a first class citizen in an SOA environment (for now, we’ll call this group the WS-folks). There was little surprise to the announcement, except for the fact that Oracle dropped its former opposition to the scheme.
The new proposal boils down to two specs: an extension of BPEL that adds human workflow as one of its orchestration steps, and a new proposed spec, WS-Human Task, where the actual workflow would be described. Backers claim that, by separating out human tasks, that they can stand alone and be invoked without having to go through a BPEL orchestration. That would enable you to decouple the task from the actual application or user interface, making it that much more reusable.
This all sounds fine and dandy except for one thing -– the classic BPM folks are still not among the signatories. Both sides have been warring back and forth, with many of the established BPM players claiming that BPEL is simply a rudimentary execution language that does not reflect the subtleties of a process workflow. For instance, it doesn’t represent core concepts like “swim lanes” that are used for describing parallel activities. They claim that BPEL in fact complements a couple other standards, including BPMN, a graphical notation for process models, and XPDL, an older specification first developed by the document management and workflow communities.
As for the WS-folks, the claim is that XPDL is not service-oriented, in that it does not separate loose couplings where processes are abstracted from the way they are implemented. And to rub it in, they actively denigrate XPDL as “old fashioned” in its traditional association with paper pushing.
Or as one colleague put it, the BPM folks are from Venus and the WS-folks from Mars.
Our first inkling is that regardless of the merits of the classic BPM crowd, it’s kind of difficult to move forward when you’re facing a solid roadblock guarded by IBM, SAP, Oracle, and BEA. But we’re also disappointed that the WS-folks have not conducted any outreach to the BPM folks. Although they exert strong control in the increasingly strategic middle tier, the process folks come from a different side of the organization than IT –- and if there is no common ground soon, the only result will be stalemate.
Permalink
06.20.07
Posted in Application Development, IT Infrastructure, Security at 1:12 am by Tony Baer
After IBM announced it was buying web application security tool provider Watchfire, we predicted that HP would soon respond. We were right but we goofed on the target. Instead of buying Cenzic, HP chose SPI Dynamics, a provider whose tools fit more squarely with Mercury’s test tools.
But there’s a bit of an irony in all this, which has to do with division of labor. The need to vet software security certainly belongs in the software lifecycle, which HP says is the logic behind the SPI buy. The only hitch is that software developers and QA specialists are not trained in the area. The kinds of software defects that they look for aren’t the ones that could spawn memory leaks, or open vulnerabilities to SQL injection or buffer overflows (which can cause the databases to dump data).
Typically, security is vetted after the fact by its own specialists. If you’re lucky, it’ll happen before the app enters production, but more likely, serious analysis of real or potential holes won’t happen till after there’s an incident. At best, developers don’t see security issues until they’re asked to rework.
So it was interesting to hear SPI Dynamics cofounder Caleb Sina concede that, although his company has unit and system test tools that would fit in nicely with HP/Mercury’s Quality center offerings, only 12% of the customer base uses them (he did claim that half the base is kicking the tires on those tools). The rest use the company’s best known tools: the ones that scan websites in production for existing security holes. Ironically, the company’s strong point is not with the QA folks who are the sweet spot of the HP division in which they would fall.
The other side to the story is that this only adds one piece to HP’s web app security strategy. Significantly, SPI has partnerships with other niche providers that could fill many of the gaps, such as Citadel, which offers automated vulnerability remediation; GuardedNet, which offers a security information management platform; Teros, which conducts discovery; or F5 Networks, which provides an XML load-leveling appliance. In fact, SPI Dynamics has worked jointly with these folks on Application Vulnerability Description Language (AVDL), an XML languages that is now an Oasis standard.
So we’ll venture another prediction: We wouldn’t be surprised if HP buys one or more of SPI Dynamics’ partners in coming months to pick up where SPI leaves off.
Permalink
06.12.07
Posted in Application Development at 11:28 am by Tony Baer
Forgive us for being, literally, an hour and a day late, but IBM’s announced offer to buy Telelogic caught us yesterday on the morning after being forced to Tivo the Sopranos final blank screen (we still haven’t had the time to catch the last episode yet).
But we couldn’t let this one escape without comment. When we first caught the rumors that Telelogic had attracted a buyout offer last week, IBM was among the furthest from our mind. We thought that some of the other ALM (application lifecycle management) vendors with greater gaps in their offerings would have made more logical suitors.
But our miscues were attributable to our getting unnecessarily hung up over the fact that Telelogic’s best known product, the Doors requirement management tool, is IBM/Rational Requisite Pro’s largest rival. Aside from buying raw market share, both tools are at least 10 – 20 years old and have installed bases that are pretty much not likely to migrate anywhere anytime soon.
But we forgot that Telelogic has a jewel that’s been a clear gap for IBM: The System Architect enterprise architecture tool that would make a valuable addition to the Rational portfolio, not to mention a trove of consulting opportunities for IBM Global Services. Telelogic also has several other tools geared toward modeling and testing of real-time systems. So on closer inspection, Telelogic’s markets, which have heavily skewed towards highly complex systems especially in public and telco sectors, largely complement rather than duplicate those of Rational’s, which are about complex enterprise systems in more commercial (e.g., financial services) sectors.
So on second thought, if the offer is accepted, it doesn’t look like a bad deal for IBM. It’s a form of circling of the wagons to solidify the higher end of the requirements, architecture, and modeling market. It’s clearly not about reaching out to the newer forms of development, such as agile, with lighter, simpler tools (Doors and ReqPro are 10 – 20 year old products not known for ease of use).
In that light, we were a bit amused at an incredibly appropriate question from one of our colleagues during the Q&A, on what IBM/Rational is getting itself into by acquiring a company that has made similarly scant progress in integrating its tools.
Danny Sabbah’s answer (he heads IBM’s Rational business unit) was a bit telling, in that it unintentionally shed light on the fact that the cowboy culture in software development is far from dead: “We had some serious discussions with the engineers. They love their tools. They focus a lot more on the maturity of the tools than they do on the integration.”
Permalink
06.06.07
Posted in Application Development, IT Infrastructure, Security at 10:16 pm by Tony Baer
We’ve noted in the past that, when it comes to safeguarding services levels in SOA, there’s been a disconnect – the service level agreements hammered out by business process owners are typically enforced using tools targeted at software developers. There’s been relatively little connect between monitoring service level agreements with SOA tools and dealing with the realities of the data center.
All too often, the same has proven true when it comes to enforcing security of web applications. Software developers, who are supposed to be the intellects or artists of IT, typically know little about IT security. Conversely, security folks, who act as the armed guards or soldiers of the data center in repelling intrusions and hacks, know little of software architecture.
So we were intrigued yesterday when IBM disclosed its intention to buy Watchfire. Until now, you typically didn’t see security checks within design and development phases of the software lifecycle. But IBM’s offer could take what is currently a niche tool used by security specialists once the web app is either live or just about to, and inject the process at several points along the software life cycle. That’s because IBM is the first household name to show an interest in tooling that probes application security soft spots.
Watchfire is part of a small, growing collection of providers who automate the ethical hacking of web applications (some of the others are SpiDynamics and Cenzic). In Watchfire’s case, it stores signatures of known security breaches, much as antivirus tools don’t store the virus, but its signature. (Cenzic takes a different tack, recoding end to end session through the browser.
Watchfire has a fairly impressive, 800-strong customer base, which is concentrated in financial services, healthcare, and government. Nine of the top 10 global banks are Watchfire customers. IBM is proposing to add it to the Rational brand, with targeted integrations to Tivoli.
Although Watchfire has been until now primarily a tool used by security specialists, it has a loose arrangement to exchange data with Fortify, a tool that checks application security vulnerabilities at the code level. Significantly, Fortify is also a Rational partner, and once the Watchfire deal is closed, could become another logical acquisition target for IBM as its tools could have an even better fit with Rational’s testing tools.
What’s interesting is that rival Cenzic is predicting there will be more consolidation in this space. On one side, application life cycle management vendors like Borland, Compuware, and Serena are logical suitors, as security testing should be added to the QA stage of the life cycle.
But we’d like to make a bit of a further reach: How about HP? Like IBM, it also has testing, IT governance, and infrastructure management offerings. Roughly half of Cenzic’s installed base uses HP/Mercury testing tools, and the company has been certified to interface with Mercury Quality Center. Of course, as Mercury dominates the test market, Cenzic’s ties are hardly unique.
But that doesn’t mean that HP/Mercury shouldn’t one-up IBM here. Maybe it’s poker face or maybe HP has other meat on its plate, but Cenzic’s marketing VP Mandeep Khera maintained that both companies have not had any marketing-related discussions since HP completed the Mercury acquisition.
Permalink