Comments on: The Three C’s of architecture http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/ Software development done right! Wed, 08 Feb 2012 14:41:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Duchess Community — Blog — Lean Architecture: approach to architectural improvements http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/#comment-95293 Duchess Community — Blog — Lean Architecture: approach to architectural improvements Fri, 18 Jun 2010 14:04:29 +0000 http://blog.xebia.com/?p=4460#comment-95293 [...] Connection, Cohesion, and Changeability. You can read about the 3 C’s of Architecture here: http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/ But here’s my spin: On first glance, it is not really obvious what is meant by connection. [...] [...] Connection, Cohesion, and Changeability. You can read about the 3 C’s of Architecture here: http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/ But here’s my spin: On first glance, it is not really obvious what is meant by connection. [...]

]]> By: Lean Architecture: approach to architectural improvements : JavaPulse http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/#comment-95292 Lean Architecture: approach to architectural improvements : JavaPulse Fri, 18 Jun 2010 13:25:54 +0000 http://blog.xebia.com/?p=4460#comment-95292 [...] Connection, Cohesion, and Changeability. You can read about the 3 C’s of Architecture here: http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/ But here’s my spin: On first glance, it is not really obvious what is meant by connection. [...] [...] Connection, Cohesion, and Changeability. You can read about the 3 C’s of Architecture here: http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/ But here’s my spin: On first glance, it is not really obvious what is meant by connection. [...]

]]> By: Theo Gerrits http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/#comment-94696 Theo Gerrits Fri, 23 Apr 2010 08:31:08 +0000 http://blog.xebia.com/?p=4460#comment-94696 I would say that the formulation of the three Cs has everything to do with the waste elimination of Lean, but the phrasing is opposite: more geared to the benefits than focused on the things to remove/avoid. More precise: *Connection* is what you want to achieve with the elimination of _muda_: that which is non-value adding or unproductive. *Cohesion* is what results from minimizing _muri_, that which is burdensome, overhead or unreasonable. By defining standards (for example reference architectures), the unnecessary learning new frameworks, tooling, etc., and inventing the same things over and over again can be much reduced. It also has to do directly with reducing _mura_: inconsistency. By aiming for cohesion, inconsistency is effectively removed. *Changeability* is perhaps not directly related to Lean, but a *very important* aspect of architecture. I would say that this is what architecture is all about (cf. definition of architecture by Chris Verhoef: "The software architecture of deployed software is determined by those aspects that are the hardest to change". This is also precisely the part of software development that a project manager is not particularly interested in: these are concerns that go beyond the scope of the current project. Concerning product management, if this is taken to mean the governance of products during their lifecycle, I would say that architecture must be (or even: is) a very important part of that, so overlap is no surprise there. I would say that the formulation of the three Cs has everything to do with the waste elimination of Lean, but the phrasing is opposite: more geared to the benefits than focused on the things to remove/avoid. More precise:
*Connection* is what you want to achieve with the elimination of _muda_: that which is non-value adding or unproductive.
*Cohesion* is what results from minimizing _muri_, that which is burdensome, overhead or unreasonable. By defining standards (for example reference architectures), the unnecessary learning new frameworks, tooling, etc., and inventing the same things over and over again can be much reduced.
It also has to do directly with reducing _mura_: inconsistency. By aiming for cohesion, inconsistency is effectively removed.
*Changeability* is perhaps not directly related to Lean, but a *very important* aspect of architecture. I would say that this is what architecture is all about (cf. definition of architecture by Chris Verhoef: “The software architecture of deployed software is determined by those aspects that are the hardest to change”. This is also precisely the part of software development that a project manager is not particularly interested in: these are concerns that go beyond the scope of the current project.
Concerning product management, if this is taken to mean the governance of products during their lifecycle, I would say that architecture must be (or even: is) a very important part of that, so overlap is no surprise there.

]]> By: Gerard Janssen http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/#comment-94693 Gerard Janssen Fri, 23 Apr 2010 06:53:21 +0000 http://blog.xebia.com/?p=4460#comment-94693 Hi Machiel, thanks for your response, you make two excellent points that we discussed amongst ourselves too. When it comes to Lean, we see two major sides to it: Value creation/orientation and operational excellence / optimization of work processes. Waste reduction, which is in fact one of the principles to be discussed in a later blog, is an aspect op the operational excellence side. We choose to emphasize the value orientation aspect of Lean. The value side is most important since it is geared to goals and identity of the organization. When you focus on the value side, the elimination of none value generating ballast will follow. The value orientation aspect is also the reason why I mentioned those responsibilities of an architect. It is about the ends, not about the process. Keeping an eye on goals, consistency and the ability to respond to change implies a long term vision. A project managers responsibility is primarily for his project and business case. The architect supports that responsibility and keeps the long term perspective in mind. He acts as a counter balance of opportunistic, project oriented forces. As far as product management is concerned: there is overlap there too. Product managers look towards the market and the demand side of the product, that is their job. Again, the architect looks at the product from a long term sustainability perspective. He balances the demand side with what supply can deliver. In other words: product manager or product owners cannot oversee technical and delivery consequences of (functional) demands. The architect, which in that respect is a sort of Technical Product Owner, adds that knowledge to the product management function. Hi Machiel,

thanks for your response, you make two excellent points that we discussed amongst ourselves too.
When it comes to Lean, we see two major sides to it: Value creation/orientation and operational excellence / optimization of work processes. Waste reduction, which is in fact one of the principles to be discussed in a later blog, is an aspect op the operational excellence side. We choose to emphasize the value orientation aspect of Lean. The value side is most important since it is geared to goals and identity of the organization. When you focus on the value side, the elimination of none value generating ballast will follow.

The value orientation aspect is also the reason why I mentioned those responsibilities of an architect. It is about the ends, not about the process. Keeping an eye on goals, consistency and the ability to respond to change implies a long term vision. A project managers responsibility is primarily for his project and business case. The architect supports that responsibility and keeps the long term perspective in mind. He acts as a counter balance of opportunistic, project oriented forces.

As far as product management is concerned: there is overlap there too. Product managers look towards the market and the demand side of the product, that is their job. Again, the architect looks at the product from a long term sustainability perspective. He balances the demand side with what supply can deliver. In other words: product manager or product owners cannot oversee technical and delivery consequences of (functional) demands. The architect, which in that respect is a sort of Technical Product Owner, adds that knowledge to the product management function.

]]> By: Machiel Groeneveld http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/#comment-94691 Machiel Groeneveld Fri, 23 Apr 2010 05:42:33 +0000 http://blog.xebia.com/?p=4460#comment-94691 It sounds your definition of architecture is overlapping with project/product management: • what needs to be done, • what can be done, • tangible results and delivery, I like to think of architects concern themselves with making the above possible (in the long term), but not as their immediate responsibility. Otherwise everyone is swarming the same short-term goals (much like the way kids swarm the ball when playing soccer). I can't make out what's particularly 'Lean' about these principles. There's not even a mention of waste reduction. It sounds your definition of architecture is overlapping with project/product management:
• what needs to be done,
• what can be done,
• tangible results and delivery,

I like to think of architects concern themselves with making the above possible (in the long term), but not as their immediate responsibility. Otherwise everyone is swarming the same short-term goals (much like the way kids swarm the ball when playing soccer).

I can’t make out what’s particularly ‘Lean’ about these principles. There’s not even a mention of waste reduction.

]]>