Newsletters

Many times competing goals inhibit the progress within in a software development project. Developers, for example, are most interested in seeing that the written code compiles and works as intended. Systems engineers focus on seeing that requirements are met, while testers are tasked to identify bugs. Sometimes these goals do not always align during an ongoing project. In addition, some groups may fail to see the big picture as they carry out their duties.

The complexity of modern systems makes it difficult to understand what is happening in any specific environment. The problem is compounded by the presence of distinctly different environments for development, production and testing.

According to Gartner Inc., IT complexity is the measure of your inability to understand, use, repair and enhance your IT environment and any solution that helps you understand, diagnose and maintain your environment as a whole will reduce complexity.

The antiquated method of using spreadsheets cannot reduce complexity; however modeling can. For example, modeling can help in design tradeoff analysis and during the early stages of architecture definition for product/technology selection.

To achieve this, though, modeling must be lightweight and quick to respond to changes. In addition, the results from a modeling effort must make sense and answer specific questions. Outages will happen because there is no way to account for every peak that will be experienced. But if modeling is being done, it is possible to be ready for most eventualities.

Take the case of a new application being introduced to the environment. Developers might harness a LAN and some clients to connect to three servers in the lab. In this self-contained laboratory environment, the application experienced low latency. But when moved into the production environment, clients actually had to connect over the WAN and go via a switch to the server bank. Various slowdowns and bottlenecks cropped up.

Modeling helps overcome such errors by enabling the organization to view the impact of a new application in light of the actual environment it is planned for. If, for instance, you capture representative ‘use cases’ during early stages of development or architecture definition, this data can be used to predict the behavior of the application over a model of the network architecture.

Know Your Audience
When it comes to providing feedback to developers, architects and managers, you have to know the audience. Don't overwhelm them with data - just provide the facts that are most useful and applicable to them.

For example, the capacity manager has to know how to effectively (and politically) provide feedback of modeling results to the people who need the information.

Developers aren't interested in hearing that information cannot scale sufficiently and architects don't want to hear that it won't fit on an existing WAN.

You have to know how to present the facts in a way that doesn't engender direct opposition or disgruntlement.

Knowing and cooperating closely with your audience is also vital when it comes to decisions about what to measure and model. For example, is the team interested in peaks, mainly CPU usage or some other metric? Put all assumptions out in the open, and confirm those assumptions before running the model.

Perhaps most importantly, go directly to the team with the initial findings. Do not go over their heads to management. Even if you are sponsored by management, keep the teams in the loop regarding any findings you have. This keeps them on your side.