Customer Reviews

Convergent Architecture: Building Model Driven J2EE Systems with UML

5 star:		(10)
4 star:		(1)
3 star:		(0)
2 star:		(1)
1 star:		(1)

 

 

When I started this book, I was looking forward to an explanation of how to use the Convergent Architecture to create a J2EE application. What I found was a vague, confusing, and repetitive discussion that often reads as if it was in a tragic accident with a thesaurus. The idea behind the Convergent Architecture is not that complicated. We need to create a model driven architecture above UML that can link design and actual code development. Too often in this book the Convergent Architecture is not explained in terms of what it is but rather how it is like designing cathedrals, diesel engines, or jet planes. The author tells us that using the Convergent Architecture can reduce time up to 70% and that these numbers are endorsed by neutral parties but he gives us no information about these neutral parties. And he doesn't tell us what the 70% is actually compared to making these numbers useless for doing any evaluation. The book promises to be a "step-by-step" guide but instead reads like a corporate white paper designed to sell a product. And there is a product in here that the author is selling. He is the founding director of the company that makes a product that takes up the last two chapters of the book. The only part of the book that is "step-by-step" is the tutorial on how to use the author's product. Overall, I was very disappointed in a book that I looked forward to reading.

This is the first book I have found on model-driven development, and there is no need to look any further. I really like how the author ties model driven concepts to David Taylor's convergent architecture approach. I've been waiting for the book that shows how to implement Taylor's ideas in his Business Engineering with Object Technology, and this is it.

This book gets to the heart of issues surrounding the development of large scale software systems. The real beauty is that Hubert does not just outline the conceptual and philosophical issues surrounding software development - he proposes structures and methods that address the problems. Should be mandatory reading for anyone involved in IT.

I started this book with no anticipation of the treat in store. Having read it, I have to say that if you're interested in significantly improving software development efficiency, and you read only one book this year, then this is it! It's a "must read" for any software engineer, architect, or manager involved in boosting "time to market", "responsiveness", or "timeliness".

There is a slowly-growing body of experience in proven approaches to high-efficiency software development. This book shows Richard Hubert to be clearly among the front-runners in the field.

A foundation observation in this field is that, across many projects, there is often much commonality. "Silo" or "stovepipe" developments ignore this commonality. A core goal is to capture commonality and apply it as widely as possible. This is feasible because the technical content of many projects is similar: one web service app is broadly much like another, as are most mainframe batch apps, or stand-alone GUI apps. However, capturing commonality alone is not sufficient. Other key factors are architecture, process, tools, and organization. They must all be brought together into a cohesive whole.

Most industries (other than IT) have known for many years that meeting their "time to market" goals requires this kind of cohesive approach, which Hubert calls "Architectural Style", and fully describes at the start of the book. Thus designing an building a range of products that are similar (such as a range of cars, or a range of houses, or a range of hairpins) can benefit from having the same architectural style, which is understood across the industry, is taught in schools, which evolves over time, and which implies a given set of structural concepts, processes and organization, tools, and technology outlook. Hubert explains how these are the four major elements of an architectural style.

The particular architectural style presented in the body of the book is the "Convergent Architecture" of the title, and addresses distributed applications such as web services. This style has as its metaphor not the mass-production of Chaplin's "Modern Times", but rather a machine shop with highly skilled engineers, each doing what they're best at. Hubert presents the Convergent Architecture in terms of its major elements - base enabling concepts (which he calls the metamodel), component architecture, the IT organization model, development process, and tools. Along the way, project design and management is covered. Also, the process of taking components from the business model straight through to implementation shows how one of the major promises of OO can be delivered. And the way it's done-this is what MDA really means!

It might be thought that Hubert's approach requires a revolution, but this is not so. Like other practitioners in the field, he proposes an evolution, and includes process support for its management. For example, he shows in some detail how RUP is tailored for the Convergent Architecture, so building on currently-available products. He also touches on some of the low-down and difficult challenges, such as how much technical glue to write to make life simpler for application developers - the more you write, the further from standards you get.

Last, but not least, there is a worked example, using Hubert's company's Convergent Architecture IDE, "ArcStyler", from business model right through to EJBs. Now it might be thought that spending over 40 pages on a proprietary product is mere publicity-seeking. But it's not. It's proof that the tool market is now starting to address one of the great challenges facing our industry: how to move away from the cottage industries of stovepipe development into seriously productive development. And if it also advertises the product, well, if it does the job, what's wrong with that?

Finally, this book is well-written, well-structured, and at 250 pages, a comfortable read. If you've read any of the few other books in this field (such as Peter Herzum and my "Business Component Factory", or "Software Product Lines" from the SEI), then this book is an essential companion, bringing valuable new insights. If you haven't, then this book is not only a first-rate introduction to the field, but also a major contributor to it.

This book is a brilliant vision of applied architecture. Everyone who is architecting, or funding, enterprise projects should read this book. This book provides an extraordinaily useful framework for architecting systems.

This is a great work that defines an entirely new method of software development, architecture and testing. As part of that it advocates code generation through use of Model Driven Architecture (MDA). If you are looking for a practical work showing step by step use of MDA with screenshots, this isn't it. But if you are looking for a methodology book, and something that will stretch how you think about development, this is the book for you.

I started this book with no anticipation of the treat in store. Having read it, I have to say that if you're interested in significantly improving software development efficiency, and you read only one book this year, then this is it! It's a "must read" for any software engineer, architect, or manager involved in boosting "time to market", "responsiveness", or "timeliness".

