Lean Architecture

Architecture is a longstanding metaphor for software design and construction and particularly for programming-in-the-large. Software engineering has largely embraced this metaphor in many forms, ranging from the use of the software title architect to the metaphors offered by the pattern discipline.

Architecture is the form of any system created through conscious design, and it thus has strong human elements both in its process and its product. The term form implies a deep mental model of the essence of some structure. A structure has form; a given form awaits implementation in structure. For example, an image comes into your mind when we invoke the word chair. For most people it’s not a wholly concrete image: it may not even have a color until the question causes you to assign it one. We might suggest that we meant to have you think of a five-legged chair and, although you are likely to have envisioned only four legs, you likely will not protest that such a structure violates the form of chair. Architecture drives to the essence of a system.

The term architecture broadly touches a host of concerns in the built world, which perhaps can best be summarized in the terms popularized by the late Roman architect Vitruvius: utilitas, firmitas, and venustas. As captured by these terms, much of the classic architectural vision speaks of quality of human life. While the link of architecture to fashion and even to esthetics is controversial, commodity and utility (utilitas) are fundamental; so architecture is beauty. Architecture is not without an engineering component that encompasses materials and techniques of construction, as good construction must be durable (firmitas) and architecture arguably is timeless. Last, but certainly not least, architecture should inspire a human sense of delight (venustas). We can distill “delight” as comfort, beauty, or awe.

Because form is a result of design, and not of analysis, architecture lives squarely in the space of design. Architecture itself is therefore not principally about knowledge management, although knowledge management activities such as domain analysis and pattern mining often serve as powerful preludes to architecture. Lean is about eliminating waste, and Architecture helps in this because:

• Architecture will define standards which reduce inconsistencies, and avoids time and energy waste in recurring issues and discussions;
• Architecture sets up the system for dummy-proof feature development, reducing time and energy waste in recurring issues and amount of repetitive boilerplate;
• Architecture organises the code so that it can speak for itself, reducing time and energy waste in writing extensive documentation;

The software pattern discipline took major departures from the Alexandrian vision of architecture, and these departures are no more apparent anywhere than in object oriented practice. The Design Patterns book was selective in its application of Alexandrian ideals. On one hand the GOF recognized that software has crosscutting constructs that aren’t visible in the code, but are nonetheless part of the design vision of the programmer. This notion of scaling beyond individual objects to relationships takes us firmly into the realm of architecture. Patterns were arguably one of the strongest foundations of the agile, design thinking, design sprint, Lean Startup and Lean UX agenda. The ideas of piecemeal growth and local adaptation that are fundamental to pattern-based developments would be taken up almost verbatim by the pattern community. Agilists would embrace Alexander’s valuation of human concerns over method less than a decade later. Gartner (as well as numerous others) tried to visualize how methodologies like Design Thinking, Lean, Design Sprint and Agile flow nicely from one to the next. Most of these visualizations have a number of nicely colored and connected circles.

Geert Claes has beautifully put these methodologies into a X,Y model. Anyhow, most innovation methodologies can add great value and it’s really up to the team to decide where to start and when to apply which methods and techniques. The common ground most can agree with, is to avoid falling in love with your own solution and listen to qualitative as well as quantitative customer feedback.

How do I define Business Architecture?

To simplify any business or company, I usually try to define them in 3 layers, in following figure I have shared my model of thinking:

In order to understand the business model, I use various canvas tools but one of the most common one that I use very often is Business Model Canvas. A global standard used by millions of people in companies of all sizes. You can use the canvas to describe, design, challenge, and pivot your business model. It works in conjunction with the Value Proposition Canvas and other strategic management and execution tools and processes.

Then I put together what is each business look like in those 3 layers. For instance for a FinTech startup called iCare Benefits, iCare Benefits is a for-profit social enterprise which enables manufacturers, social organizations, banks and service providers to serve workers at the bottom of economic pyramid, The following figure demonstrates the 3 layers of iCare:

It is very crucial to define what is your core business and what is not, then you can set strategies on which areas matter the most that requires more focus. Besides, for non-core business you should purchase a ready product and adopt your processes and refrain customization. At iCare, in order to facilitate this transition and be committed to our principles we have defined following categories:

• Core Business. At iCare Benefits we have defined following items as core business:

1. Revenue Generation, any channel, technique, technology, product that help us to generate more revenue.
2. Repayment, any channel, technique, technology, product that help iCare Members to pay back the loan
3. Collection, any channel, technique, technology, product that help us to collect the debt

• Non-Core Business. All other areas except core business will be considered as non-core, such as Finance, Accounting, Inventory, Fulfillment, SCM and etc.

According to this classification we should decide what product or services should be acquired, everything on non-core business must be acquired from a third-party. Then we defined a change program called: “iCare Reloaded” which comes with many different solutions that covers all perspectives of our business. The following figure illustrates a high-level architecture of iCare Reloaded Program.

Data, Context, and Interaction

DCI is an acronym standing for Data, Context, and Interaction. DCI is very much in line with these architectural shifts in agile. DCI is much more about mental models than about technology — more about the end user’s intent than the architect’s intent. Good software, like a good house, suits those who inhabit it. On the technology side, the focus is on thinking and the creation of good separation of form. While some technological underpinnings are of course necessary to support the DCI model of computation, this issue has not risen to the level of language debate or of a battle of technological prowess.

DCI leads the programmer and the user of the code (sometimes the same person) into a dialog that helps capture mental models in the code. DCI offers a home for the end user mental model directly in the code in contexts and domain classes. That obviates the need for an additional level of documentation, removing a level of handoff and translation between the end user and the programmer.

DCI is an approach to system architecture that is characterized by several postmodern notions:

1. Value ideas over objects; Architects of the built world have long been fascinated with form and function. The phrase “form follows function” is a vernacular English language idiom that stood as a truism for ages. Contemporary architects are wont to critique this posture and offer alternatives such as: “Form follows failure”, which evokes the need for change and dynamics in converging on a suitable architecture.
2. Favoring compositional strategies over individual parts; DCI is about compositional strategies: how to capture function and form and to reintegrate them under a computational model at run time.
3. A broad-based, human-centric agenda; DCI data classes correspond to the domain organizational structure, and contexts correspond to system-level deliverables. Recalling Conway’s Law, this structuring supports team autonomy.
4. Focus on change. Complex systems are shaped by all the people who use them, and in this new era of collaborative innovation, designers are having to evolve from being the individual authors of objects, or buildings, to being the facilitators of change among large groups of people. Sensitivity to context, to relationships, and to consequences are key aspects of the transition from mindless development to design mindfulness.

I found “Lean Architecture for Agile Software Development” great books that focus on this topic very well. More and more Agile projects are seeking architectural roots as they struggle with complexity and scale — and they’re seeking lightweight ways to do it.