Level: Intermediate Dan McCreary (dan@danmccreary.com), Metadata Strategy Consultant, Dan McCreary & Associates
11 Dec 2007
This article examines several methods of calculating the Return on Investment (ROI) of
adopting enterprise-wide XForms standards. Explore ROI analysis from several
different viewpoints, including the standards perspective and issues around vendor
lock-in avoidance strategies. Learn about three ROI models for an enterprise XForms
migration: The use of vendor knowledge to convert standard forms to a rich
Web-client-based XForms application; an investment and savings calculation over a
three-year period; and how XForms can form a synergistic relationship with XML-centric technologies such as Service Oriented Architecture (SOA) Business Process Management (BPM). This article concludes with a discussion on how to overcome common objections to an XForms initiative.
Background
Because this article discusses the Return on Investment (ROI) XForms
standards, familiarity with XML is and other W3C standards is useful, as well as a
basic background in cost accounting. This article includes a
Microsoft® Excel template for doing ROI analysis. Each tab in the spreadsheet uses a different model for calculating total ROI.
Audience
Use this article as a blueprint for any organization that is
considering the adoption of XForms standards either across the enterprise or
as a business area's point solution. While many articles focus on XForms
features, this article attempts to look objectively at how XForms
technologies can benefit an organization.
Frequently, new technology standards are promoted from the "bottom up" when
software developers and architects try a new technology and develop a gut-level feeling that the organization would benefit from adopting the technology. This article may help those developers articulate the strategic nature of XForms to high-level decision makers concerned with documenting solid financial return on investment from technology decisions.
Occasionally a high-level executive will ask an enterprise architecture
team to look into the cost effectiveness of a specific technology. When
this happens, it is usually because their peers at similar organizations
have already proven the ROI of a technology. In this case, accessing a
network of case studies with documented ROI is usually an excellent option.
Unfortunately, with any new technology, industry-specific case studies can
be hard to find. I hope that this article can serve as a resource in these instances.
Standards: A proven track record of high ROI
The late 1980's saw an explosion of personal computers in the workplace and
organizations found a need to connect these computers together into local-area-networks
or LANs. Early LANs were recognized as useful; unfortunately, their initial benefits
barely exceeded the costs. The reason? Lack of standards. There were at least
a dozen LAN standards from companies such as IBM®, Novell, Digital Equipment
Corporation, and Xerox. Each company sold very expensive yet completely incompatible
systems. What made LANs cost effective was the gradual adoption of standards such as
Ethernet and TCP/IP protocols. Eventually, Ethernet hardware became built into computers and creating a LAN was just a matter of purchasing inexpensive hubs. The ROI became clear.
We see the same problem today with Web development. We must keep in mind that HTML was
not originally designed for processing of forms; it was designed as a way to link
documents. Before XForms, there were simply no standards for user interaction other than highly simplified field entry tags tacked on to the HTML standard. There were no standards for rich user interfaces and asynchronous interaction.
Most Chief Information Officers (CIOs) and Chief Financial Officers (CFOs) have a good
understanding of the costs of trying to support multiple standards. Employing three
teams of database performance gurus is usually more expensive than a single team, resulting in the frequent pressure to use a common infrastructure. When you propose the adoption of the XForms standard, your success may rest on your ability to convince the corporate decision makers that the adoption of a single standard for Web applications makes sense.
XForms and Metcalfe's Law
Another factor to consider is how the value of a standard increases dramatically as the
standard is adopted by others. This is best stated by Metcalfe's Law: The value of a
network standard grows exponentially with the number of nodes connected to it.
Metcalfe's Law was named for Bob Metcalfe, the inventor of the Ethernet standard. He
noted that as more users adopted a standard the value of that standard to an
organization increased dramatically. For example, if only one organization had a fax
machine, it would not prove very useful. However, if all of an organization's customers
and vendors had fax machines, purchase orders could be sent to anyone who had a fax and its value increases.
Unlike Ethernet or a fax machine, XForms is not a formal communication protocol between
any two nodes on a network. It is a communication standard for a user interface
interaction with its own ecosystem and can become the hub of communication in a software
development environment. For example, XForms can be used in form designer applications, forms deployment servers, business rule servers, browsers or browser plug-ins, Web debuggers, and other development tools. Metadata registries can store XForms labels in multiple languages for any form. So sometimes looking at XForms as a point solution to a specific problem does not take into account the network effects of new standards. You will usually find much stronger ROI as these standards spread to multiple business units.
Collection of techniques vs.
international standards
When people are considering using techniques like Ajax (Asynchronous JavaScript and
XML), what they are doing is cobbling together a set of techniques designed to take
advantage of a single function (the XMLHttpRequest function). There are now hundreds of
books, articles, and publications devoted to meeting user demand for updating Web page
elements without reloading a page. However, each publication has different ways of
slicing and dicing the problem. Two Ajax programs may only share the single
XMLHttpRequest function call. Some do not even use XML in data exchanges. There are no
widely used Ajax standards for putting a model-view-controller in the browser or using a
dependency graph to track changes. Adopting Ajax may give users a better experience,
but may, in fact, dramatically increase your costs of developing and maintaining Web
applications.
ROI analysis is critical
Analysts suggest that only 20% of proposals for new technology without an ROI
analysis are adopted when first proposed. However, when accompanied by an ROI analysis,
the adoption rate increases to over 60%. With that in mind, it is best to do your ROI
homework before you head out to present your enterprise technology standards. If you
have never done ROI analysis before, you may want to find others in your organization to
assist you, and your friends in accounting might be a good place to start.
ROI strategies: Delivering the right
message to the right audience
There are many reasons why organizations choose to adopt new technologies. Research dating back to the 1950's shows that the decision process of the corn farmers in Iowa to adopt a new corn hybrid seeds is similar to that of most technology adoption. Groups that adopt new technologies fall into five categories:
Innovators (about 2% of the population) or technology enthusiasts, will use a technology based on its features and do not require financial analyses before adopting a new technology.
Early Adopters (about 13% of the population) or visionaries wait until Innovators have shown a technology has merits but still are not driven by financial analysis.
Early Majority (about 33% of the population) or pragmatists need to see clear ROI analysis or ROI-based testimonials from others in a similar industry.
Late Majority (about 33% of the population) needs concrete objective ROI analysis supported by multiple sources.
Laggards (the remaining 16%) or skeptics will only use advanced technology if they have no other choice. Often new technology must be embedded in a total solution for a laggard to adopt a new technology.
What emerges is the notion that all but a small minority want a solid ROI analysis
before they use new technologies. In fact, the laggards sometimes have the best
insights about the reasons their organizations would not adopt a new standard. If you can convince the laggards in your organization that XForms will give you a positive ROI, the others may quickly fall in line.
What this does say is that there are at least three different possible strategies to take.
If you have the luxury of working in an organization where innovation is the rule, you can sell XForms based on its technical merits and allow the innovators and early adopters to map the features of XForms to organization advantages and benefits. You need to be prepared to understand the overall design as well as the intricacies of XForms and how each feature works.
Alternatively, if you are appealing to early adopters and early majority users, you
will need to focus on the ROI of the XForms standard itself and carefully map the
features of XForms into specific advantages and benefits within your organization.
Explaining how XForms is superior to other specific options and showing how third-party
non-XForms vendors use specific techniques to lock you into their tools will also be
required. The good news is others have been down this road before you and will most
likely be willing to share their side-by-side analysis (see the References section for additional resources).
Selling to late majority and laggards may require you to bundle XForms into a larger
package and sell that package as an organizational solution; for example, suggesting a complete library of XForms for the insurance industry based around the ACORD standard or the health care industry using standards such as HL7.
Your solution may require you to collaborate with vendors that embed XForms directly in
their products. Be aware, however, that some solution providers claim to support the
XForms standards when in fact they are using the same lock-in strategies that are common in many Web application development frameworks.
Getting these XForms applications to run under multiple forms players is an obvious
test of portability. Any files with non-W3C namespaces in their headers should be a red flag. One way to qualify vendors is to inquire as to the role their organization plays on the XForms standards committee. Careful reference checking and a site visit to other organizations that are actually using and customizing the forms with XForms development tools is an obvious way to vet the vendors.
A final word of caution. Many organizations do in fact state that "innovation" is part
of their company mission and values. The challenge is that the high-level decision
makers do not have the technical knowledge to understand the features of XForms. If the
CIO invites you to "come talk to me about XForms" and you get that
deer-in-the-headlights glazed-over look when you try to explain MVC architectures,
change your strategy quickly! Listen carefully for their "hot words." If they use
phrases like "increase quality," "control development budgets," and "cut spending," then
mirror their vocabulary. Help them develop the mental models they need to understand how XForms can meet their organizational objectives.
Calculating ROI: Warning: Your mileage
may vary
Calculating the return on investment for any new technology is an inherently variable
process. Rarely do all organizations have uniform structure, staff skills, challenges,
and opportunities to recapture IT investment dollars. This article cannot address all
of the variables, but it attempts to look for common patterns and answer the question: "Why should our organization adopt XForms standards?"
Information technology solutions impact varies dramatically based on the many considerations. Here are three that are critical:
- What are the main business challenges in your organization?
- How do your current IT resources (people, process, technology, standards, politics, and vision) align with these challenges?
- How can a technology like XForms allow you get a greater return on investment within your IT unit?
Some basic terminology
Before we begin, it is important to make sure you share a common understanding of the following terms with your audience. While technical in nature, it will be important to present these terms and concepts in a way to facilitate understanding regardless of the technological know-how. Find and select an appropriate metaphor to explain key concepts and keep the list of terms short – technical jargon is a sure-fire way to lose an audience.
Declarative programming is a way of specifying the requirements of a system.
Declarative programming states what a system should do, not how it should
do it. The XForms standard is a declarative system because it describes the
requirements of a form using just 21 functional elements; however, the standard does
not specify how these elements are mapped to any specific display device like a
Web browser or a mobile phone. XForms does not specify the computer language to be
used to render a form, what Web browser to use, or what operating system the forms should run on. XForms has many advantages because it does not dictate the implementation details of how forms are rendered on a specific device.
One of the ways to describe this is the metaphor of giving a person general directions to an airport. "Go north-east for 10 miles and look for planes." This is compared to a procedural way of giving 50 discrete turn-left-on, turn-right-on steps.
An XML Schema is a "blueprint" or "data specification" for form data used by
many development systems. XForms re-uses XML Schema data types and XForms applications can be automatically generated from an XML Schema. Many industries supply XML Schemas for standard forms, such as ACORD for the insurance industry. When XML Schemas are linked to the enterprise metadata registry and centralized layout standards (CSS), these systems can create a large library of professional-looking, precise forms that conform to industry standards. If you are also using industry standards, the shared meaning or semantics of each data element will simplify the exchange between systems.
A Model-View-Controller (MVC) architecture is a way of separating data entered
in a form from its actual screen representation. MVC is a fundamental design pattern that separates concerns and makes systems easier to build, manage, debug, and maintain. In the same way buildings have excellent designs, XForms also leverages excellent design based on an MVC architecture.
The Form Dependency Graph is a network of all controls on a display and how
they relate to each other. If form controls depend on each other, that dependency is
automatically represented by the dependency graph. For example, if you have a purchase order total, the total can be recalculated inside the client device without sending data to and from the server. This makes developing complex forms much easier and cuts down on network traffic to and from your application server.
The primary reasons to adopt XForms:
Great application architecture
If you are a technical person who has created complex interactive Web applications
with XForms, I will not tell you anything you do not already know. You know that
building applications with both Ajax and Web 2.0 technologies is inferior to building
them using XForms technology. Unfortunately, most executives do not have the same level of appreciation for great architecture and while they may perceive your commitment and recognize your exceptional record of accomplishment, you will still have to "show them the money."
How you demonstrate to management the benefits of XForms technology will depend on your ability to identify the organizational "pain points" and map them to specific XForms features.
There are several signs that XForms will be a good fit for you or your organizations.
Here are just a few you may want to consider:
- You are spending a lot of time and money creating complex applications that would
benefit from Web deployment.
- You cannot seem to develop interactive Web applications within the timeframe or budgets you need.
- You either have or are starting to invest in describing your data in terms of XML
documents (XML Schemas, XML transforms, etc.).
- You want your business units to be able build their own Web applications using metadata shopping cart tools and graphical schema design tools.
- Your IT organization feels excessively burdened by having to write and maintain
many large in-house and third-party JavaScript programs.
- You want to build rich Web applications but do not want to invest in learning JavaScript.
- You have many XML configuration files that you want non-technical users to change without corrupting them.
- You have or are considering investment in native XML data stores and you want systems that can use them.
- You are rolling out Web forms applications but do not want to pay excessive license
fees to proprietary Web form creation tools.
- You don't want to be locked into a vendor-proprietary set of tools for building Web applications.
- Your application architecture team loves well-thought-out open architectures such as client-side Model-View-Controller and dependency graphs.
- Your users just want a great Web experience and are tired of constantly reloading
entire Web pages for simple data validation checking.
- Your data quality team wants to put more character-by-character data validation in
your Web applications.
- You want your forms to execute consistent business rules directly in your Web form and expressed in an industry standards such as XPath.
- You want to use existing industry-specific XML standards (like ACORD) that already have XML schemas defined for standard documents.
- You have many forms where the controls (such as selection lists) need to pull
information from dynamic sources (such as Web services).
- You want to be able to automatically generate Web forms directly from XML Schemas.
- Your Web forms are very slow to load and your support team suggests combining many
small round-trips to the Web into a single submit with more data validation in the browser.
Alternatively, there are also signs that XForms is not the right solution for your
organization:
-
You don't have a real user interaction-centric problem. For example, if you are
tasked with indexing large amounts of Web content like Google. This really is not a Web interaction model and you may not be able to reduce the cost of your organization's operation.
-
You are already too locked in to a vendor-specific standard. You are already
locked into a current vendor's proprietary solution and this solution already has
excellent features, such as top-notch in-browser MVC architecture and advanced browser dependency graphs.
The nice thing about the list above is that is really is a pretty short list. You can
usually quickly tell if an organization will not benefit from XForms.
BAF not FAB
Once used, you can quickly become overwhelmed by the rich features of XForms.
Yet how can we map these extensive features into concrete savings? One technique
commonly used is to never assume the listener (or reader) will automatically determine
the Benefits of a new technology when you explain its Features.
BAF is an acronym for Benefits, Advantage, and Features. FAB reverses
the order and should not be used unless you have a very technical audience. When presenting your ROI, begin with the Benefits, follow with Advantages, and conclude by demonstrating how the Features will create those advantages.
Benefit statements are variations of two things: saving time and saving money.
Advantages contain comparison words (faster, better, greater) with other alternatives. Features are facts. For example, here are the benefits, advantages, and features for model-view-controller:
Benefit: Save development time in building and maintaining Web applications
Advantage: Unlike storing data in many JavaScript variables, developers quickly see form data inside a model
Feature: Model-View-Controller separates form data from presentations
Your organization may derive many different advantages and benefits from a feature. It is up to you to show how XForms features create bottom-line benefits for your organization.
Linking an XForms ROI to the
organization mission and strategy
When discussing XForms benefits, you should first review your organization's mission
and strategy documents, as well as the technology department's objectives and begin the
conversation by linking your proposal to these documents. Look for keywords like
flexibility and quality and check to see if your organization has already developed metrics for these areas. Can they state a dollar cost for a data quality? If a complex form has incorrect data, how does that impact the overall data quality of a project?
Three analytical ROI models
The spreadsheet associated with this article has three ROI models. Each tab in the spreadsheet is an independent model and is meant to be a template to start your ROI analysis.
ROI method 1: Vendor-driven forms comparison using Request for Purchase
The first model of XForms analysis is to leverage the experience of the marketplace. Let your vendors do the work and ask for a fixed cost in a legally binding quote. Your cost of doing this analysis is limited to gathering information in a detailed request for purchase (RFP) and evaluating the total costs in the responses.
Assume you have several existing paper forms, mainframe forms, old Windows®
forms, or older HTML forms that you want to convert to use a high-quality, user-centric
interaction model. These forms should have some standard CRUD (Create, Read, Update,
and Delete) functionality and some simple business logic (for example, the value of some fields depends on other fields). You create a list of all these forms and all their business rules, and send the requirements to several vendors.
One quote would require the use of the XForms and another would use some other
non-standard technology. The quote should include the cost of developing the forms and
the expected cost of ongoing maintenance. In this scenario, a full software development
lifecycle cost analysis is not required, but you should keep an eye on the
capability-maturity models (CMM) of the process if you can. Make sure you are comparing
apples to apples.
It may be wise to suggest that vendors demonstrate how they would create small,
medium, and large forms with their technology. When you bring the vendors in to do a
demonstration, make sure that non-developers can change the look-and-feel of the forms
using a standard such as CSS, add new fields, or change a simple business rule.
Additionally, determine how making a specific optional field into a required field or
adding a new value to a selection list can be accomplished. This may require some
training, but having a graphical tool or simple forms to make changes is usually easier
than having to edit Java™ or Visual Basic code.
You may also suggest that one of the evaluation criteria be how well do the forms
standards work with other standards? For example, if you have a selection list on your
form that needs to pull values real-time from a Web service, is there a simple way to
do this? (Hint -- This is just a few lines using the XForms.)
Although this may sound like a straightforward way to calculate the ROI of XForms, it
presents two challenges. First, gathering all the data requirements from the
enterprise forms to provide to a vendor can be a challenge. Second, since XForms is a new technology, XForms-centric vendors will not be as mature as vendor solutions that have been in development for many years.
When Ethernet interfaces for computers first hit the market, they often cost thousand
of dollars each. This is not because the standard was bad, it was because manufactures
did not yet have a high enough demand and time to mass-produce the components inexpensively. However, organizations that did invest in early standards did get substantial ROI on these investments and reaped even faster ROI as the standards became prevalent. As XForms tools and vendors emerge, these comparisons will be easier to find.
ROI method #2: Measuring quantitative XForms
benefits
In the second ROI method, we attempt to put ballpark numbers around many of the costs and savings of an XForms project to derive a total three-year ROI analysis. The second tab on the spreadsheet associated with this article allows you to enter in both short-term non-recurring costs and annual costs as well as expected annual savings in several areas. The initial first-year costs include items such as:
- Hardware costs
- Software costs
- Training costs
Once the XForms infrastructure has been put into place, you will then see annual savings in the following categories:
- Reduced development costs (fewer developer hours per form)
- Savings from better utilization of non-programmers in maintaining and updating
XForms (using lower-cost resources)
- Savings from better user experience entering and updating data (faster and more accurate data entry times)
- Savings from better data quality (lower cost to fix bad data)
- Savings from more accurate reporting (higher confidence in report accuracy)
The categories described above can be associated to numerical counts (hours,
occurrences) with dollar values assigned to each count. To the amount calculated above
an additional load for items, such as developers and differentials between developers
and others on the team who take on tasks that were traditionally only done by
developers, should be added to derive the cost by component. You will find the
simplicity of XForms will allow junior staff members to take on roles and assignments
previously handled by more experienced staff, resulting in lower costs. You may also
need to do some research to find a fully loaded or fully burdened hourly costs that
includes items such as vacation time, sick time, supervision costs, rent, and more.
The categories listed above are not all-inclusive. It may also be applicable to
include the soft-benefit categories such as savings due to faster time-to-market and
faster turnaround of specific form data, which can be difficult to measure in dollars
and cents. If you are building new Web applications, you may be the first entrant in a
new market creating a dominant market-share forcing competitors to compete on price to diminish your market dominance. It is often said that the first bite is the sweetest and the first market entrant is the most profitable.
Using this method assumes that conversion of your regular paper and a Web form to use XForms is a stand-alone IT strategy and has no relationships with other IT projects. In practice, this is rarely the case. The final model will examine these interactions.
ROI method #3: XForms in the SOA/BPM ecosystem
In our last RIO model, we look at the synergistic effects of an XForms standard and
other related IT strategies. Service Oriented Architecture (SOA) and Business Process
Management (BPM) are at the heart of a large percentage of modern IT strategies. These
technologies, combined with a robust Enterprise Service Bus (ESB), are typically the central force driving the adoption of XML skills within the enterprise. Because XForms is also an XML-centric technology, you will find many synergistic benefits from the introduction of XForms in an information systems strategy. The third ROI model attempts to quantify these additional benefits for any organization that has these technologies in their IT strategy portfolio.
XForms are, by design, consumers of XML Web services. When an XForms application needs
to load an instance of form data, it does it using XML Web services. Each selection list
in an XForms application can also read data directly from a Web service. These
selection lists can be dynamically populated based on the user role and organization.
Each Save button on an XForms application sends XML data to a persistence service. That service can be "smart" and detect the type of data you are saving by the XML content type and then route the data to the appropriate collection or workflow queue for storage and further processing.
Imagine of all your applications immersed in a new ecosystem filled with supplies and
demands for XML Web services. After you build the first generation of Web services, you
may start asking your team: How can we build our next generation faster to support
faster XForms development? Your tools will quickly start to evolve and your staff
will start to get the training they need to be more agile. The creation of new Web services follows the same "experience curve" as any manufacturing process. Broadly stated, as individuals and organizations get more experienced at a task, they usually become more efficient at it. For example if you double the number of Web services you create you may cut the time and cost of each Web service created by 25%. Therefore, XForms can become the keystone of a highly productive declarative and XML-centric development environment.
Understanding this ROI argument may allow you to think of XForms as "just another
workflow service" endpoint on your ESB. We think of Web services as Web components that
take XML in and return XML. In fact, that is precisely the way that XForms works in the browser. It just so happens that there is a human being mediating the value of the XForms data. Any workflow operations that require human intervention can end up with an e-mail message being sent to a user. That user opens an e-mail message with a link to an XForms application. The form not only displays a record but also gives the user a list of workflow options: reject, fix and continue-processing, route to another Web service, or route to another person or workflow queue. See Figure 1.
Figure 1: XForms in a BPM workflow
XForms also uses many XML standards such as XHTML, XML Schema data types, XPath
expression, XML events, and XML bindings. What happens when users start to learn XForms is that they start to leverage existing services and create the demand for new services.
One final issue for XForms consideration; it is an excellent example of a highly
specialized domain-specific declarative language. Unlike the full Java or .Net
languages and frameworks with tens of thousands of classes and methods, XForms has just over twenty elements. This allows it to be learned quickly and easily maintained. It is intended to focus in like a laser beam on a specific task: creating highly interactive Web applications. It's part of a new way to solve complex business tasks by breaking computing problems down into small transformations. Combined with the rest of the XML languages in the XML ecosystem, XForms can transform the way you think about solving computing challenges.
Preparing for the common objections
Before presenting an XForms proposal to the management team, you should be prepare yourself for some of the most common objections and develop strategies to overcome them. Most of these objections come about because decision makers do not understand the true nature of the XForms standard.
"But XForms does not run on browser X"
One of the first ways to deal with this objection is to point out that XForms are just
over twenty abstractions of a user interaction model. How these abstractions run on any
individual device can be changed at any time. XForms application do not need to have native support by any operating system or browser. XForms abstractions can be transformed by Web servers into JavaScript and HTML for every known browser, including new devices like the iPhone™
"But vendor Y does not support XForms"
One of the most challenging things to explain to many IT managers is why some vendors are not interested in allowing organizations to use high-level abstractions. If a vendor gives you a low-level interface that locks you into their operating system or software, they are usually doing what is in the best interest of their stockholders. Any organization that decides to use high-level abstractions frees themselves of the display APIs of any specific vendor. However, to use these abstractions an organization must select business partners and tools that will help them transform these abstractions into the interfaces of the devices they need to support.
"But we can do this all with JavaScript in the browser"
Although this argument is technically true, it misses the main point about architecture,
standards, and maintainability. In fact, some XForms tools are completely implemented
using JavaScript that manipulates the browser document object model. However, the point of XForms is about standards and using XForms abstractions in a consistent way to reduce Web application development costs. You many want to also point out that JavaScript is notoriously difficult to write and debug. Since much of this work has already been done for you by JavaScript-enabled XForms tools, why not just start from there?
"We don't have the XML expertise to support this"
Although this comment often arises in XForms discussions, there are several ways to mitigate this concern.
First, point out that most of the people that will be designing XML Schemas and building XForms will eventually be insulated from the technology by graphical user interfaces.
Second, find people that have already been using XML as part of other tasks; they will most likely have basic skills and will be able to come up to speed quickly. Many software developers frequently read and edit XML configuration files and are already comfortable with the syntax. Web developers that are familiar with HTML and XHTML are in fact using XML every day.
Finally, point out that XML has become the de facto standard for exchanging information
between computers and computer applications. Any organization that wants to be able to
manipulate this data needs to have the staff on hand to read, transform, and validate
XML. Unless your organization plans to put all their data in a single computer with no
requirements to have data interact with other computers (including Web browsers) you may
want to start and XML center of excellence sooner rather than later.
"But XForms development tools are not mature enough yet"
There are in fact many XForms development tools available today from vendors like IBM and
Oracle. Many of these tools are not open source but can provide extremely high-quality
drag-and-drop functionally for non-programmers. When Web standards first emerged, there
was also a shortage of tools for building Web sites and searching Web pages. That is not
to imply, however, that the Web standards were not good standards and it did not prevent
users from adopting Web technologies for small projects like a company Website or an
intranet Web page. XForms tools will certainly mature and the cost of the tools will
decline, resulting in greater adoption in organizations.
Summary
HTML was never designed as an application development language. XForms is a powerful
and deep-reaching technology that could have a large impact on an organization's overall
IT strategy. On the surface, there are around twenty data elements that are added to
XHTML pages to enhance usability. However, underlying XForms is a change in the
contract between the browser and all Web-based applications. It changes the Web browser
from a "dumb" device that allows you to navigate between Web pages to a "smart" device with a clean and elegant architecture that can load intelligent Web applications and execute as-you-type business rules. When coupled with other XML-centric technologies such as SOA/ESB and BPM, XForms can give an organization a large return on investment.
References
Paul Strassmann's 1990 book The Business Value of Computers: An Executive's Guide was an early effort at analyzing relationships between various technology strategies and profitability in organizations. One of his findings is that adopting standards (such as e-mail standards) usually provided a significantly higher ROI than point-solutions. Strassmann also encourage IT managers to go beyond simple ROI analysis and look at the strategic nature of technology investments.
The study of technology diffusion in a population is discussed in detail in the classic book Diffusion of Innovations, 5th Edition by Everett M. Rogers.
If you are interested in finding out more about how to market new technology to a
group, the book Crossing the Chasm Marketing and Selling High-Tech Products to Mainstream Customers by Geoffrey Moore has some excellent insights why many products and standards fail to cross from use by innovators and early adopters to the early majority.
An excellent discussion of recognizing and managing lock-in strategies used by software vendors can be found in chapters five and six of Information Rules by Carl Shapiro and Hal R. Varian.
Download | Description | Name | Size | Download method |
|---|
| Sample Excel ROI template models | XForms-ROI.zip | 31KB | HTTP |
|---|
Resources Learn
Get products and technologies
- The W3C XForms site has a large collection of
resources for anyone considering the adoption of XForms. The site includes
list of tools, vendors, and other XForms resources.
- Check out the W3C
XForms Specification.
Discuss
About the author  | 
| | Dan McCreary is a metadata strategy consultant from Minneapolis, Minnesota. He has over 20 years of computer consulting experience, including work at Bell Labs, the supercomputer industry, NeXT Computer, and his own consulting firm.
Dan was one of the principal data architects of the CriMNet system and has been a contributor to the U.S. Department of Justice GJXDM system and advocate of federal XML standards. Dan has extended the NIEM to include K-12 educational data as well as real estate data. He has a BA from Carleton College, a Masters degree in Electrical Engineering and Computer Science from the University of Minnesota, and is finishing his MBA at the University of St. Thomas. His main focus is semantics and metadata-driven systems. |
Rate this page
| 
