Reengineering Existing Systems

Introducing IoC To An Existing Application (Continued)

(This is a continuation of a previous post)


In the previous post, we adapted our existing code to allow the use of an IoC Container, and prepared the container so it is ready to use.  In this post, we put that foundation to work and start altering our logic.
Install Service Locator
When coding new applications, Inversion of Control (IoC) is best done using Dependency Injection, or DI.  However, DI assumes all necessary classes are registered with the container and available for resolution.  When converting an existing application, it is not practical to convert all necessary classes to DI in one step.  Trying to do so can dramatically increase the scope of the work, making the conversion project more difficult and possibly extending it beyond a single sprint.

In order to avoid the requirement of converting the entire application at once, we introduce an intermediate step of using a Service Locator.  Using the Service Locator pattern allows you to convert objects to the IoC pattern slowly over time instead of requiring a massive conversion effort.  Once an application is fully converted to Service Locator, it is a trivial step to further convert it to Dependency Injection.

The Service Locator is a static class that is referenced from all parts of the system (this is the part that Service Locator detractors object to).  As such, it needs to be located in a central project that can be referenced by all classes that need it.  Depending on how your IoC container works, this project may also need to be able to reference the projects where the Interfaces and Classes are kept. If you have a large solution, finding a good place to put the Service Locator can be one of the most difficult parts […]

Introducing Inversion of Control To An Existing Application

How to retrofit an existing system to use Inversion of Control and Dependency Injection, without the cost of a rewrite. Reduce maintenance costs for legacy systems.

Automated Testing for Brownfield Software

Implementing modern automated testing on software requires that the system in question be broken up into pieces.  This is not to say broken into different systems, just that the code that makes up the entire application need to be composed of distinct pieces, or modules (or classes, or components, etc.)  When things are properly designed, an application will be composed of many different components, and they all work together via interfaces – the information they pass among themselves.  Current automated testing approaches can then take each module and feed it different values for the various interface elements, and check to see that the component behaves in the proper way.

For example, say we have a system that is supposed to accept a data feed (from another system, not a person), validate the data in that feed and record any errors, then email one person on success or a different person on failure.  We could break this system into the following components:

Input reader – reads the incoming data (i.e. in XML) and breaks it into the distinct data fields
Data Validator – looks at each piece of data to ensure it follows business rules
Error Logger – saves any errors found (to text file, database, or elsewhere)
Emailer – creates and sends emails

With the system broken into these parts, automated tests could feed the Input Reader different XML files (some valid, some invalid, some incomplete, etc.) and ensure it handled them all correctly.  A different unit test could create a Data Validator and send it samples of valid and invalid data, and so on.

When working with Brownfield software, introducing automated testing can be one of the most difficult parts because the code is normally a Big Ball of Mud.  In order […]

By |October 21st, 2014|Legacy Applications, Reengineering Existing Systems|0 Comments

Brownfield Software Development – A Step by Step Guide for the Enterprise

The goals of brownfield and greenfield development projects are different.  Greenfield projects develop a new application as quickly as possible to address an ongoing business problem.  Brownfield software development projects, however, are concerned with enhancing existing code to solve a business problem, while keeping the legacy application available.  It is the second part of that sentence that is the key to the value of brownfield development over greenfield – you can fix the plane while it’s in the air.

These different goals require a different management and technical approach.  Let’s assume we are adding a new feature to an existing application.  This is an application that was developed a long time ago and has been working well, but now the business requirements have changed so we must add a new feature.  Moving our legacy application towards Service Oriented Architecture is our long term goal, so we will be also move the application in that direction while adding our first feature.
Step 1 – Introduce Inversion of Control
If the legacy application does not have some form of Inversion of Control, this should be introduced first.  IoC is an common architectural pattern that makes applications much easier to build and enhance by breaking them up into smaller pieces that work together.  Each piece can be replaced with something more functional at any time without affecting the rest of the system, as long as the inputs and outputs remain the same.

One type of IoC is called Dependency Injection.  This is an excellent approach to use when building applications from scratch, but can require a lot of work when trying to introduce the pattern into an existing system because the pattern must be used everywhere – it cannot be slowly introduced to […]

Greenfield and Brownfield Application Development

To quote Marc Andreeson, “Software is eating the world”. To those in the technology industry this should be self-evident since we see new software applications being created each day. A question rarely asked is what happens to all that software as it gets older and needs to change to meet new market demands. To answer this, we need to split software development into two categories: Greenfield Development and Brownfield Development.
Greenfield Application Development
Greenfield Development refers to brand new applications – ones that start from scratch (or as Wikipedia puts it “…lacks any constraints imposed by prior work”). This can mean a new application that solves a previously unaddressed business problem, or a system that completely replaces an existing system which is inadequate in some way.

In greenfield development, the feature set and interfaces are dictated only by the problem being addressed.  The different aspects of the problem can be solved in any way the development team sees fit, as long as it solves the described problem.

Greenfield development can be quite time consuming since it requires all aspects of the new system be defined and constructed.  For new applications that are meant to replace something that already exists the process can be just as lengthy.  Though it would seem that when replacing an existing application much of the work has already been done, the very fact that the existing system needs to be replaced indicates that the current system is inadequate, therefore duplicating what is already there is insufficient.

Due to its very nature, a greenfield project can only begin adding value to the business when it is complete.  While still in process, there is insufficient functionality to provide any benefit, and can even do harm if the system […]