I’ve just finished reading Lean Architecture masterpiece by James Complien et al. A review is to follow, but the book gives such a refreshing perspective on the essence of Lean, so I can’t stand without formulating my own view on the idea in the light of what I’ve just read.

I couldn’t agree more when authors contrast Lean with Agile. On the one hand, Lean per se is about eliminating waste, and rework is a notorious manifestation of waste along with defects, excessive work-in-progress, unnecessary movement, etc. On the other hand, Agile practitioners clearly state that responding to change is superior to following a plan. Moreover, new and changed requirements are welcomed, even late in development, of course, at expense of rework.

Arguably, the most prominent and well-developed pillar of Agile is being able to respond to change. Even a naive application of prioritized backlog planning, short time-boxed iterations and frequent releases with demonstrations can do wonders in many situations. However, this feedback-driven development leads to major rework as the price you pay for accommodating changing requirements, but rework itself doesn’t contribute to the value stream, and hence it isn’t Lean. This is exacerbated to a greater extent when one needs to scale Agile development beyond a small project being developed by a small co-located team. A common belief that you can always refactor and introduce a solid architectural foundation that would enable less wasteful changes is a myth. Time ‘hardens’ systems. Authors of the book quote a fascinating metaphor comparing architectural refactorings to stirring a bunch of cement: eventually, it sets, and you can’t stir it anymore.

What is the primary vehicle for waste elimination? It is said that rework and afterthought (in positive sense) during the engineering phase of product development helps reduce waste later, in actual manufacturing. This is fair enough, we can imaging how up front considerations on the organization of the factory floor flow can lead to less waste.

However, in our trade there’s no manufacturing. Software-intensive enterprise systems engineering consists entirely of analysis and design activities (and their friends verification and validation). The coding and integration activities are still closer to design, albeit a very detailed and specialized one, there’s no factory floor involved. So when and where is that up front thing?

The answer does require some out-of-the-box thinking and the same time is pretty much obvious. What you need to do is to engineer the engineering. By giving up front thoughts on the way a system is to be developed can you reduce waste during the actual development life-cycle.

What can you actually think about? A couple of things. First, you can take into account the development process you use. That is what is called situational method engineering and is understood as an application of systems engineering principles to processes of doing a work on various stages of system’s life cycle. A process is composed from instantiated method components taken from some sort of repository, and subsequently tailored to a particular need. It’s a theme that is getting a lot of attention recently in multiple seemingly independent communities:

  • General acknowledgement of the fact that there’s no proper way of doing Agile. It is interesting to see how ‘Agile movement’ slowly but surely gets over its fundamentalist message of early days and starts revisiting its own practices and borrowing from next door methodologies. There is evidence of attempts of coming up with repositories of agile method components, considering which practices scale well and which don’t, and even blending with plain old systems engineering to produce a reliable approach to offshore development. Funny enough, you wouldn’t be able to find terms such as ‘gate review’ in an Agile paper three years ago, but now it is almost welcomed.
  • MFESA (Method Framework for Engineering System Architectures) is being developed by evergreen Software Engineering Institute. The framework offers a classical method engineering approach to architecture and design activities in a project. All usual suspects such as method components repository are in place. Nice idea, but it’s the early days of it, so the jury is still out if it gets recognition or not.
  • OPF (OPEN Process Framework) is ‘a public-domain object-oriented framework of free, open source, reusable method components’ having ‘over 1,100 state-of-the-art reusable method components’ that is ‘intended to be used to engineer endeavor-specific methods for developing and operating software-intensive systems’. Fair enough, and very good job.

But there’s more than just processes. You may make a sensible decision with regard to the architectural style for your system under design. I’m using this term in a traditional sense, i.e. an overreaching design pattern that is employed in a particular system’s architecture to drive its structure. Prominent architectural styles are Event-Driven Architecture, Model-Driven Architecture, Domain Driven Design, Blackboard, but there are many more of them.

Usually architectural style imposes certain way of thinking about the system being developed. For example, in the aforementioned book authors present a novel and advanced architectural style called DCI (Data-Context-Interaction) that — given the proper application — does a fantastic job of separating slowly changing parts of the system (what-the-system-is, a domain expertise) from malleable, uncertain parts (what-the-system-does, a set of supported business scenarios). Main selling point of the style is that you get less rework while ’embracing changes’, which is Lean — hence the title of the book.

Note that these two things — process and style — are not independent, but rather complimentary. Useful methods normally demand certain assumptions about the system-under-design to hold. In other words, a method imposes constraints on what you can achieve using it in the same way as laws of physics limit what we could build with a particular set of materials. For example, use case driven process such as RUP works best when system requirements could be sensibly described as scenarios initiated by external actors. It is not advisable to apply RUP for developments such as closed-loop control system or graphical editor.

On the other hand, productive application of an architectural style usually requires certain way of doing analysis and design, that is essentially a method. For example, by applying Domain-Driven Design you have to cater for workshops with domain experts, and incorporating their feedback into the model that underlies the design. On the other hand, if your style of choice is Model-Driven Architecture, please consider separating modelling exercises and development of code-generation templates.

In Systems Engineering speak this dualism could be described as an interface between the system-of-interest and its enabling system (a developer). I’m pushing the envelope here, as interface is understood as point of interaction between a system and its operating environment. On contrary, enabling systems are said to be working directly with the system-of-interest. In the light of the cement metaphor that I’ve quoted above it is not exactly so, i.e. a system-of-interest has its own ‘physical’ constraints that enabling actor have to take into account, i.e. incorporate process elements that accommodate them.

That’s it for now. Hope I’ll finish the review post for the book soon.