Download (direct link):
Someday, application development will outgrow its painful adolescence and gain the kind of maturity that building architecture now enjoys. As with modern office buildings, business applications will be assembled out of proven components that offer standard solutions to recurring problems. Each will be a unique construction, but—like buildings—they will share compatible subsystems, be easily maintained, and deliver reliable service.
This book is a seminal contribution to that goal. It offers, both through its content and by the example it sets, the possibility of coherent architectures for business software. The particular architecture it describes, the Convergent Architecture, may well be the most comprehensive, detailed framework ever proposed for large-scale business applications. Although many parts of the architecture are new, it incorporates the best of current practices, such as Model Driven Architecture (MDA), Responsibility Driven Design (RDD), and the Unified Modeling Language (UML).
The inspiration for this architecture is a discipline called convergent engineering—a discipline my colleagues and I developed a decade ago to facilitate the design of scalable, maintainable business systems. The founding premise of convergent engineering is that the design of a business and its supporting software should be one and the same. For each key element of the business, there is a corresponding software object that acts on its behalf. These objects come in many forms, but they fall into three broad categories: organizations, processes, and resources.
Rules govern how these three kinds of objects can be combined and how they interact. For example, processes consume and generate resources, and can take place only in the context of an owning organization. These rules bring useful order to the difficult task of re-engineering a business, and they do so in a way that directly specifies the software to support that business.
Richard Hubert learned convergent engineering in May 1996, when he took my week-long certification course at the Convergent Engineering Institute (CEI).
Within a year, Richard had gone on to receive his master's certificate, entitling him to certify others, and had opened the second international branch of CEI in Freiburg, Germany. He and his staff of consultants at Interactive Objects Software (iO) were soon using convergent engineering in large-scale development projects throughout Germany, combining it with other techniques to expand it into a more comprehensive architectural style.
Frustrated by the lack of adequate tools, Richard and his team began developing software to better capture the results of their design efforts and to automate the generation of code. The end result was the release of iO's award-winning ArcStyler product, a suite of tools that models a business in terms of organizations, processes, and resources, and then drives that model into an executable system that can be deployed on any of the major Java application servers. Remarkably, the business model remains visible throughout the development lifecycle. If a process is improved or an organization restructured, the necessary changes are made to the corresponding business objects using high-level design tools, not by altering the low-level code. The tool is a compelling demonstration of Convergent Architecture, and it gives the architecture a solid grounding in the hard realities of software development.
The architecture described in this book is a significant contribution to the software industry on two distinct levels. At the most evident level, it provides a detailed prescription for application development, one that can be adopted as is or adapted as desired. At a deeper level, it illustrates the kind of effort that will be necessary to impel the industry out of its prolonged adolescence and into a mature engineering discipline. For the first time, we have a coherent, compelling vision for application architecture combined with precise instructions for implementing that vision, including all the necessary tools to go from concept to code. It is a combination that is certain to raise the bar for the application-development community.
—David Taylor, Author, Business Engineering with Object Technology
But what's the point of having everything measured by poles? Why not
build everything higgedy piggedy, like a house? First, because it's cheaper this way. All the arches of the arcade are identical, so we can re-use the falsework arches. The fewer different sizes and shapes of stone we need, the fewer templates I have to make. And so
Second, it simplifies every aspect of what we're doing, from the original laying-out — everything is based on a pole square-to painting the walls — it's easier to estimate how much whitewash we'll need. And when things are simple, fewer mistakes are made. The most expensive part of building