Information System Design

Lately I've been busy acquiring in-depth knowledge of Web Services and why do we need them. In this journey I came across few good things and few not so good things. My primary concern was always the design issues which forces one to use Web Services and on the top of that the architectural concerns, constraints etc. Not to forget the Business Requirement which adds to the constraints we already have to deal with.

In this process I came across a very good which described about the Basics of an Information System design. Lets first get our head around what an Information System consists of. In a Typical information system we have:

1. Client Layer: The front-face of the application as seen by the client. This is typically a HTML page rendered by the web browser.
2. Presentation Layer: The logic which is used to render the data and build the presentation for the client. The best example of this is XSL rendering which is being used in eBay web pages.
3. Business Logic Layer: Set of programs which process data entered by user as per the business rules defined in the system and then pass on to data access for storing. When retrieved the raw data from the data access layer these programs are responsible for converting them into a format which is meaningful to the user.
   
4. The Data Access Layer: The data access layer manages the way data is stored in the system. It exercises the Normalization / De-Normalization principle, Establishes relationship among data elements before persisting them into the data store. This understands the format in which the data is being stored.
   
5. The Resource Layer: This is the core of an information system. The data which is stored in Database, File Systems, Active Directory etc form this layer of the information system.
   

Having known the different parts of an information system we then go for designing how the information will flow and how the different parts of the system will interact with each other. There are few different approaches which is put into practice by architects and designers around the world.

Top Down Approach:
This is the most common approach which is followed by the architects and designers around the world. In this methodology the Functionality or the Business Requirement drive the system design and their components (abstraction) etc. Here client is the center of focus always. The system is designed to keep client in mind, how will they interact with the system etc. The name Top-Down approach comes from the way the design of the system evolves. The designer first sees how the client is going to use the system ie Presenation Layer, then they design the Business Logic or Application Logic components of the same and then at the end the resources (data store) is finalized.

The steps involved in Top Down approach is:

1. Define access channels and client platforms
2. Define presentation formats and protocols for the selected clients and protocols
3. Define the functionality necessary to deliver the contents and formats needed at the presentation layer.
4. Define the data sources and data organization needed to implement the application logic.

This approach of design has few advantages like it emphasizes the final goal of the system, and at any point in time it can cater to changes in both functional and non-functional needs of the system. But on the other side it can be applied to only the system which is developed from the scratch.

Bottoms Up Approach:
The Bottoms Up approach of system design is not a preferred choice of the designer to start with. It occurs out of necessity than the choice. There are systems which exists in this world serving their original purpose with great accuracy and the organizations rely heavily onto it for their day to day business function. But these systems have become legacy system as they are not able to cater the needs of requirements than they are originally designed for. These systems have a fixed set of functionality defined and the development effort to make changes in the system to cater the new requirements are not viable option for the organization. Under such circumstances the Bottoms Up approach is used.

The Steps involved in Bottoms Up approach is:

1. Client Defines access channel and Client Platforms.
2. Examine legacy system and any other resources and the functionality they offer.
3. Build a wrapper around the existing resources and also build an adapter to provide a consistent interface to the outside world.
4. Build adapters around the application logic so that it can be used by any client and access channels and protocols.

As stated earlier this design approach is not by choice. Rather it is dedicated by the need to integrate the services provided by legacy systems. This is one area where much of spending in today's world is happening. Most of the buzzwords today like Web Services, SOA, EAI all are primarily targeting in this area.

Until Next Time...:)