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.

Extreme Programming

What is Extreme Programming?

Extreme Programming (XP) is actually a deliberate and disciplined approach to software development. The methodology is designed to deliver the software your customer needs when it is needed. This methodology also emphasizes team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP improves a software project in four essential ways:

• Communication
• Simplicity
• Feedback
• Courage

XP programmers communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation XP programmers are able to courageously respond to changing requirements and technology.

A Change in the Way We Program

A typical project will spend about twenty times as much on people as on hardware. That means a project spending 2 million dollars on programmers per year will spend about 100 thousand dollars on computer equipment each year. Let's say that we are smart programmers and we find a way to save 20% of the hardware costs by some very clever programming tricks. It will make the source code harder to understand and maintain, but we are saving 20% or 20 thousand dollars per year, a big savings. Now what if instead we wrote our programs such that they were easy to understand and extend. We could expect to save no less than 10% of our people costs. That would come to 200 thousand dollars, a much bigger savings.

Another important issue to customers is bugs. XP emphasizes not just testing, but testing well. Tests are automated and provide a safety net for programmers and customers alike. Tests are created before the code is written, while the code is written, and after the code is written. As bugs are found new tests are added. A safety net of tight mesh is created. Bugs don't get through twice.

Another thing your customers will notice is the attitude XP programmers have towards changing requirements. XP enables us to embrace change. Too often a customer will see a real opportunity for making a system useful after it has been delivered. XP short cuts this by getting customer feed back early while there is still time to change functionality or improve user acceptance.

When should Extreme Programming be used?

Extreme Programming (XP) was created in response to problem domains whose requirements change. Your customers may not have a firm idea of what the system should do. You may have a system whose functionality is expected to change every few months. In many software environments dynamically changing requirements is the only constant. This is when XP will succeed while other methodologies do not.

XP was also set up to address the problems of project risk. The XP practices are set up to mitigate the risk and increase the likelihood of success.

XP is set up for small groups of programmers. Team size between 2 and 12 is perfect, though larger projects of 30 have reported success. Your programmers can be ordinary to use XP. But you can not use XP on a project with a huge staff. We should note that on projects with dynamic requirements or high risk you may find that a small team of XP programmers will be more effective than a large team anyway.

XP requires an extended development team. The XP team includes not only the developers, but the managers and customers as well, all working together elbow to elbow. Asking questions, negotiating scope and schedules, and creating functional tests require more than just the developers be involved in producing the software.

Another requirement is testability. You must be able to create automated unit and functional tests. While some domains will be disqualified by this requirement, you may be surprised how many are not. You do need to apply a little testing ingenuity in some domains. You may need to change your system design to be easier to test.

The last thing on the list is productivity. XP projects unanimously report greater programmer productivity when compared to other projects within the same corporate environment. But this was never a goal of the XP methodology. The real goal has always been to deliver the software that is needed when it is needed.

[Courtesy Extreme Programming Website]

Recipe for XML and Web-Services - The Low Carb alternative for EDI

EDI since decades have been the standard for inter-Organizational Information Exchange. Electronic data interchange (EDI) is the transmission, in a standard syntax, of unambiguous information of business or strategic significance between computers of independent organizations. EDI users do not have to change their internal databases. EDI is the common "language" used to get information from one computer system to another. Users must translate this information to or from their own computer systems, but this translation software has to be prepared only once.

EDI has some serious limitations, few of them being:

1. EDI is expensive, it uses a dedicated communication infrastructure.
2. The definitions used are far from flexible. For instance, it defines a limited set of protocols and terms with respect to a certain set criterion for specific industries. It does allow business users to add their own custom defined tags.

Becuase of the initial popularity of EDI, most of the financial, logistics and retail businesses depend on it for almost all their information exchange. However, the scenario is slowly changing as the industry leaders, along with standard EDI exposure are also providing an alternative interchange mechanics using Web-Services and XML as the new frontier. XML makes communication easy. It's a great tool for transactions between businesses.

So what is XML?

• XML is a meta-language. A meta-language is a language that's used to define other languages. You can useXML for instance, to define a language like Web Markup language (WML).
• XML is a smaller version of Standard Generalized Markup Language(SGML).
• It's easy to master and that's a major advantage compared to SGML which is a very complex meta-language.

XML: What can it do?

With XML you can :

• Define data structures.
• Make these structures platform independent.
• Process XML defined data automatically.
• Define your own tags.

However, with XML you cannot define how your data is shown. To show data, you need other techniques Like CSS or XSL along with your XML. XSL (eXtensible Stylesheet Language) is created for this purpose. But the presentation can also be defined with CSS (Cascading Style Sheets).

Now Coming down to Web Services, What are Web Services?

• Web services are application components
• Web services communicate using open protocols
• Web services are self-contained and self-describing
• Web services can be discovered using UDDI
• Web services can be used by other applications
• XML is the basis for Web services

Web Services can convert your applications into Web-applications. By using Web services, your application can publish its function or message to the rest of the world.

Web Services can be used by other applications. With Web services your accounting department's Win 2k servers can connect with your IT supplier's UNIX server.

The basic Web Services platform is XML + HTTP. Web services use XML to code and decode your data and SOAP to transport it.

The Future of Web services - Don't expect too much, too soon.
The Web Services platform is a simple, interoperable, messaging framework. It still misses many important features like security and routing. But, these pieces will come once SOAP becomes more advanced.

Hopefully, Web services can make it much easier for applications to communicate.

Six Steps to a Successful VMI System

