the 7 wastes of architecture

Preview chapter from the upcoming book Surviving Strategy and Architecture by Michael D. Stark.

Republish of article from thinkingEA.com

The concept of the seven wastes comes from lean thinking. Lean is based on the Toyota Production System (TPS). Lean thinking has provided significant benefit to many people through its impact on manufacturing, service provisioning (including healthcare), and technology development, along with many other industries. Importantly, these people benefits have been to customers, shareholders, and employees; not only can lean thinking provide a win-win, but it is baked into the way it works.

I believe the principles of lean thinking can provide great benefit to architecture, including enterprise architecture, to the extent that it might even save enterprise architecture from itself.

There is nothing so useless as doing efficiently that which should not be done at all. - Peter F. Drucker

There is a long history of how lean evolved and I’m not trying to explain the history and all the key players here, other than to say that a key moment in the lean journey was the release of the book Lean Thinking by James P. Womack and Daniel T. Jones in 1996. The earlier book The Machine That Changed the World, is another key moment, and was written by the same two authors, along with Daniel Roos, all of which were conducting research at MIT. Other influential players in the lean world include Jeffrey Liker and Mike Rother, but there are many others. Also, I always enjoy the real-world lean thinking CEO lessons from Art Byrne, as in the end lean thinking is something you do, not just something you think.

The core idea of lean has been summarised as maximize value to the customer while minimizing waste. It is said that lean thinking changes the focus from optimizing separate technologies, assets, and vertical departments to optimizing the flow of products and services through entire value streams.

Lean does relate to the more widely known agile practices, however I’d agree with people that say agile is a subset of lean. Exactly where lean demarcates with systems thinking, human centred design, product thinking, and other contemporary approaches are topics outside the focus of this book (Surviving Strategy and Architecture ), but it is true that many of these things tend to hang-out together.

the lean process and waste

The overall process described in the book Lean Thinking is 1) identify value, 2) map the value stream, 3) create flow, 4) establish pull, and 5) seek perfection. All the time you go through this process there is a key focus on minimising waste. There is a whole lot involved in unpacking this process and I’d encourage people to explore the many great books, videos, podcasts, and training sessions on lean thinking. The key callout I’d make is that lean is principles based, not process based. It is called lean thinking because lean is more than anything a way of thinking and acting. There is probably more than an accidental relationship between my love of the concepts [explored elsewhere on this site], and my love of lean thinking; these ways of thinking do seem to overlap.

You don’t have to do lean perfectly to get value, and if you are doing it perfectly then you just don’t understand lean thinking. There is value in simply understanding the concepts, taking action, observing, and refining in cycles; you could argue that in the end that is all there is to do.

For this chapter the wastes are key for us. Lean came from manufacturing where there are seven wastes of manufacturing defined, which are: over production, inventory, waiting, over processing, transport, defects, and motion. These seem very logical, and it is a bit easier to measure when you are dealing with real physical items being manufactured. These wastes are somewhat generic outside manufacturing; however, tweaks tend to get made for different industry types.

There have been seven wastes of software development defined, but I’m not sure who originally defined these, and there are slight variations. One of the lists I’ve seen is: task switching, partially done work, motion, waiting, extra processing, extra features, and defects. These seem reasonable, though some might need to be carefully interpreted, particularly extra features, which is a concept that could be exploited by project managers to claim gold-plating.

the value of enterprise architecture and architecture waste

Time waste differs from material waste in that there can be no salvage. The easiest of all wastes and the hardest to correct is the waste of time, because wasted time does not litter the floor like wasted material. - Henry Ford

Technology architecture, and particularly enterprise architecture (EA), has long been questioned about its real value to the business. I’ve presented at EA conferences, participated in and moderated discussion panels, and of course have attended many other conferences. What I noticed is that many of the presentation at these conferences are about what EA even is, and what is the value of it. Surprisingly after all these years we are still trying to justify, and even defined, ourselves.

For me the central charge, which I’d observe as being a fair question, is that we spend way too much time navel-gazing and thinking about EA, and not enough time actually adding value. I’ve long believed that lean thinking is a great countermeasure to help EA to become discipline enough to realise its value. Focusing on the many rabbit holes we are tempted down, recognising them as forms of waste from the viewpoint of the business, and minimizing this waste, would be very useful.

the (top) seven wastes of architecture

Below is an initial list of the top seven wastes of architecture. Are these irrefutably the top seven, well that can always be debated, but I think this is a good place to start.

Unclear purpose Performing architectural thinking without having a clear business purpose for that thinking. Generally, architectural thinking, at least when it is on-the-clock (paid for by the company), ought to be clearly aligned to business purposes and outcomes, which might be indirectly aligned, providing this is still reasonably justifiable as beneficial to the business.

At times it might be appropriate to have some focus on professional development or architectural community uplift, for example presenting at an architectural conference under the company’s name, benefiting both the company reputation and wider architectural community.

However, the vast majority of activity must clearly align to business purposes and outcomes.

Over production As with manufacturing, over production is where something is produced and there is no business defined need. For architecture a common occurrence of this is the production of target state architectures, roadmaps and strategies where there is no business request or identified funding pathway.

We need to carefully consider when to enact the removal of this waste as we do want some premeditated high-level thinking in some areas, particularly where we see that there is strategic alignment and we want to get ahead of the business request, or where we want to try to build the narrative and desire for the roadmap as we strongly see a benefit to the company.

It is all about finding the right balance of being reactive verses being disconnected from the actual business appetite, and this will be different by company, industry, and factors like economic cycles.

Over processing As with manufacturing, performing more processing work on architectures than is needed to get to the next decision point or handover point.

As always context matters, and the level of work needed for an enterprise architect, domain architect, solution architect or other, will be different depending on the business, the skill of individuals, their interest level, and other factors. Funding can have an impact, for example I’ve worked in teams where enterprise architects didn’t recharge but solution architects had to, and therefore project managers were greatly incentivised to try and get the enterprise architects to go into as much detail as possible. We need to be very careful about how we manage these situations.

I always advocate applying what I call a dead-cat test. We don’t want to throw a dead-cat over the fence hoping it magically pops back into life on the other side. We ought to do enough that it can reasonably be used to make the required decision and be taken forward with the next level of detailed solution or design work, based on the full context of the initiative and the team’s skills.

Reprocessing Unnecessary reworking of architectures. This might be because appropriate patterns have not been defined or used, therefore we create another architecture which really could have just been pattern reuse. This could also be where there has been a handoff to the next architect and they cannot, or do not, pick up from where the architecture has evolved to, and there is no contextual change necessitating rework.

Architecture is not deterministic, so different architects can legitimately come up with different solutions, and this is not a problem. It can be very hard to pick up someone’s work and continue from there. We just need to try to minimise the rework.

Task switching and partially done work Combining two closely related wastes from software development, the amount of task switching, which often strongly correlates to partially done work.

Given the nature of architecture, and particularly enterprise and domain architecture, there is inherently a need to be across many programs, projects, and initiatives, as well as supporting business case development, root cause analysis, strategic planning, investment slates development and more. ?We must be available for many stakeholders, and so we will have many spinning plates.

But we do need to be mindful of how much work we have in progress. Managing the other wastes will help with this one. We need to focus on creating efficient flow in our work.

Waiting As with manufacturing and software development. Waiting time is almost always a key waste, and a key metric to measure to improve flow. The degree of wait time will often be related to interdependences.

Architects are often a bottle neck, either in reality, or at least perception. Architects both cause others to wait and have to wait for others. Having an architecture principle to move decisions as close to the real place of work as practical will greatly help to reduce this bottleneck, and in both directions. Effectively this is one of the key benefits of microservice architecture – technology operating model decoupling.

Re-litigation of decisions Unnecessarily revisiting decisions where there has not been significant new information, or a significant context change.

We need to ensure we have the right architectural governance, including responsibility and accountability, so we can make good decisions first time, and then commit to those decisions acknowledging that we won’t always get it right. We need to have lightweight documentation of when and where the decision was made, by whom, and the basic rationale. Generally, we should avoid decision by committee, and have a small number of responsible decision makers, but they ought to consult wider.

Revisiting decisions if there is new information makes sense, but only if there is new information or a context change. If we must revisit the decision because we just got it wrong, then we need to use it as a learning opportunity and apply continuous improvement to get better.

How to start

The idea of lean is not necessarily to eliminate all wastes, as that just never happens, but we should continually look to bring in countermeasures to reduce these wastes. It needs to be continual improvement because conditions change and new wastes creep in.

The top 7 architectural wastes for your specific situation may well be different depending on the type of company you are in, the architectural operating model (centralised, decentralised, federated), your maturity level, the mix of personalities you have, and many other factors. Lean thinking ought not be prescriptive. There is no magic formular that just works. It is a way of thinking and improving. The countermeasures you need depend on your specific situation at that specific time.

The key is to start where you are and reduce waste and friction in the architectural process. Be diligent about focusing on business value.

A chapter doesn’t really do this topic justice. One day I might expand this out to a book of its own, but for now I’ll stop here; just cracking the door open a little and giving you a tantalising peak. But be curious. Keep your beginner’s mind.

We improve by 1% every day. In just 70 days, you’re twice as good.?- Alan Weiss