July 28, 2015
Hot Topics:

The Role of XML in Agile Enterprise Architecture

  • January 21, 2004
  • By Jeff Ryan
  • Send Email »
  • More Articles »

(Is XML Really Boring?)

Recently, I attended a talk about 'Agile Enterprise Architecture' by a well-known author and speaker. It was an inspiring talk that discussed agile tools, methods, and processes. During the question and answer period, I posed a question: "What role does XML play in agile enterprise architecture?" The answer floored me: "Quite frankly, I think that XML is boring" was the author's curt reply.

I was so taken aback that I didn't know how to respond at the time. I thought I was asking a leading question. I was expecting to hear that XML has become pervasive in enterprise architecture in a few short years and that it has tremendously improved agility (the modifiability, portability, reusability, integrability, and testability of software[i]).

Is XML really boring?What is its place in agile enterprise architecture?

We'll begin our exploration with a brief background on XML. Next, we'll discuss the virtues of XML. Then we'll move on to the technologies that comprise and have been inspired by XML. We'll discuss the tiers used to describe enterprise architecture and how XML and XML technologies are used in each tier. Then we'll summarize XML's role in agile enterprise architecture.

XML Background

XML was introduced a few short years ago, in 1997. It is a descendant of SGML (Standard Generalized Markup Language), which is a language for describing markup languages, particularly those used in electronic document exchange, document management, and document publishing. XML is a cousin markup language of HTML that has also made a meteoric rise in popularity and usage.

Virtues of XML

Why has XML become so pervasive since 1997? Perhaps the many virtues of XML explain why.

XML is Simple

XML represents data through a hierarchical tree structure of elements. Elements are composed of data, attributes, and other elements. A tag is the markup language used to describe an element. An XML tag is represented by the element name enclosed by angle brackets.

An XML document can be used to store simple structured data as well as complex or even unstructured data. The rules for constructing an XML document are simple. A well-formed document can be easily parsed into elements, attributes, and data.

XML separates data from presentation

Unlike other markup languages that embed data within presentation components, XML separates data from presentation. For example, in HTML, the following might represent customer data laid out in a tabular format:

    <td>ABC Pizza</td>

HTML tables or <table> elements describe a tabular structure of rows and columns. Table row or <tr> elements contain a row of data. Table data or <td> elements contain data values. HTML describes the presentation characteristics, in this case a tabular layout. It describes the presentation, and contains the data values, but does a poor job of describing the data for other uses.

In XML a customer might be represented as follows:

  <Name>ABC Pizza</Name>

XML concentrates solely on describing the data. This data could be rendered in a multitude of presentation formats, unlike the HTML table shown above.

XML is self describing

XML comes with no pre-defined vocabulary or schema, unlike other markup languages. It can be used to describe virtually any data structure. Its tags, as in our customer example, describe the data.

XML is adaptive

New data elements can be easily added to our customer XML document, as shown in bold in the following example:

  <Name>ABC Pizza</Name>

Existing clients would not be affected by the addition of the Email and Website elements. Generally, clients are agnostic to added data elements.

XML is interoperable

XML is a text-based data format that can easily be parsed and understood by heterogeneous hardware and software platforms. For example, an XML document can be used to communicate data between J2EE and .NET.

XML is standards-based

XML and many XML-inspired technologies are based upon industry standard specifications. There are many competing implementations of the various XML standards. There are also many proprietary XML technologies aspiring to become standards.

Technologies Inspired by XML

Let's take a look at a few of the standard technologies that comprise and were inspired by XML.

DTD (Document Type Definition) and XML Schema describe the structure, content, and semantics of XML documents. Many standard XML vocabularies have emerged using DTD and XML Schema. SOAP (Simple Object Access Protocol) and WSDL (Web Services Definition Language) are examples of XML vocabularies used in Web Services. ACORD XML is an example of a standard industry-specific vocabulary.

In order to parse XML documents, several approaches have been standardized: DOM (Document Object Model) is an API that provides an object representation of an XML document and can be used to both to query and manipulate documents; SAX (Simple API for XML) is a push-based API for parsing XML documents as a stream of events; StAX (Streaming API for XML) is a new standard pull-based parsing API. These API are implemented by various languages and vendors.

XPath is the query language for XML and plays the same role that SQL does for relational data. XPath is a building block for several other XML-inspired technologies, such as XSLT (eXtensible Stylesheet Language for Transformations), a language for transforming XML documents into other formats and XQuery, a language for querying XML documents from a broad spectrum of XML datasources.

XForms is a platform-independent markup language for data capture and validation. It provides an XML-friendly means of data capture. XForms improves upon HTML forms by separating presentation and content.

These are but a few of the technologies that exploit the virtues of XML.

Enterprise Architecture Tiers

For a moment, let's pause our discussion of XML and XML-inspired technologies and discuss a typical tier structure for describing enterprise architecture. Then, we'll see how XML maps into the enterprise tiers.

Typical enterprise architecture can be categorized into the following tiers: Client Tier, Presentation Tier, Service Tier, and Resource Tier. Configuration is not a tier per se, but permeates all tiers.

Client tier

The client tier includes thin, browser-based user interfaces and thick, rich client user interfaces.

Presentation tier

The presentation tier services the client tier. In the case of a browser-based interface, the presentation tier serves up markup pages and other resources to the client tier. Typically, this tier would be built upon a MVC (model-view-controller) framework to separate the business model (data and business logic), view (presentation code), and controller (response to user actions).

Service tier

The service tier hosts business and technical services. Services expose components through a common interface and are accessible from many clients, including the presentation tier. Typically, this tier would implement a SOA (Service Oriented Architecture) framework and include the ability to produce, consume, deploy, and manage services.

Resource tier

The resource tier includes the back-end systems of record, which may include mainframe systems, vendor packages, databases, and external resources. Resources are exposed to various clients via the service tier.


Configuration is not really a tier per se; at least not yet. However, intra-component, intra-tier, and inter-application configuration is a reality of enterprise architecture. Applications, services, and components are becoming more and more configurable or data driven to improve their agility.

Page 1 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel