03.29.02
Posted in .NET, Application Development, Java, Middleware, SOA & Web Services at 7:34 pm by Tony Baer
Don’t be fooled, the competition between Java and .NET isn’t a horse race or Super Bowl match. For those making the technology buying decisions, the issue is not who’s doing the best spin doctoring, but whether (1) their investments are protected, and (2) their skills are transportable if they should find themselves changing jobs or departments.
So it’s interesting to catch the results of a recent Merrill Lynch study showing software vendors favoring J2EE because it’s more open, and enterprise IT groups preferring .NET because it might support more of the programming language skillsets already in their organizations.
Therefore, the debating points.NET’s “early lead” in web services support vs. Java’s maturity–both miss the mark.
Starting with .NET, yes, it’s at least a year ahead of J2EE when it comes to integrating web services technology. But that’s less important than the headlines imply, because web services technology is rudimentary today. Standards, followed by standards-based products necessary for real mission-critical apps, won’t emerge for at least 12 – 24 months. For now, we must rely on vendor-specific technologies, like Iona’s authentication framework for web services.
So, scratch the web services advantage. Given Microsoft’s critical mass, .NET will become a de facto corporate standard. That’s investment protection. But to get there, it will require the vast throngs of VB developers to unlearn a decade of practice. For now, .NET’s skills portability isn’t rock solid.
As for Java, it’s scored early wins, such as becoming the favored platform for next-generation smart phones. But at present, this market lacks a killer app–unless you count mobile video games. Java’s competitive edge remains J2EE, a framework rich enough for developing a solid third-party software market, but too rich for enterprise IT groups to master. The bottom line is similar to .NET: good investment protection, debatable skills transportability.
Addressing the skills issue, efforts are underway for simplifying J2EE. BEA, stealing pages (and former execs) from Microsoft, is introducing VB-like deployment features to J2EE while adding a framework for encouraging third party “controls.” Exactly the thing that Microsoft did with VBX controls, that helped make VB so essential in the early 90s. Other providers, like Wakesoft, are aggregating best practices to make J2EE developers overcome knowledge gaps.
Even if J2EE gets kinder and gentler, the .NET folks claim there’s still the issue of IDEs (integrated development environments): .NET only has one (Visual Studio) to learn and carry from job to job, while Java has many. Not really true–you can develop .NET apps without VS.NET. More importantly, Java’s problem isn’t the multiple IDEs, but the fact that no two IDEs deploy code to the same appservers the same way. But once the Java Community standardizes that next year, poof, Microsoft’s multiple IDE/skills portability arguments go out the window. Then you’ll have skills portability.
But the real question is that the real competition may not necessarily be Java vs. .NET. Both frameworks claim to complement XML web services. But, suppose, 3 4 years from now, if web services standards usurp many of the .NET and J2EE functions, like messaging, database connectivity, component deployment, security, and so on. They might co- opt the frameworks, and in so doing, maybe offer better answers when it comes to investment protection and skills portability. At that point, they might even claim most of the purchase dollars.
Permalink
03.15.02
Posted in Technology Market Trends at 7:31 pm by Tony Baer
Technology customers like it simple. Most prefer umbrella solutions from a single vendor over trusting their luck to integrating so-called “best of breed” solutions.
One-stop shopping works, sort of. That was the core revelation prompting Lou Gerstner to halt IBM’s break-up plans when he took over in 1993. One-stop shopping also propelled SAP to the top of the enterprise applications market over best-of-breed rivals like Oracle.
But you can’t dismiss the “sort of” factor. Since the software industry emerged 30 years ago, it has been virtually impossible to rely on just one vendor for everything.
For vendors, the challenge is accepting their limits. IBM confronted the matter successfully when it realized that customers looked to them to sell the box and make it work. Out went IBM’s printer, network, and application software businesses. In came systems integration and aggressive third-party solution provider charm offensives (it didn’t hurt that Larry Ellison’s “soft touch” made IBM a sweeter alternative for many).
Not all vendors handle the “sort of” gracefully. When SAP realized it couldn’t easily master supply chain planning and B2B collaborative commerce, it attempted alliances with i2 and Commerce One before realizing that technology partnering clashed with its core architecture and internal culture. Chastened, when it came to adding Java, SAP did its own appserver rather than rely on the usual suspects, WebLogic or WebSphere.
While IBM and SAP built their way to one-stop status, can vendors buy their way there?
This week, Ascential Software, which offers data transformation tools, acquired Vality, a maker of data quality tools to fill out its product line. Enterprises consolidating their data for business intelligence or application integration must scrub their data first, a logical step for integrating with the transformation process. Ascential’s move validates a strategy already taken by rivals like Trillium Software, whose data cleansing product is now embedded by Oracle and Siebel.
HP’s Compaq deal, which comes to shareholder vote next week, was also premised on one-stop shopping. But if the deal goes through (we expect it will, narrowly, because opponents haven’t voiced a compelling alternative), customers buying HP servers, HP printers, and Compaq storage are still likely to go outside for high-end integration services because HP/Compaq still won’t have them.
Permalink
03.11.02
Posted in Application Development, Data Management at 7:31 pm by Tony Baer
Recently, we attended a local software industry gathering and heard some rather unusual advice from, of all people, the mayor. In this case, hizzoner was New York’s Michael Bloomberg, who came to office knowing more about the business of technology than that of picking up garbage (of course, we’re also hoping he’ll soon master the latter as well).
Bloomberg recounted a tale of project scope creep from his former company that rang all too familiar to us. In this case, it was a system for printing out visitor security badges that proved so complex that people entering the building often ended up waiting in line just to get in. The culprit? Out of nearly a dozen fields that were entered from scratch every time, only one (the visitor’s name) was unique.
Whether it’s enterprise systems or commercial software, the results often end up losing sight of the original purpose. We try making so many stakeholders happy that we end up pleasing virtually no one.
And we end up with systems that are unnecessarily complex. For instance, when was the last time you phoned an (800) customer service line, entered your account number, then had to repeat the same info when the call center rep finally came on the line? Or the last time you changed a Windows preference and were faced with the buttons “Apply” and “OK?”
All right, maybe occasionally, there are good reasons for having separate “Apply” and “OK” buttons. For the 20% who really need that extra choice, segregate them onto an Advanced User set of menus. Otherwise, leave the rest of us alone, because we’ll probably end up clicking the wrong button anyway.
That message was reinforced later at the conference when another city agency–the Board of Health–discussed its highly popular web site covering restaurant health code violations. Targeted at patrons who want to know if their restaurant is clean, somebody in the audience asked if the site also had a feature that sorted restaurants based on inspection results. Fortunately, the agency opted for common sense. If you want aggregated info, it’s also available–separately. Otherwise, the 80% of us who are just going out to eat won’t be burdened with navigating yet another confusing feature that we probably won’t use anyhow.
Permalink
03.04.02
Posted in Data Management at 7:26 pm by Tony Baer
No matter how much you spend, enterprise systems remain far too fragile. Just ask Hersheys. A couple years back, they tried going live with SAP just before Halloween, taking huge sales hits when the new system failed to keep stores stocked during what should have been the company’s peak season.
Sure, no systems project is complete without testing, but most teams are preoccupied with coding bugs, system interfaces, and loads. All too often, however, the problem is data. Recall the case of the Mars Lander that crashed because somebody forgot to specify that the measurements were metric.
Data quality is too frequently taken for granted. We were reminded of the problem when we recently sat down with the global technology group of a major financial services institution. In 1998, the organization began building an enterprise data services utility, using SeeBeyond’s eGate as the application integration broker. The driver was the need for introducing new products that addressed changing markets and new competition, plus a mandate for eliminating redundancies.
The sleeper cost turned out to be data quality: ensuring that data was properly mapped and transformed from source to target. Data quality often soaked up more effort than architecture and development. And they found that it was far cheaper to fix problems up front rather than after the fact.
OK, nothing startling so far, except that most other companies that we’ve studied have largely paid lip service to this realization. The major hurdle? Prying domain specialists away from their business units long enough to vouch for the quality, not just of the data transformations, but the reliability or context of the sources in the first place. In this case, top management was sold on the necessity for getting the right eyes on the data early on (it didn’t hurt that the company already had an ingrained Six Sigma mentality).
What’s interesting is how the technology group justified costs: not just the operational savings from consolidating redundant databases, but in the work that people performed. For each project, poll users and technology staff to log their activity over a few days. Get data from about 60 – 70 people, and you can quickly deduce where people are spinning wheels.
However, the other part of the equation requires spreading the word. The group conceded that for now they were too busy to internally market their successes.
Permalink