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.

SCRUM - The New Kid on the block!

What is Scrum?




Scrum is an Agile process that can be used to manage and control complex software and product development using iterative, incremental practices. Scrum has been used from simple projects to changing the way entire enterprises do their business. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development. Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. It's attributes are:

• Scrum is an agile process to manage and control development work.


• Scrum is a wrapper for existing engineering practices.


• Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing


• Scrum is a process that controls the chaos of conflicting interests and needs.


• Scrum is a way to improve communications and maximize co-operation.


• Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.


• Scrum is a way to maximize productivity.


• Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.


• Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

Scrum naturally focuses an entire organization on building successful products. Without major changes -often within thirty days - teams are building useful, demonstrable product functionality. Scrum can be implemented at the beginning of a project or in the middle of a project or product development effort that is in trouble.

Scrum is a set of interrelated practices and rules that optimize the development environment, reduce organizational overhead, and closely synchronize market requirements with iterative prototyes. Based in modern process control theory, Scrum causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates. Useful product functionality is delivered every thirty days as requirements, architecture, and design emerge, even when using unstable technologies.

XP@Scrum

Scrum has been employed successfully as a management wrapper for Extreme Programming engineering practices. Scrum provides the agile management mechanisms; Extreme Programming provides the integrated engineering practices. An article written by Ken Schwaber and Kane Mar on one implementation is at the Prentice Hall InformIT web site.

Benefits of xP@Scrum include:

The agile management and control mechanisms of Scrum are applicable for any type of project, including business initiatives that consist of multiple, simultaneous software development, business development, re-engineering, marketing, support, and implementation projects.

• xp@Scrum projects fit within the overall management framework of these initiatives.


• xP@Scrum projects realize the full benefits of self-organization; teams are iteration (or Sprint) goal directed, rather than story directed.


• When Extreme Programming projects are wrapped by Scrum, they becomes scalable and can be run simultaneously by non-colocated teams.


• Scrum implements in a day; Extreme Programming can be gradually implemented within the Scrum framework.


• xp@Scrum projects benefit from ADM's business value metrics process for measuring and managing initiative ROI.