Philip Brittan's Blog

October 2003 Archives

Confusion between grid and utility computing

I just published an article on CNet News.com titled The new IT confusion which attempt to disentangle grid and utility computing concepts in less than 700 words.

Open Standards Definitions

What do we mean by open standards anyhow?

My last entry evoked a certain amount of name-calling in the arena of open standards. Today I'd like to explore just what "Open Standards" might mean. This will seem very simplistic to many of you, but I hope it’s helpful to sort things out in a simplistic way.

I’d like to start with some definitions:

Open - Open for third parties to support and create products to (opposite is Closed)

Proprietary - Legally owned by a company, individual, or private group (opposite is Public Domain)

Community - Administered by a group, not just a single company (opposite is Sole-Stewardship)

One minor note that some people seem to miss is that open and proprietary are not opposites. A standard may be both open and proprietary at the same time. A "closed standard" is an oxymoron. You can have "closed systems" which do not allow third-party integration, but you cannot have a meaningful closed standard.

A standard that is not legally owned by any company or person is said to be in the public domain. Examples of this include: HTML, SNMP, etc.

A proprietary standard is owned by a single company and may be administered solely by that company, as Windows and Solaris APIs are, or it may be administered by a community, as Java is. Some communities are have their own bodies for collaboration (JCP), and some rely on standards bodies, such as the W3C, OASIS, ECMA, and so on, to handle community collaboration and be the official keepers of the spec.

An "open source" standard is one in which the source code as well as the APIs are included in the specification of the standard, meaning that third-parties can extend the product at the source code level, not solely by working through an API. Open source is considered by many to be the purest form of open standard. But again, that doesn't mean it can’t be proprietary. Linux, a favorite open source example, is not in the public domain. The Linux GPL license does not require a monetary fee, but it does make other requirements which it imposes with a copyright. For instance, all source code for modifications made to Linux must also be freely available. Linus Torvalds explicitly owns the registered trademark "Linux". FreeBSD, as a counter-example, is also free of charge and open source, but does not impose the requirement of sharing enhancements with anyone else.

Whether software costs money, and what it costs, are economic/strategic decisions made by the owners of the software / standard. 0 is a price, just like 5 or 745. 0 just carries more psychological weight than other numbers. The underlying license and source code for Linux are free, but distributions of Linux do not have to be free. Companies can charge whatever they want for them.

The relative advantages of these are not moral. They are rooted in various benefits they give to the owners and users of the standards. One of the benefits of using open community standards is vendor-independence: multiple vendors can create competing products that implement the same standard, thus giving customers more choices. Cost, ability to extend, and ability to debug are common reasons that customers choose open source software, but keep in mind that many “closed-source” solutions do provide source code to their paying customers for debugging purposes. One might say that a sole-stewardship standard carries the risk to users that the single company administering the standard can potentially change that standard to suit only its own needs, thus causing damage to third-party users of the standard. Conversely, since a community-administered standard must reflect the interests of a group of different constituencies, it is unlikely to change capriciously or quickly. This distinction is the heart of the Microsoft / Java war of words.

The flip side of that is, of course, that since community standards are slow to change, single-stewardship standards can be much more nimble and capture the changing realities of the marketplace in a more time-sensitive way. When a standard is too slow to change, then vendors supporting the standard are sorely tempted to add one-off extensions for functionality that is not yet standardized, which erodes the value of the standard.

Customers make choices about their adherence to standards based on what they need to achieve and the risks they perceive.

Sun: Threatened by Standards?

Can 'standards' and 'standardization' be two unrelated concepts?

There was an article in yesterday’s Wall Street Journal, Cloud Over Sun Microsystems: Plummeting Computer Prices, which dissects Sun’s current financial and strategic challenges.

One of the interesting claims in the article is that "Scott McNealy, Sun's chief executive for the past 19 years, long resisted the standardization trend sweeping across the tech industry." The articles asserts that "The wager paid off, making Sun the dominant provider of the server computers that power Internet sites and corporate computing. But now the company is paying a big price for bucking the tech mainstream -- and scrambling to keep customers and stay afloat."

