Learn more Shop now Learn more Shop now Shop now Shop now Shop now Shop now Shop now Shop now Shop now Shop now Learn More Shop now Learn more Click Here Shop Kindle Learn More Shop now Shop Women's Shop Men's

on 18 July 2010
This is a different book. Where most books expound a single theme such as Agile, Lean, or Scrum, "Lean Architecture for Agile Software Development" paints on a much broader canvas: Working with the end user, end user's mental model, user requirements, system architecture, and right down to actual code.

This is neither a beginner's "how to do it in ten easy lessons" nor is it a design method. It is a book written for the mature professional by two authors whose long experience has given them a deep understanding of what really matters in practical programming.

At a first glance, many methodologies appear as mere fads, but Coplien and Bjørnvig see through the fads and build on their real worth to create a thought-provoking and eminently practical book.

Three random jottings from my first reading:

* Architecture: "No matter how we care to define it, software architecture should support the enterprise value stream even to the extent that the source code itself should reflect the end user's mental model of the world."

* Lean secret: "...unite specialists together in one room: everybody, all together, from early on."

* Form and functionality: "System architecture should reflect the end user's mental model of the world. The model has two parts: The first part relates to the user's thought process when viewing the screen, and to what the system is: its form. The second part relates to what end users do - interacting with the system - and how the system should respond to user input. This is the system functionality. We work with users to elicit and develop these models and to capture them in code as early as possible."

The authors claims that an end user should have a picture in his head that enables him to see the commands that are meaningful in a given situation and to understand what it will do for him. This picture, Jim calls it the end user's mental model, it will be reflected into the actual code in well-built systems.

A few years ago, this reviewer introduced a new programming paradigm that he called Data, Context, and Interaction (DCI). The main feature of this paradigm is that it splits the code into two distinct parts. One part specifies system state; the other part specifies system behavior. Coplien and Bjørnvig use this paradigm to fill in the gap between architecture and code execution. To quote from the book:

* Key building blocks of object-oriented design: "Objects, which are end users' conceptualization of things in their business world; Classes, which provide simple, encapsulated access to the data that represents business information; Roles, which interact in a use case to achieve some business goal."

This book is a MUST read for all who want to understand the true nature of systems development.
0Comment| 14 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 5 December 2014
Four years after Coplien & Bjørnvig's book came out, Agile Architecture is slowly becoming a Thing. I still think this is the book to read, because it showed me how "Technology Is All About Human Beings" might be expressed not only in working practices but also in a technical architecture.

It's notable that this book's review ratings follow the U-curve: people love it or hate. If you are a practising architect, this is a Must-Read. In fact, it's four must-reads in one. If not, you might dismiss this book for 2 reasons: the homespun style, as if the authors grew up on a farm, does not suit a bullet-point gimme-the-headlines-now generation. The second is that if you have not experienced the pitfalls of trying to architect and build software in a real organisation with actual people in it, then Coplien & Bjørnvig's pearls may impress you much as the agile manifesto might impress a cattle rancher.

I say four books in one:
1) The literally decades of experience of a leading practitioner & thinker in the field
2) A thought-through answer to the questions, what can we learn from lean & agile. Whilst value-chains and some technique feature, the authors' secret conviction is surely that Technology Is All About Human Beings. "Everybody, all together, from early on" is their Lean Secret. "Deferring interaction with stakeholders [the authors list users, the business, customers, domain experts, developers], or deferring decisions beyond the responsible moment slows progress, raises cost and increases frustration. A team acts like a team from the start."
3) Which leads to what, for me as a more-techy focussed reader, was the marvel of the book. Clements et al in "Software Architecture in Practise" offered attribute-driven design, a partitioning of the system based on a priority ordering of, primarily, technical quality requirements. Coplien & Bjørnvig all but deduce a partitioning based on the priority ordering of people: Users first, Development team next. Their points seem me obvious in hindsight, yet they turn traditional approaches to high-level designs on their head. "The End Users' Mental Model" is their early refrain and they explain how distinguishing domain from use cases can help you nail it. Conway's law is next: However non-technically-derived the structure of your organisation, you should still let it lead your architecture.
4) This is the first book-sized exposition of DCI architecture, which I would describe as a proposed architectural pattern for systems that have users. Having separated What the System Is from What the System Does, DCI provides the design pattern for how the Doing (the Use Cases) marshals the elements (both entities and behaviour) of the What the System Is. I find the result remarkable. By clarifying the relationship between domain elements and use cases as, "In Use Case X Domain Element Y plays the Role of Z" the roles needed for a use case become, in the code, its public dependencies. Coupling is reduced, cohesion is gained, clarity abounds. The mapping from business architecture to code is greatly simplified; suddenly one can draw a straight line between them.

Any of the four would be worth owning. All four together is remarkable.
0Comment| 2 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 1 May 2011
I found this an excellent, widely scoped book on lean thinking applied to software systems. I did find it a somewhat unusual book, the beginning is a bit hard to pin down and, in my opinion, the DCI section felt a little out of place. However don't let this deter you, the body of the book is fantastic and it brings together many ideas. It certainly changed the way I think about architecture.
0Comment| 3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 9 August 2010
Most IT projects I've been envolved in starts with an idea, an idea of how to create more value for the once to come end users. It might be the end users them selves that came up with the idea or it might be some one else. The important thing always is that the end product should return a specific value defined by the user or on the behalf of the user.

Most projects I've worked on seems to be neglecting this, not consciously of course but simply because they are working hard at meeting the requirements. The approach in this fabulous book is to look at how we work in software teams and to challenge our ways of work so that we can focus on meeting the requirements at the same time s as we focus on the value the end product is supposed to give the end user
0Comment| 3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 1 August 2013
Microsoft Certified Technology Specialist And Certified Scrum-Master with more than 18 yrs experience. Successfully (on-time/within-budget) delivered multiple agile projects, sometimes as many as 4 projects in parallel.