There is a slowly-growing body of experience in proven approaches to high-efficiency software development. This book shows Richard Hubert to be clearly among the front-runners in the field.

A foundation observation in this field is that, across many projects, there is often much commonality. "Silo" or "stovepipe" developments ignore this commonality. A core goal is to capture commonality and apply it as widely as possible. This is feasible because the technical content of many projects is similar: one web service app is broadly much like another, as are most mainframe batch apps, or stand-alone GUI apps. However, capturing commonality alone is not sufficient. Other key factors are architecture, process, tools, and organization. They must all be brought together into a cohesive whole.

Most industries (other than IT) have known for many years that meeting their "time to market" goals requires this kind of cohesive approach, which Hubert calls "Architectural Style", and fully describes at the start of the book. Thus designing an building a range of products that are similar (such as a range of cars, or a range of houses, or a range of hairpins) can benefit from having the same architectural style, which is understood across the industry, is taught in schools, which evolves over time, and which implies a given set of structural concepts, processes and organization, tools, and technology outlook. Hubert explains how these are the four major elements of an architectural style.

The particular architectural style presented in the body of the book is the "Convergent Architecture" of the title, and addresses distributed applications such as web services. This style has as its metaphor not the mass-production of Chaplin's "Modern Times", but rather a machine shop with highly skilled engineers, each doing what they're best at. Hubert presents the Convergent Architecture in terms of its major elements - base enabling concepts (which he calls the metamodel), component architecture, the IT organization model, development process, and tools. Along the way, project design and management is covered. Also, the process of taking components from the business model straight through to implementation shows how one of the major promises of OO can be delivered. And the way it's done-this is what MDA really means!

It might be thought that Hubert's approach requires a revolution, but this is not so. Like other practitioners in the field, he proposes an evolution, and includes process support for its management. For example, he shows in some detail how RUP is tailored for the Convergent Architecture, so building on currently-available products. He also touches on some of the low-down and difficult challenges, such as how much technical glue to write to make life simpler for application developers - the more you write, the further from standards you get.

Last, but not least, there is a worked example, using Hubert's company's Convergent Architecture IDE, "ArcStyler", from business model right through to EJBs. Now it might be thought that spending over 40 pages on a proprietary product is mere publicity-seeking. But it's not. It's proof that the tool market is now starting to address one of the great challenges facing our industry: how to move away from the cottage industries of stovepipe development into seriously productive development. And if it also advertises the product, well, if it does the job, what's wrong with that?

Finally, this book is well-written, well-structured, and at 250 pages, a comfortable read. If you've read any of the few other books in this field (such as Peter Herzum and my "Business Component Factory", or "Software Product Lines" from the SEI), then this book is an essential companion, bringing valuable new insights. If you haven't, then this book is not only a first-rate introduction to the field, but also a major contributor to it.

My company provides IT services for French banks and the book give excellent solutions for architecture problems we see every day. The most important problem is the divergence between the business aspect and the IT dimension in the design of many applications. Huberts book shows how to address this with convergent architecture and MDA in real life scenarios.
I am not surprised that this book receives either very good or one very bad rate, but nothing in between. The architecture focused readers find it good, and M. Colin J. Davies finds it too general on the one side and too much concerned with a software product otherwise and useless. But the book shows very good how to integrate many tools for a model-driven achitecture approach and go from abstract system design to increased technical detail in models and deployment. Of course if this process is automated with transformation from model to model to code, a experienced Oracle expert will miss code listing that he can change. But the book shows that the database design of a system must be the result of convergent engineering and does not start the process. I want to recommend this book for everybody who have to implement real-world architecture and have to solve hack scenarios at lower programming levl.

When I got this book, I was primarily interested in MDA. The author provides is a clear outline of the concept of "IT architectural style", something that is greatly missing in the IT industry. Hubert's work is pleasantly different from other books in that it does not try to promote any specific technology as the exclusive solution to all IT problems. Instead, you get a generally applicable conceptual framework and one specific implementation of this concept. The book is of great value for a great variety of readers. IT consultants, CEOs and CIOs will find the more abstract descriptions on architectural style and IT architecture of particular interest. Project managers and IT managers will benefit from the chapters detailing the MDA approach. And even if you just want to know how to organize an IT department in a meaningful way, this book is what you should read.

This is a great book for understanding why MDA is important.

My favorite quote from the book;

What large IT organizations need is less philosophical discussion regarding absolute truth and more agreement on Architectural Style.

Another great theme that I'm kind of parapharasing;

If we built airplanes like we build software there would not be much of an airline industry. Most of that is due to style, no one builds an airplane from first principals, why do we so often build software that way.

This book is worth the money. Like one of the other reviewers I was dissappointed in the 'tutorial' nature of everything past chapter 3. However, I thought the first 3 chapters were worth the price and more importantly the time to read it.

For example in Chapter 1 the author goes into the 'higher level of communication' we get out of a style. When someone says 'car' a huge amount of information is transfered in that small 3 letter word. With an architectural style, the author argues, we can begin to have this same level of high bandwidth communication.

Hopefully we have all been on at least one project where there was a practical mind meld in the team. All to often though we are on teams that have to have 2 hour meetings to define the word 'entity'. Until we can perform mind melds for real a 'style' will help us to communicate better.

I give four starts instead of five due to the tutoral nature of the last half of the book.