Foreword

More than ten years ago I wrote what many call the “definitive book on integration” entitled Enterprise Application Integration. The idea for the book was simple, really. Put some time and energy around planning how various enterprise systems communicate with each other, and leverage some sophisticated technology to make integration work in reliable and changeable ways.

Until then, and what is still sometimes the case today, many looked upon integration as a one-off development project, coding to interfaces between two or more systems. It was always cheaper, it always worked at first, but it always hit a brick wall at some point. This was a hack-after-hack approach that quickly led to a dysfunctional state of architecture where changes are difficult if not impossible to make. We needed a better approach and some good thinking around how integration is done.

While I often get credit for kicking off integration as an architectural discipline, the reality is that many smart people worked on the integration problem prior to my book, and they are still working on it today—for instance, the authors of this book, John and David. I remember meeting John for breakfast in 1998 when he was working for AMS and talking about what was next for integration. Even then John’s thinking was highly innovative and forward-looking. John’s most profound ideas placed discipline around integration, something that was not the case then and is still lacking today.

So, what is needed today? First and foremost is the importance of data in this generation of cloud computing and SOA. Data has always been, and always will be, the foundation of all sound architecture, no matter if you leverage SOA as an approach to architecture, or cloud computing as an option for platform deployment. Understanding the importance of data means that you’ll create more efficient and agile architectures that can accommodate any required changes to the business.

In the last ten years, we’ve gone from hand-coding interfaces between source and target systems to EAI as a better approach to integration. Now we move on to SOA as a way to create architectures that address most behaviors and information as sets of services, and to data-oriented SOAs that are “Lean Integration and Integration Factories.” In many respects we are returning to our roots, but doing so with better technology and refined approaches, such as Lean Integration. The benefits will be a reduction in system costs and a huge increase in efficiencies.

The fact of the matter is that integration is an architectural pattern. Like any architectural pattern, you can improve and refine integration into something more productive and more innovative. That is exactly what the authors have done here. In short, John and David have written the right book, at the right time, for the right reasons. John and David present concepts that take integration to the next level, making integration more accessible, efficient, and cost-effective. I jumped at the chance to promote this book to my publisher, as well as the chance to write the foreword. Lean Integration should be read by anyone involved with an integration project.

“Lean Integration” is a management system that emphasizes continuous improvements, meaning you don’t complete the links and call it done. Integration requires an ongoing interest in the way integration is carried out and the mechanisms required. This means consistently reevaluating and improving the approaches we leverage for integration, as well as the technology employed. Integration is a journey, not a project.

The end results of leveraging Lean Integration go right to the bottom line, including as much as a 50 percent labor productivity improvement via value stream mapping. This is the use of constant improvement to locate and eliminate non-value-added activities, in short, things that are not needed and don’t add value to the ultimate customer.

Moreover, Lean Integration provides the value of agility. This means you create an integration infrastructure that is able to change around a changing business or mission. You’re able to quickly adjust around these changes, and thus you have the value of quickly altering the business to get into new markets, get out of old markets, and outmaneuver your competition. The strategic advantages of agility are huge.

The approach of addressing data quality within Lean Integration means that you can finally treat data as what it is: an asset. Not addressing data quality means not taking care of that asset, and thus the diminished value of the data results in the diminished value of the business. Data quality also addresses the use of data governance, which is required to adhere to regulations but needed more to protect our data assets no matter what systems are currently managing the data.

Core to this concept is the ability to promote and manage innovation, allowing those in the organization to create and test their own ideas for improving integration. This provides a feeling of empowerment, which is a benefit to the employee, as well as the actions around good ideas, which is a benefit to the company.

What is most profound about Lean Integration is that many of the ideas in this book are obvious, but not leveraged. In reading this book you find many things that seem to be simple but good ideas, and you find yourself asking, “Why did I not think of that?” over and over again. However, while the ideas are important, having a framework of understanding is vital as well. You have to place these disciplines into context and make them part of a repeatable process, which is another core feature of this book.

Lean Integration marks the end of chaotic integration practices and the beginning of continuous improvement, which enhances the value of integration. As the number of systems increases within enterprises, so does the need for integration. You can do integration the right way, which is the Lean way. Or you can struggle with it for years to come. I recommend the former.

David S. Linthicum