I've watched time and time again how business's fail to understand the core principles of lean/agile methodologies, especially architecture. The industry is rife with incompetence that worships short-term gain and long-term pain!

Too many managers/projects have thrown the baby out with the bathwater in order to introduce 'agile/lean' practices. I've only skimmed the contents at this stage and it is a testimony to the pearls-of-wisdom contained in this book that it can quickly be observed that this book addresses the balance! How many more projects (and ultimately companies/industries) must we sideline because of incompetent management decisions/practices. Come on IT, get with the 'program'!!!!
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on 10 September 2011
The good:

- Focusses on value streams.
- Practical requirements examples.

The bad:

- Very dry read, very academic in nature with no practical example of the whole theoretical approach working.
- Strikes me as very waterfall in approach.
- DCI struck me as just a simple implementation of the Strategy Pattern with the Decorator Pattern, so the end was a bit of a let down. This would have been fine but the DCI architecture was built up as a major evolution in development.
- The above point reinforced the view that architects are largely out of touch with the practices and technology used by developers, I left feeling that a good business analyst and a good development technical lead would have produced something akin to the output of the book without needing a traditional architect.

To summarise, some good practical examples presented in isolation but doesn't tie it all together and is slightly out of touch with development practices used today.
0Comment| 11 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 28 October 2010
This first book covering the new DCI paradigm of programming is a must read for anyone interested in separating the more often changing behavioral parts of code related to use cases from the more slowly evolving structural parts of domain data.

A great practical description of how the use case evolves and translates directly into code, of how to reflect the end users mental model in code - making it much more readable for both programmers and domain experts. It goes into detail about how use case roles translates to Object Roles playing out their part of a use case algorithm and how they get injected into the domain objects to use their state. And we are presented with how the Context can set up the mapping of Roles to domain Objects in different flexible ways before firing off the trigger Interaction of the use case.

Apart from example code in C++ and Ruby through out the last chapters of the book, it also have a great appendix with coded DCI examples in Scala, Python, C#, Ruby and Squeak.

For anyone interested I can also recommend visiting the Google "object-composition" group where all the concepts are discussed and explored.
0Comment| 4 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 21 September 2011
Agile movement for good or bad is getting more academic traction. This book is such in a good sense: plenty of in-depth analysis and though-provoking insights on the convergence of Agile and Lean. The praxis is not forgotten as well, there are examples and even code snippets, a nerdy paradise.

At first the book takes mostly academic stance. Authors go to great lengths to show the convergence of Lean and Agile ideas in a way that Lean enables Agile, and Agile without lean is wasteful and generally painful exercise. The architecture is seen as an enabling factor for low-waste development. The purpose of it is to separate and isolate slowly changing parts of a system (what-the-system-is -- domain, which is unlikely to change fast) from quickly evolving ones (what-the-system-does -- ever-changing business scenarios). The idea is definitively not new, but this is the first book where it got some convincing theoretic underpinnings.

Other pillar, which is reflecting end users' mental model of the domain in the code in order to enable adequate degrees of freedom, is introduced in middle chapters. Authors are convinced, nothing more Agile than proper requirements capturing. Their the technique of choice Use Case Analysis is argued to be the most natural yet flexible option.

Endgame is quite dynamic. Authors present an advanced architectural style of MVC family called DCI (Data, Context and Interaction). The essence of the style is an approach to laying out the code so it to a maximum degree reflects the mental model of end users, which is captured in the form of use cases. As far as I know this is the first book on DCI, so if you -- like me -- prefer reading books to learn about big new things, this is the way to go. Code examples are in abundance.

Few notes on the style. The text sometimes gets dense and very hard to get through. Reading first chapters require discipline and persistence, though if you managed to get through university, it shouldn't be a problem anyway. On a brighter side, once you cope with the first part, the narrative becomes surprisingly exciting and rich in ideas. Don't try skipping though, first chapters are essential for understanding the message.

As a summary, this is quite a advanced book on software architecture. I dare to say that it may be immediately usable for majority of software architects, but even if not, there are still plenty of food for thought. Moreover, I'd recommend reading it to anyone in software industry as it provides a solid background for understanding how to develop applications and systems with less waste.

(This review was originally posted on Enterprise Systems Engineering blog -- see profile for URL)
0Comment| 3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 14 July 2010
This superb book is about a new vision of the object-oriented world.
Based on the DCI (Data, Context and Interaction) architecture paradigm and renewed Lean principles, the book constructs a lightweight and pure Agile bridge between requirements and architecture. Now you can reach a Lean up-front architecture in an incremental Agile way. DCI gives you a framework for thinking and the inspiration for improvement.
This is a must-read for anyone working in software engineering.
0Comment| 3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 16 April 2015
I was a bit underwhelmed by this; it's basically a fairly long book about quite a simple idea, which isn't really practical, to the extent promoted, in most instances (given the constraints of most modern programming languages). The basic ideas, e.g. of extending the "separation of concerns" paradigm to split system form from system function, is reasonable, but I'd argue it's not the game-changer its made out to be in this book. It also takes a long time to make a fairly simple point, which isn't even a new one (Strategy design pattern, anyone?). I certainly didn't find myself itching to try it out in practice, and i found myself thinking "but you can do the same thing much easier by..." in several places. The whole "lean" connection is a bit tenuous, too: it seemed to me like they added "lean" to the title to make it more topical, without any real substance to it.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse

Sponsored Links

  (What is this?)