Posted by Denis Koelewijn in the early evening: August 10th, 2010
This is the eleventh and last post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The eleventh principle we discuss is called “Freedom where possible, standardize where needed“. (more…)
Posted by Denis Koelewijn in the early morning: July 15th, 2010
This is the eight post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The eight principle we discuss is called “Focus on the value stream“. (more…)
Posted by Denis Koelewijn at around evening time: June 2nd, 2010
This is the fifth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The fifth principle is called “Just in time, just enough“. The essence of this principle is that only architectural work is done that is necessary and possible at that very moment.
(more…)
Posted by Denis Koelewijn just before lunchtime: May 13th, 2010
This is the second of a series of blog posts discussing Lean Architecture principles. Each post will discuss one principle and applying these principles will result in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. Last week we discussed the first principle Always involved. In this blog entry we discuss the second principle that applies to the architect role and the architectural artifacts and is called “Travel Light“. Travel light should be taken literally, how much does the architect have to carry around running from stakeholder to stakeholder? How much material does he need to explain the business needs to the development team, what does he need to explain the vision of the product to the business, to involve operations early on, etc., etc. ?