It's ironic to see Sun portrayed as a company that has consciously flown in the face of standardization, when in practice Sun champions open standards precisely as a way to differentiate itself from Microsoft.

So, which company does this article say represents mainstream standardization? Microsoft. "Sun appears to be the latest casualty of the rising tide of tech standardization, led by Intel and Microsoft. Many companies in the history of high-tech -- Digital Equipment Corp. and Apple Computer Inc., among others -- believed they could resist standard designs and thus ultimately charge a premium for their products. In the end, a lot of these companies were either acquired or hang on in the industry as smaller players."

RAD Tool Let-down

Rapid application development tools let you put together a great-looking mock-up of your app in no time, but often are of little use for the production version of your system. Visual GUI builders and data-aware controls are two such culprits.

In yesterday’s post, I mentioned that all too often tools that help developers put out a really quick version of their application are frustrating to use when trying to create a sophisticated production version of the same application. This forces the developer to back-track and gives rise to the concept of the "throw-away" prototype, meaning that any effort put into the prototype has to be chalked up solely for the purpose of getting early feed-back but has to be tossed when it comes time to build the "real" system.

Today I'd like to illustrate what I mean with two very common examples of this phenomenon: visual GUI builders and data-aware controls. I have a love-hate relationship with them both.

By visual GUI builders, I mean WYSIWYG editors for laying out components in an application window. It's great to be able to sit down at a blank project and just start grabbing controls and laying them out on the screen, one after the other, changing positions if you change your mind about the layout, setting properties and seeing those properties immediately reflected in the representation of the window you are building. It is very satisfying to be able to put together a window so quickly, and it is much easier than instantiating all those widgets and setting their properties in code.

However, building the GUI through code does have some big advantages, and, personally, I almost never use a GUI builder for a production application. Here’s why. GUI builders give developers a component-by-component interface onto the window and treat properties as literal values. So, if I want to set the background color of a bunch of my components to red, I have to go and set the background color property of each of those components manually in the GUI builder. And, if I want to change the background color of all those components to something else, say orange, then I have to go through and change them all manually again. The GUI builder gives me a really quick way to put the window together but ends up with a pretty brittle design that requires lots of manual labor to make subsequent changes.

If, on the other hand, I set the background color of those properties in code, I can simply make a variable that represents the background color, set the color properties of those components to the variable, and then set the variable to red. It takes more time to set this up, and it’s a non-visual development process, but my design is now more flexible and I can change the background color of all those components by simply resetting the value of the variable to orange. This is exactly the benefit that Web apps get from CSS, and Joshua Marinacci posted a great article yesterday, CSS and Swing, about how you can achieve similar results to CSS in a Swing app by making a properties file that is read in at run-time. The problem, however, is that this takes you out of the GUI builder and into the code. I want a GUI builder that can handle this for me. Fortunately, many GUI builders generate source code which allows you to take a hybrid approach: use the GUI builder to generate basic component instantiations and properties, and then modify the generated code by hand from there. Still, I wish I didn't have to switch modes -- and that approach is generally a one-way street.

This problem can be more much sophisticated than just setting properties on components. I find that I often want to create bunches of components programmatically, with a loop, reading component specs from a database or config file or based on some algorithm. At that point, even a CSS mechanism can’t help me. I long for a GUL builder that can give me a visual environment to see what my window looks like at all times but to be able to create and manipulate components algorithmically as easily as I can create and manipulate them visually.

I feel similarly about data-aware controls. Manually wiring up GUI controls to database values is admittedly a pain, so data-aware controls are also a great boon in helping developers get a basic version of their app up and running quickly. However, I have rarely written a sophisticated data-driven app where I didn’t need to massage data while reading or writing from/to the database. Hard-wiring controls to the database tends to be pretty brittle. So, once again, for production-quality apps, I have to abandon the data-aware controls for a manual, code-intensive process that gives me the flexibility I need.

