When a business searches for software to meet a particular need, along with the functional requirements, they provide a set of non-functional requirements that they expect to be met. These non-functionals are mostly common to any application that is required to be enterprise grade. The Haskell core language in itself doesn't meet these non-functionals so in the discussion that follows the word "Haskell" is used to mean the core language plus libraries and packages built by the community.

In the inital version of this paper, the following sources for packages are used:

Persistent Data - Data needs to be stored between instantiations of the application. Typically for a desktop application these are files on a local disk which the application reads and writes to directly. This sort of storage is not suitable for enterprise systems for the reasons that follow.

Lots of Data - A simple file based storage for an application is acceptable where there is a 'small' amount of data but when indexing and caching are brought in, a database management layer is required.

Concurrent Data Access - Not only is there lots of data, it needs to be accessed by more than one person and not just as a partition for each user (which can be achieved by files) but the data needs to be shared and control imposed over access and updates.

Lots of User Interface Screens - Not only is the application itself complex but there is likely to be different modes of operation depending on the class of users - some users require just query and viewing access whilst others require full update access. These modes of access and their associated screen layouts should be configurable rather than hard coded.

Integration - No system is an island. Integration to other systems is required and done using standard middleware

With all of the above complexity, the system still needs to perform as well as a dedicated desktop application. In order to met this the application is typically divided into tiers:

Database Layer (also referred to as Model)

Application Logic (Also referred to as Controller)

Presentation Layer (Also referred to as View)

The question then breaks down into how can Haskell meet of the above architectural needs and in particular how can multi-tier Haskell applications be constructed?

The architectural needs listed in the previous section are often presented in the form of non-functional requirements (NFRs). Furthermore, it is not expected that the developers will implement all the NFRs from the ground up since some of these can be meet using a third-party tool or library. In the latter case integration, typically through an API, is required to be supported.

At first sight NFRs, seems to be self contradictory, surely all requirements are functional - they are what I want the system to do? Yes, this is true but think of these as non-domain specific requirements or domain free requirements - they are requirements for all applications regardless of whether it is is an e-commerce application or a customer management system. Having said that, one persons NFR is another persons' requirement; a security NFR is a functional requirement for someone developing a security package. In most cases however security is an NFR.

NFRs are broken down into the following. The order of the list is from the most concrete and technical to ones that are slightly more subjective or forward looking. These later ones are often met by words, rather than technical deliverables.

The table below describe how Haskell and associated libraries and contributions can meet each of the above NFRs. How it can provide the building blocks to build Enterprise applications.

Foreign Language Integration

Key to meeting many NFRs as it provides access to libraries that do realise the requirements.

Integration to well know database backends, SQL based. It is not expected that enterprise applications come with their own 'home cooked' database and instead the expectation is that they will utilise an existing database package, typically an RDMS. In most cases this is mandatory, as the enterprise can leverage existing DBA skills, be guaranteed that their data is not locked away in a proprietory database and they can access it easily using reporting and data mining applications.

So the need here is for the language to support access to well know database packages.

Package must be easily extensible preferablly through configuration rather than long code - compile - link cycles. Some form of scripting or plugin architecture is good. Configuration management can be done using common tools and processes.