If you are going to eat the elephant that is legacy IT systems, it's best to get the beast down to bite-sized chunks,...
says Richard Hopkins and Kevin Jenkins, who are executive IT architects for IBM in the UK. Based on their experience doing just that, they have co-authored a book, Eating the IT Elephant: Moving from Greenfield Development to Brownfield, which has garnered praise from Grady Booch, IBM Fellow, co-creator of UML. He writes that the authors "introduce us to a reality that's often neglected in our industry: the problem of evolving legacy systems, a domain they call 'Brownfield development.' This as opposed to 'Greenfield development' – the kind that gets most of the headlines.
The authors identify the root of the problem as that of complexity, and offer an approach that focuses on the fundamentals of abstraction and efficient communication to nibble at this problem of transformation bit by bit." Hopkins talked to SearchSOA about the book in this interview.
Read a sample chapter.What are we talking about when we talk about Brownfield development?
We are not talking about replacing legacy systems or re-platforming them, or transforming their code base. Brownfield is about mining existing environments, which include legacy applications but also more modern applications. In projects we've worked on, I have seen legacy systems that are written in J2EE Java and are only about seven years old. These aren't just COBOL programs. This is the entire gamut of the existing installed base of our clients. Brownfield development involves gaining an in-depth, detailed, multi-layer understanding of that environment. Then you use that to reverse engineer and then re-engineer that environment. To do that we've been using model-driven and pattern-driven engineering techniques. Can you summarize the philosophy of legacy modernization behind Eating the IT Elephant?
The philosophy is about saying what is there – the vast majority of it – is what you need. And you're never going to replace the whole IT infrastructure for any significant systems. So we've got to get smarter by taking individual elements out of that complex morass, and replacing them with new versions of them, rather than doing wholesale replacements or wholesale junking. There's an awful lot of valuable investment in those systems and in those programs. We need to find ways of mining that value out of them, and using it in more flexible ways in the future. So this is Brownfield as opposed to Greenfield?
We're trying to get away for this Greenfield view of the world where we always start from scratch each time. Well, we don't. The world as it exists is a complex space and we don't have the money to replace everything. Therefore we need to have methods to optimize what's already there. Can you implement service-oriented architecture with this approach to Brownfield?
A lot of our clients are looking at that as a way of moving to service-oriented architecture. You can't move to SOA in a single jump. You've got to do it in a series of ordered steps. Those steps can only be done by taking chunks and moving them to where you want them to be. So you use Brownfield to mine the existing environment. Once you mine the existing environment, you use abstraction techniques to understand it, actually get it into your head. Once you've got it in your head, you use the modern techniques of re-engineering, forward engineering, model driven techniques to replace elements of that environment or improve the quality and flexibility of them. What is the future of the enterprise service bus in Brownfield development?
You have to have an enterprise service bus. You can't do things point-to-point anymore. It just doesn't make economic sense. So once you've accepted that there's an ESB to be built that will allow you to rationalize interfaces and start reusing elements all the way from the canonical model to the mapping. You're in a very interesting position because you know you've got a lot of very similar code that you're going to need to write. Everything's going to have an onramp. Everything's going to have an off-ramp. So this is one of the areas where we focused on generating that highly repetitive enterprise service bus code. Putting one schema in for the source, another schema in for the target and hooking things together using a very simple business analyst proven tool and then essentially pressing a button and getting a lot of the configuration and a lot of the low level generation of the code required to run across the ESB.
We're seeing an increasing trend where the business analysts are the programmers. Essentially what the business analysts are doing when they write down their perspective is they have to document it in a slightly more formal form than they were used to in the past. This is a moving away from the free-form drawing tools and making use of UML tools that have slightly more formality. So it's a bit of a culture jump they have to do to realize that what they are creating has to be written in a specific language. But they then become the programmers. After the initial culture shock, the reaction once they get used to it is very positive indeed. They know they've got direct control over what's coming out at the end of the pipe. It gives the business far more control and visibility in what's going on in the definition of the solution and far more control over the business logic, too. What about approaches to legacy modernization based on moving the legacy code into an ESB-based service-oriented environment?
That is a non-starter from my perspective. It takes something that is intensely procedural and puts it into a target that is essentially non-procedural. It doesn't do much to help you understand what you've ended up with and probably makes maintenance harder in the long term. It's an interesting idea but fundamentally it's a dead end. If you want to do transformation you've got to take a different path where you understand what you are looking at across multiple levels of abstraction, not just at the very low level of the syntax tree.