The Three C's of architecture

Xebia Author

In our work with clients we often have discussions about the function of architecture and the role of architects. These discussion are largely due to fact that architecture does not visibly contribute to organizational goals and is perceived as a nuisance for projects. Many discussions originate from a lack of understanding of the role and place of architects in the organization. We have defined three goals of the architecture function in IT organizations: The Three C's of Architecture. These are: Connection, Cohesion and Changeability. Taking these as the prime principles of architecture provides focus on what to do and how to position architecture in the organization.

Organizations are continuously changing and operating in ever more dynamic environments. This places big demands on the IT department. It constantly needs to ensure it supports the business goals and changing circumstances. Architecture should play an important role in this process. This implies that architecture must focus on contributing value. Architecture does not exist for esoteric reasons, it is not there to define and prescribe the most beautiful or technological most advanced architecture. No, it has to focus on business goals and value creation as its ends. Architecture is just a means.

There are three main principles, focal points upon which architecture should base its effort. The first is Connection to the organizational goals. Roughly, these come two categories. First, business goals that define what the company exists for and what place it has in the marketplace or society. Second, projects, business cases that define opportunities to further the first type of goals. For Connection principle, architecture needs to work on connecting the efforts and capabilities of IT with these goals and endeavors. It needs to thinks about how structures, technical solutions and infrastructures need to be organized to realize the goals as good as possible. Architects do have a role and responsibility here to understand the business aims and ambitions. And architects must make sure that other people in IT understand how to realize these aims and ambitions into concrete solutions.

IT is expensive. Period. That is not just a perception of the business, it is reality. We need to find ways to most efficiently use IT. One part of the solution is Cohesion in the kind of solutions created and deployed. By choosing from a limited number of solutions (reference architectures) we can keep the complexity contained. Cohesion also helps to organize the systems in a way that promotes sensible partitioning of functions and responsibilities, such that simplicity and flexibility are increased.

Change is a given, so we better be ready for it. Changeability is the last focal point of architecture. It is the capability of IT to adapt to changes in business goals and the environment quickly. Changes disturb the Connection between business goals and IT capabilities and it might disrupt the Cohesion in within IT. By focusing on Changeability we can restore Cohesion and Coherence as quickly as possible.

The effect of defining the role of architecture by these three principles is focus.
We gain focus on
• what needs to be done,
• what can be done,
• tangible results and delivery,
• quality,
• cost effectiveness

In short: focus on results that matter. It is interesting to note that these principles apply to architecture at multiple levels: enterprise, project, systems and infrastructure architecture are all governed by these principles. In that respect the three C's of architecture do not only help unite business and IT effort, but also unite the different IT functions themselves.

This blog is the first in series about Lean Architecture, an architecture method that bridges the gap between classical architecture , Agile Project Management and long term goals of organizations.
The upcoming series will first focus on a series of Lean Architecture principles: basic principles or mantras that form the foundation of Lean Architecture and how a Lean Architecture approaches his responsibility.

Comments (6)

  1. Machiel Groeneveld - Reply

    April 23, 2010 at 6:42 am

    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.

  2. Gerard Janssen - Reply

    April 23, 2010 at 7:53 am

    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.

  3. Theo Gerrits - Reply

    April 23, 2010 at 9:31 am

    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.

  4. [...] 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. [...]

  5. [...] 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. [...]

  6. [...] de l’IT au travers de ses différentes fonctions. Traduction libre du billet « The Three C’s of architecture » publié par Gerard Janssen sur blog.xebia.com.Billets sur le même thème [...]

Add a Comment