A commonly-heard maxim in the software and content publishing world is the importance of separating content from presentation, or separating structure from presentation, or presentation from behaviour, etc.  There are many variations on this theme, but they all share similar objectives:

• separating responsibilities of one kind or another
• making certain types of change easier
• allowing reusability.

Let’s take a look at a few examples and see where information architects (of my type) get involved.

The first example is the classic three-tier web application, which breaks an application into three layers:Presentation layer, which manages the user display and interaction

• Business logic layer, where business rules are implemented
• Data layer, where data is stored

Each layer has responsibility for certain aspects of the application functionality, and can be developed by different people, using different technologies.

These three layers communicate using a request/response mechanism.  For example, the presentation layer might send a request to the business logic layer submitting information (“can you add this name and address record”) or requesting information (“can you retrieve all books by this author”).

Elaborating the first example, we would have the sequence of events:

• Presentation layer:
  • a web form captures name and address information and does some simple types of validation, for example ensuring the user has provided a name, and that the email address in the correct format name@provider.something
  • if the form data passes this validation, it is packaged up and sent to the business logic layer.

• Business logic layer:
  • this layer receives the name and address information submitted by the form and checks it against business rules; the business rules can range from simple to complex
    • name and address must be unique
    • address must be unique, as when an offer says “only one per household”
    • name and address must pass a real time credit check or identity verification
  • if the name and address passes all business rules, then it is sent to the data layer, with instructions to update whatever database structures are required.

• Data layer:
  • this layer receives the package of name and address information from the business logic layer and updates the appropriate database structures;
  • in this example, the business requirements may specify that we create a unique customer identification number
  • the data layer tells the business logic layer that the update was OK, and provides the customer identification number that was created.

• Business logic layer:
  • passes the customer identification number back up to the presentation layer.

• Presentation layer:
  • displays a confirmation page that the user has successfully registered, applied or whatever, and provides them with their customer identification number.

This structure helps understand a front-end information architect’s role.  Here are some traditional considerations:

• IA identifies what types of information are needed and their characteristics (Should we keep a log of all registration attempts, for instance?)
• IA and UX specify how information might be packaged in the presentation layer (Do we need a review page to present the information back to the user? Do we use Ajax so that results of business rules checking can be presented to the user without page refreshes?)
• IA and UX need to understand the business rules and determine what recovery path we can given the user when the rules are violated
• IA does not get involved at the data layer; often, what seems to be a simple name and address might actually be stored in a number of tables.

One of the benefits of this structure is that different presentation layers can use the same business logic and data layers.  For example, we could submit name and address information using:

• different variants of a web form on a browser, or a kiosk, or webTV
• mobile web or resident apps for a mobile device.

And if we were “retrieving all books by author”, we could display the results in any of the above channels too.  We could also generate PDF or Excel spreadsheet versions and present them to the user, or email them to the user as attachments.  Architecturally, this would entail extending the three level architecture by adding common services to convert the data to different formats, and to send email.

Of course, in the more distributed world we have been talking about, we might be exchanging data with other systems.  In the two cases we have been discussing:

• an external system might send us name and address information as a chunk of XML using web standards for the intercommunication
• we might send the list of books by author to an external system as a chunk of XML using web standards for intercommunication.

In these situations, the IA will involved in designing any additional information that needs to accompany (wrap) the XML package.  For example:

• the sender of name and address information might have to provide their company name, a unique request ID, and a timestamp
• when we sent out our list of books, we might similarly provide our company name, a unique ID, and a timestamp.

The external systems can be considered another layer whose details we know absolutely nothing about.  What all parties do have to know about is the request/response protocol. This described in a document  called an application programming interface (API), which talks about all aspects of the communication between the systems, not just the structure of the information exchanged, but also lower level protocols specifying how to reach and connect with the service being provided, and any credentials needed to use the service.

The Information Artichoke Home Page | Modern IA Course Table of Contents