A lot of talks about XForms are a bit technical in nature because the people who manufacture XForms processors tend to be technical people who understand the business value of XForms in terms like "model-view-controller" architectures, a superset of AJAX, and software engineering benefits like abstraction. But the C-level executive cares not about these things. It is important to connect them to what the C-level executive does care about.

The C-level exec is about efficiency, flexibility and accountability.

The CEO wants

• efficiency via reduced operating costs and decreased time to close deals
• flexibility to react to new business processes and changes of business partners
• accountability for control of expenditures and compliance with regulations

The CIO wants to achieve

• efficiency through end-to-end business process integration and ability to leverage business objects as IT assets
• flexibility through a malleable system architecture that can be rapidly reconfigured with replaceable, reusable components
• accountability through transaction record auditability

We need to speak about how XForms helps the organization to achieve better results along these metrics. This is where the global picture of what XForms does against the backdrop of the classic 3-tier architecture comes in handy.

The C-level exec is not up at night worrying about the server tier, where databases, content managers and workflow engines live. These may be expensive systems, but they are designed to be robust and highly scalable systems whose metrics relative to the size of the anticipated user base of a system are easier to quantify. In other words, they are low risk numbers that are easy to budget for.

The C-level exec is not as concerned about the client tier, where the browser and OS live, again because the metrics are easy and stable.

The C-level exec has the most uncertainty and risk at the middle tier. There are two parts to it. There is the part that uses APIs to talk to DBs, CMs and workflow engines to implement custom application logic as needed. This part is not as scary because we have reliable, robust, scalable, stable APIs, and because the components we're talking to are those reliable, robust, scalable, stable, expensive systems sold by companies with important people's ties to yank when there is a support problem. Then there's the scary, assembly-language-of-the-web-part of the middle tier. This is the part that has to juggle a dynamic, multistep end-user experience on the anything-goes client side, where the web browsers are free and you get what you pay for. The upfront cost of the thin client is low, but the time to market with new offerings is the most highly affected because a lot of unpredictable, time-consuming work lives here.

Enter XForms.

• It allows you to standardize and consolidate the end-user experience into a single business object that represents the overall transaction.
• It allows that business object to access the web services of an SOA as a natural part of the process of going from empty transaction data to completed transaction data.
• It fully represents the transaction and therefore can function as an integral part of the records needed for auditability.

As a final thought, it should be clear from the exponential scales of complexity and cost that the diagram above argues that XForms-based systems have business value through complexity containment, and that said value is rightly reflected in software product cost.