Vendor Managed Inventory (VMI) systems came into vogue in the 1990’s as a way to decrease supply chain costs. Unfortunately, inventory crises left many manufacturers greatly disappointed when their new systems did not create the promised return on investment. Robert Schoenthaler, VP of SC solutions at KPMG Consulting Inc. has pointed out, “The lesson learned in supply chain management is that it is a journey, not something that can be solved in a single project. In the 1990s there was an explosion of growth in planning tools. Now the question of ‘how do I execute’ is becoming more important.”

VMI is not a perfect solution to inventory problems. Susan Cohen Kulp, a researcher at Harvard University, recently finished a study on the relationship between VMI systems and higher profits. Not surprisingly, she found that implementation does not always return better results than a traditional supplier relationship. Her study found that information precision and reliability, combined with an effective sharing mechanism, were the key factors in obtaining higher supply chain profits.

So, how do you implement a successful VMI system?

1. COMMUNICATE expectations of all parties. Customers and suppliers must make the effort to sit down and discuss the goals and objectives of implementing VMI. The importance of this step cannot be overstated. Both parties’ hardware and software requirements must be identified, and an understanding must be reached in terms of how both companies’ systems will communicate. Then a plan for implementation must be mapped, specifically identifying each party’s financial and other responsibilities.
2. Customer must commit to sharing PRECISE information. Suppliers must have visibility into the customer’s internal sales and inventory information. Without accurate data, ability to quickly meet demand will be impaired.
3. Suppliers must ensure RELIABLE transmission, receipt, and use of information. To facilitate step 2, the supplier must be able to guarantee that the customer’s trusted information will be communicated, received, and utilized securely and thoroughly to meet the designated needs. Time should be spent during the planning phase discussing information precision and reliability.
4. Sufficiently TEST systems before going live. As with any new system, testing will uncover any bugs or inefficiencies and can help to avoid future headaches.
5. Expect implementation to be a PROCESS not a project. Remember that there is no on/off switch. Adjustments will have to be made as demand levels fluctuate, and no system will be perfect 100% of the time.
6. Plan to spend sufficient TIME AND MONEY to make it work. Most successful VMI systems we’ve read about took 2-2.5 years to put into operation, and cost hundreds of thousands of dollars for IT and training. Spending (or finding) the time to create a comprehensive system can be a challenge.

Inventory Fundamentals

Inventories usually represent between 20 and 60 percent of total assets of a Manufacturing Organization.
Aggregate inventory management works according to their classification (raw material, work in progress, and finished goods) and the function they perform rather than at the individual unit level. It involves:

1. Flow and kinds of inventory needed
2. Supply and demand patterns
3. Functions those inventories perform
4. Objectives of inventory management
5. Costs associated with inventories.

Item inventory management is also managed at the item level. Management rules include:

1. Which individual items are most important?
2. How individual items are to be controlled
3. How much to order at one time
4. When to place an order

Raw Materials are purchased goods received which have not entered the production process, including materials, component parts and subassemblies

Work In Progress (WIP) is raw materials that have entered the manufacturing process and are being worked on

Finished goods are ready to be sold as competed items

Distribution inventories are finished goods located in the distribution system

Maintenance, repair and operational supplies (MRO) are items that are used in production but don’t become part of the final product, including hand tools, spare parts, etc.

Anticipation inventories are built up in anticipation of future demand (i.e. created ahead of Christmas)

Safety stock is to cover unpredictable fluctuations in supply, demand or lead time. It prevents stockouts

Cycle stock Lot-sized inventory are items purchased or manufactured in quantities greater than needed immediately. This is done to take advantage of shipping discounts or minimize setup costs.

Transportation inventories exist due to the time needed to move inventories. They are also called pipeline or movement inventories.
The average amount = (transit time in days) * annual demand / 365

Hedge inventory (usually done with commodities) is done if prices fluctuate and buyers expect prices to rise, so they buy more now

Inventory management objectives include:

1. Maximum customer service (orders shipped on schedule, stockouts)
2. Operating efficiency (build seasonal inventories, larger production runs, but in larger quantities).
Balance this against costs and tied up $$ in assets

Item cost is the price paid for a purchased item (includes direct costs like transportation, customs and insurance) also called landed price. Can also be determined in house including direct material, direct labor and factory overhead

1. Carrying costs include all expenses incurred by the firm due to volume:
2. Capital costs or opportunity cost of $$ tied up in inventory
3. Storage costs including space workers, and equipment
4. Risk costs include obsolescence, damage, theft and deterioration.

Typically 20%-30% of inventory costs are carrying costs

Ordering costs are associated with placing an order either with the factory or a supplier. It does not depend on quantity ordered.

1. Production control costs
2. Setup and teardown costs
3. Lost capacity cost
4. Purchase order costs

Average cost = (fixed cost / number of orders) + variable cost
Stockout costs expensive due to back order costs, lost sales and lost customers
Inventory turns = annual cost of goods sold / average inventory

ABC inventory determines the relative importance of items and then has different levels of controls

‘A’ items – 20% of items account for 80% of dollars
‘B’ items – 30% of items account for 15% of dollars
‘C’ items – 50% of items account for 5% of dollars

To calculate ABC:

1. Determine annual usage
2. Multiple annual usages by cost to get total dollars
3. List items by annual usage
4. Calculate cumulative annual dollar usage and percentages
5. Group ranked items into A, B and C categories

ABC rules are:
1. Have plenty of low-value “C” items (order a years at a time and carry plenty of safety stock)
2. Use money and control effort saved to reduce inventory of high-value items (‘A’ items)

‘A’ items – high priority – tight control and frequent review, expedite when needed
‘B’ items – medium priority – good controls with normal attention and processing
‘C’ items – low priority – use simple controls and order many items

Summary One needs to balance cost of carrying inventory against:

1. Customer service
2. Operating efficiency (longer production runs and fewer setups)
3. Cost of placing orders (decrease with less orders)
4. Transportation and handling costs (smaller orders cost more per item)