Why the noise about System Landscaping?

In examining software maintenance processes for improvement opportunities or for integrating existing systems with newer ones an obvious choice is information flow. Obtaining accurate, up-to-date, and useful information about a system being maintained is a major task. It is also a difficult task because the sources of this information are often limited, inaccessible, or unknown. Clearly this impacts maintenance productivity-simply because of the time it takes to find and use the appropriate information sources-as well as the quality of system changes, which depends on the quality of the system information available. On the surface, maintainers overwhelmingly rely on source code, which is not surprising. However, a deeper analysis show that other sources of information, in particular human sources, some types of CASE support, and lessons learned recorded from previous projects are at least as valuable than source code under some conditions.
Information flow besides information itself, is perhaps the most important aspect of systems design. Not only it is imperical to know how data is stored and processed into information; it is also vital to know as to how the information flows between processes and inter-organizational systems.
During pre-sales and sales cycles, most of the consulting firms earn their bread and butter in analyzing the current systems, information and information flow. This information has a major impact on the deal to be signed as it reflects not only on the current maybe untapped potential of the current environment and its capability and compatibility to integrate with newer systems. The Systems information gathering and data mapping takes considerable time. Since, data mapping is inevitable (every other software will have a different Database design and schemas), systems information gathering reduces the activity time of re-collecting one's own database configuration. Of course, a final verification and validation of native databases is also needed as over the time, they too may get updated or re-configured as part of maintenance activities and change requests.
The System analysis also exposes the available interfaces or in case of incompatibility, the possibilities as to how it can communicate with other systems. Knowing the methods of such an integration also indicates the availability of data. By methods, it can mean the refresh frequency, partitioning of data, whether it is EDI, XML or other procedure.

How to begin with System Analysis?
Instead of tring to answer How to do System Analysis, I rather prefer to answer the question as to how to begin with it lest to save my blog from turning into a book.
Analysis can best begin with the Software side of it; what Softwares are being used, Who are the vendors, what are the operating systems used, what versions of the softwares and OS, etc.
Next comes the physical manifestation and other nuances; what and on how many servers is it running on, Is is partitioned or replicated and whether it is web based or not.
Answers to these questions lead us to the next level where we try to find out the the application aspect of the system. As this level, we try to get a handle on information such as how many business users access the system, how many administrators are present for the system, what are the peak hours for the system, what is the load (CPU and memory utilization)on the system during peak and off-peak hours, the availability of the system (many systems require or recommend a restart over the weekend or month end) and so on.
Going forward, the next step would be to find out about the data itself and the dimensions it is being stored for. For instance, how old and how new is the data, is there data archival available and if historical data can be made available. Also, what are the other dimensions associated with the data apart from time. Data access and authorization and sensitivity of the data itself.
Now, from the vast data that may be available to oneself, the next step and an important one too is to decide how much of the data is required for the new integration or enhancement which is coming through. Without this information, one cannot go forward because here it is decided whther the new solution is feasible or not and also, if the organization can derive any business value from the data (and the lack of it).
Once you know what data to choose and pick from, one has to decide how? Is it through an EDI or is it through XML. Are there batch process running in the background for data update, whether it is real time viz the methods of information flow. What good is data that you cannot access and make use of. Here itself, you'll have to verify as to how many of these existing methods can you reuse and whether you'll need newer interfaces for pulling out the data.

Once all of this is done you're up for the next big tasks namely – the Data interpretation, Data Mapping and transformation rules.