Published on January 7, 2019
I’ve just checked Google for the term “Lean Architecture” and found several links, all of which lead to a quite ambiguous situation. Not earlier than last year, Chris Shayan published an article “Lean Architecture” in DZone. He said, ”The concept or architecture remains a staple in descriptions of various forms and practiced patterns of software development, especially when applied to Lean methods”.Well, an Architecture is not a staple but a reason and foundation, without which “forms and practiced patterns” are purposeless and, thus, valueless. A software architecture doesn’t differ from any other architecture because no architecture depends on the means of its implementation including software. Architecture can’t be applied to any methods including Lean methods – the methods can be applied to an implementation of architecture. In the quoted statement, I see just a tendency in modern technology to use particular interest as a hammer and knock everything around with this hammer to make personal point. I am afraid, this is not a personal sin of Mr. Chris Shayan, but a modern bias among Developers – setting things upside-down to outline their role (at the bottom of IT development) for their benefits.
As it is widely known, an architecture is a conceptual model of a system and, as such, contains certain abstraction embodied in the (very special) architectural elements. The latter is not acceptable in the software development/implementation because architectural elements are not under Developer’s control.
Everyone can find the Lean Architecture Site that has been created and administered by Michael F. Czap, AIA. He defines “Lean Architecture” as this, “Lean Architecture is the ongoing process of rethinking and improving architectural methodology.” That is, “Lean Architecture” is not a model of system and does not comprise architectural elements, but it is a process for thinking about an architectural methodology. Really? Since everyone thinks about architectural methodology differently, we will never ever be able to understand what architecture means. In other words, the author denies the meaning of architecture used in the Theory of Systems. Otherwise, a term “Lean Architecture” is a marketing murmur (like Process Architecture or Agile Architecture). In contrast, I believe that any system contains special, architectural elements that simultaneously are fundamental for the system, self-sufficient and cohesive. All other non-architectural elements in the system are either derivatives from or dependants on or inheritance from the architectural elements. Non-architectural elements can change or can be changed with no impact on the systems architecture.
In plain English, if we use an adjective for a noun, we assume that the noun is described in practical and special way by this adjective. That is, we may understand that the adjective represents a category of the noun or the noun comprises elements of the adjective type. A term ”Lean Architecture”, therefore, has to mean either a special type of architecture or an architecture of Lean. To make sense of the former, we have to be represented with concrete architectural elements and principles that distinguish this architecture from all others. While Lean (architectural?) principles are defined (and I will review them later), I have not seen one architectural element of Lean Architecture. To make sense of the latter, we have to take up an “architecture of methods” – the thing, which does not make sense and does not exist.
Actually, Mr Czap confirmd my conclusion by saying, “It is [Lean Architecture] the pursuit of better work by applying Lean principles to every aspect of practice. It is about smarter information flow and understanding how we perceive and process information in order to be better communicators amongst ourselves and to the users of our services. It is identifying what adds value and reducing and eliminating what doesn’t.” I hope I do not change the sense of what was said if outline a few points made by Mr Czap: the Lean principles are not for architecture, i.e. they are not architectural principles, but for the practice; they are about how we act in processes and outside of them, how we communicate between ourselves and with our consumers, how we add values. Altogether, “Lean Architecture” is not about architecture – it’s about operations, practice, communication. So, why is it called architecture? Why Lean specialists need anything like architecture at all? Why they cannot practice communication and leave Architecture to the professionals? Is this the “hammer” effect?
Almost 10 years ago, Jim Coplien, the author of book “Lean Software Architecture”, gave an overview of architecture’s role in the Lean and Agile movements. He reasonably said that “Software Architecture was often neglected in the early years of the agile movement. However in recent years most developers have learnt to appreciate its importance.“ Well, up to 2019, the practice shows that most developers still don’t “learnt to appreciate its [Architecture] importance.“ They still believe that business requirements given to them come out of the blue and written in stone, they believe a perfect implementation is more important than the reason for the implementation and they can build one task after another having no care about integrity of these tasks. It appears they never heard “there is surely nothing quite so useless as doing with great efficiency what should not be done at all”, said by famous Peter Drucker.
Let me articulate why I have turned to this topic now, not 10 years ago. From the time of Web Bubble, Information Technology on-boarded a marketing acumen and started to name new technologies and methods by sound words that either describe the things in the wrong way or name them by unrelated terms. This does not help IT specialists who do not know the context of those naming, i.e. abstruse names not only disrupt, but also cause a harm.
IMHO, the Words Matter!
Making marketing instead of meaningful names, IT confuses people – one day many comes and take the name literally and destroy IT reputation, at least. There are a lot of examples known – “Enterprise Architecture” that is not an architecture but an architectural practice with limited scope within IT only, not enterprise-wide; “Web Services” that are not about services and not necessary about Web; “Lean/Agile Architecture” that is not an architecture but a method of thinking and acting (as you read above); “data integration” that is just a mapping between business interpretations of values (that being numbers cannot be integrated), and so forth.
Because of wrong words, the majority of developers and even architects cannot distinguish between Architecture, architectural practice and implementation of the Architectural Solutions. When developers in Scrum Teams, who believe they make architectural decisions, are told that they are not even close to Architecture, that the Architectural Solution and decisions were made long time before Agile/Lean Teams were involved at all, they get upset and even angry. What/who is in fault of this? – The Agile Manifesto and Agile methodology (including Lean) are. They use hype to increase ambitions and motivate people to become someone else instead of becoming a professional at in what they do. Recently, some clarity’s come from DevOps because they had to face the real world of organisation of development and deployment requirements set by Architects in line with the business policies.
Mr Coplien, instead of answering his own question “What is lean software architecture?”, said: “Lean architecture comes from applying the principles of the Toyota Production System to software architecture.” Great! A famous American couple of “smart” entrepreneurs took ideas of fully regulated and up-front specified production style of manufacturing and applied them to non-regulated, non-specified and even non fully predicted software development. Why industry got in this obvious trap? – Because Lean SW development method was accompanied by 1) marketing hubbub; 2) weakness of SW development management; 3) SW development isolation in the company and irresponsibility to the corporate (not stakeholder) well-being; 4) because it is ‘cool’ doing something new regardless of its applicability; 5) because that time the market moved slowly and caused harm was not that visible to many.
Mr Coplien continued, ““Lean” means to get rid of waste (like unnecessary documentation), inconsistency (like mismatched interfaces), and irregularity spaced development work in production. Lean understands that you do deliberate analysis and planning before going into production, using techniques like set-based design that explore every viable alternative. The word “Lean” applies to both the assembly line and to the car being built, but also describes the processes behind them. Lean is both about the thing and the process, reminiscent of what good generative patterns are.” Thank you, Mr Coplien, you have explained the constrains of Lean principles and practice, but forgotten to explain where SW development would get “every viable alternative” (which is in essence an anti-Agile) and that “the assembly line and … the car being built, but also … the processes behind them” were documented in Toyota by the last bolt and part movement in the conveyer. In the SW development, the outcome is only assumed even by the stakeholders. Did anyone looked into the context of SW development before jumping in “the whole” like Alisa did or this was considered as not-development business?
Finally, “Lean architecture is both about an architecture with no fat, and about the consistency and reduction of waste in the process surrounding its creation and use.” Well said! However, if you look at the contemporary technology landscape and try to apply this statement, it will dramatically fail. Why so? – Because Lean has proved itself only in particular stable context (ask Toyota if you do not believe me). When the dynamics of the context have significantly changed in many industries, Lean has lost its value and became contra-productive (including imaginary “Lean Architecture”).
An ancient wisdom states, “there is nothing new under the Moon” – back to 2012, OASIS RM and RAF for SOA standards were published, but only now the majority of developers, architects and managers started to follow them and admit that everything they do and develop are services. Why this happened only now? – Because business started to capitalise on the information and communication revolution and the only means that can help the industry to survive in the informed market are services. Nowadays we have markets of services, service-based capabilities comprising own and other’s services, and so force.
An acceleration of market changes and emerging global Service Ecosystem are the killers to the Lean mindset – dynamic market requires an architecture with enough of ‘fat’ to change as needed.
Ask any business or technology Architect how long they would remain in the modern market if they allow “an architecture with no fat”? The common answer will be “A couple of weeks, until the next change takes place”. Another question – who will invest in the products with “a couple of weeks” life-time? My answer is… ‘nobody’.
Well, what is going on? – Well, an acceleration of market changes requires business responsiveness and solution flexibility. An adoption of a today market change should be not only for minimal cost and time to market, but also should have enough ‘fat’ to adopt another change of what was just changed and, also, with minimal cost and time to market. This second change might be required quite soon – tomorrow or in a week, literally. Thus, a fat-less Lean is good for stable, predictable in details and pre-specified business tasks; for the dynamic and (sometimes) unknown tomorrow environment, Lean is useless, if not suicidal.
Here is real world example. A Scrum Team is tasked with an implementation of a new system via services – API and Microservices. The Team decides to use technology that adhere to the Lean practice – Java Spring Framework. The Lean approach dictates two implementation designs: a) the API or Microservice interface should precisely reflect the requested function/feature; and b) interactions with data sources for each service should be optimised and minimised. Therefore, the Team decides to build fine-grained RESTful interfaces and use Spring injections of data source connections into each object used for the service implementation. The system worked well… until the business was needed to adopt a new regulation in a couple of months. The architects of the system promised a quick modification because that system was service-based, i.e. the modification was supposed to be addressed via re-composition of existing services. However, it did not happen. The Scrum Team failed to fit in the time-frame working 10-12 hours a day: developers could not reuse fine-grained services without interface changes (flexibility required some extras and was considered a waste in initial development) and data directly linked to the service objects made re-composition of the services impossible because new interdependencies between objects. This disaster was attributed to violation of Principles of Service Orientation by the Lean-driven implementation.
The practice of Service Oriented Architecture clearly states that business services must mimic behaviour of business entities to serve business needs, which requires flexibility provided by a) coarse-grained interfaces and service body; and b) the service should be decupled from the data sources to participate easily in as many re-compositions as needed. The coarse-graining of the service interface should deliver as much ‘fat’ as needed for the potential (and now to be expected) context change. Service developers should think about future (unknown) compositions where the waste in today point of view can become a treasure for tomorrow solution.
My overall conclusion is that “Lean Architecture” is a fake (it is not an architecture) and Lean methodology is inadequate to the highly dynamic environment where non-manufacturing companies have to operate now. Retire Lean in IT and go forward, or worship Lean and get unemployed.
One of my major architectural principles is “Define Architecture flexible and get market competitive advantage”. Here, let me provide some review of the “Lean Architecture principles”:
1. “Travel light” – my take: travel as loaded as needed; this depends on the execution context, not on worshipping the method.
2. “All Hands on Deck early on” – my take: use only those hands that are professional and necessary for the task in hands.
3. “Just in time, just enough” – my take: think today about tomorrow and reserve today enough for your journey to meet tomorrow needs.
4. “Iterative Architecture Development” – my take: architectural solutions (architectural development) is always E2E, but includes necessary abstraction. An idea of iterative architecture development reminds me an old anecdote: a pilot-trainee learns how to flight by reading a magazine. When in the air with the last issue, she reads the article ending with ”… now turn the plane in a peak. To be continued in the next issue”.
5. “Architecture Initiated by Business Goals” – architecture is initiated by the system. Business Goals initiate only design of Architectural Solutions
6. “Focus on the Value Stream” – my take: focus on the goals and objectives, and only then on the value chains or streams. Each created or to be created value must be challenged against goals and objectives; no match – not included.
7. “Architecture emerging from Projects” – my take: this is a the developer’s hallucination or a Christmas wish. Architecture goes only top-bottom. If Architectural Solutions are weak and emerge from projects/development, the company heads to serious troubles (blind movement).
8. “Freedom where possible, standardize where needed” – my take: freedom for implementation within the constraints of Architectural Solutions and use of standards where justified.