I would sorely love to have versions of these tools that can support the flexibility I need for production systems as well as the RAD capabilities I value for prototypes without having to backtrack and change gears along the way. Maybe such things exist, but I haven’t seen them.

ROI of UI Technology

I recently wrote a paper for The SAP Developer Network on user interface technology in the enterprise. I'd like to pull out one small section of that paper for further discussion here:

There are three main factors that affect the ROI of any UI technology: ease of use of the application, ease of deployment and on-going maintenance, and ease of initial development. Based on the total cost associated with each of those factors, they should be assigned the following order of priority:

1. Ease of Use: The usability of an application affects the bottom line of a company every day and that effect is multiplied by the number of users the application has.
   
   
2. Ease of Deployment and Maintenance: The costs associated with the deployment and maintenance of applications affects a company’s bottom line on an occasional but usually repeated and perhaps regular basis. These costs are incurred whenever an application needs to be deployed to new users, upgraded with new features, and have bugs fixed.
   
   
3. Ease of Initial Development: The costs associated with the initial development of a new application affect the bottom line of a company only once per app, and they scale with the number of developers involved, which for the vast majority of applications is far less than the number of users of the application.

The temptations of the immediate gratification of fast initial development can be so strong, in fact, that some UI development tools focus entirely on the ability to put together a good-looking but simple application really quickly. This is valuable for getting early user feedback. However, many of these rapid development systems are ironically difficult and time-consuming for creating sophisticated applications, because of an inherent lack of flexibility. A good UI technology will enable rapid prototyping but won’t do so at the expense of production version development.

Therefore it is imperative that companies apply sufficient discipline in their technology selection and implementation to ensure that an economically correct ordering of priorities is followed.

Embrace, Extend, Extinguish on the browser?

Is Microsoft ready to move onto the 'extinguish' phase with the Web browser?

Microsoft is renowned for its "embrace, extend, extingish" strategy which involves enthusiastically embracing and championing a new standard, as a way to become the market leader in that standard, then extending that standard with proprietary technology that lets Microsoft lock in customers and lock out the competition, and lastly to let the standard die on the vine or be replaced by an entirely Microsoft-proprietary alternative. Microsoft has famously done this with Java, which in its final stage has now been replaced by C# in the Microsoft view of the world.

In an earlier post, I suggested that Microsoft makes money from Windows desktops, not browsers, and that a powerful browser platform is in fact a threat against the Microsoft-preferred fat-client model which is more firmly symbiotic with the Windows desktop.

It seems there is growing evidence that Microsoft may in fact performing a slow embrace, extend, extinguish on the Web browser.

Embrace: When Netscape introduced the first commercial browser, along with the promise that the Web would make the desktop environment irrelevant, Microsoft quickly jumped to develop Internet Explorer and used a wide array of competitive tactics to ensure that IE grabbed overwhelming share of the market and eventually pushed Netscape out of business.

Extend: For a while, Internet Explorer supported all the W3C standards for Web pages, but also added its own additional capabilities that let Web designers do things that the official standards did not support. This seemed like a helpful feature for developers, but had the inevitable effect of locking developers in to the IE platform. I recently met with an ISV that has a Web-based application that depends on the IE 6 extensions. This meant that the ISV required all their customers to access their application through IE only. But now, since a significant segment of this ISV's customers use Apple Macs, and since Microsoft no longer supports IE 6 on the Mac, the ISV is left high and dry.

Extinguish? I read an article this morning titled "Has Microsoft Forsaken IE?" in which developers complain that Microsoft is falling behind in supporting new Web standards.

"While it is true that our implementation is not fully, 100 percent W3C-compliant, our development investments are driven by our customer requirements and not necessarily by standards," said Greg Sullivan, a lead product manager with the Windows client group.

When it was pointed out that the most vocal critics of IE's CSS support are Web developers and authoring tool makers, rather than standards bodies, Sullivan said those critics were comparatively few.

This work is licensed under a Creative Commons License.