Agile Zone is brought to you in partnership with:

Programmer, solution architect, user group and conference organizer, conference speaker and traveling fun code evangelist. Johannes tries to apply Agile principles to large software projects, but what he's really passionate about is sharing the experience of more fun programming with other coders around the world. Johannes is a DZone MVB and is not an employee of DZone and has posted 35 posts at DZone. You can read more from them at their website. View Full User Profile

Lean Architecture

12.04.2013
| 7695 views |
  • submit to reddit

Lean thinking describes seven classical sources of waste:

  • Overproduction: Making stuff that nobody buys
  • Over-processing: Creating stuff that is more fancy than what the customer wants
  • Transport: Moving stuff from one place to another in order to create it or give it to a customer
  • Motion: Expending unneeded effort while creating stuff
  • Defects: Having to redo work because it wasn’t done right the first time
  • Inventory: Storing stuff waiting to be worked on more
  • Waiting: The time stuff is just sitting there, waiting to be worked on

Often an eight is added: Unused talent

It’s always fun (but sometimes risky) to draw analogies with other fields. In an enterprise information application (that is: what most people are working on these days), “stuff” is the data that your application shuffles between users, databases and other systems.

Here are the seven wastes of enterprise information application architecture:

  • Overproduction: Any code that is not executed by an end user. In the extreme case, many applications contain code that is not “reachable” and so can never be executed. In other cases, it may be functionality that is available, but never used
  • Over-processing: Do you really need to scale to a million concurrent users for a company internal application? Do you really need an application that is used get data for monthly reports to have 98% uptime?
  • Transport: How many classes in the code touches a single piece of data before it’s displayed to the user (or stored in the database (or sent to another system)). How many systems does a piece of data touch before it’s done processing?
  • Motion: How many times do you transform data into another representation?
  • Defects: Do you accept data that may be in error? How do you deal with old data that contains errors?
  • Inventory: I don’t know… maybe are you deleting obsolete data?
  • Waiting: Do you have batch processes that run daily? ‘Nuff said

(As an aside about transport. Did you know: In C#, it’s requires substantially less work to save and find data with EntityFramework than it does to call a web service? If system A “helps” system B by provide a data access service, system A is actually causing more work for system B. It’s not just an investment with low ROI, it’s got negative ROI!)

Remember: Not all production is overproduction and not all transport is wasted transport. But much is.

Published at DZone with permission of Johannes Brodwall, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Oleksandr Alesinskyy replied on Wed, 2013/12/11 - 5:45am

The most dangerous waste ever created is the "Lean Architecture".

Robert Brown replied on Wed, 2013/12/11 - 12:19pm

I think there are some corollaries here that some people use by taking Agile and lean thinking to extremes that can cause a lot of defects. 

  • Overproduction - Underproduction:  Not taking known requirements into account when developing a system.  Example: Strapping a multi tenant architecture onto a single tenant system because marketing needed the "Prototype" now so you didn't have time to produce the multi tenant security and data structures when you started prototyping, and as we all know "Prototype" means "Production" in far too many cases. "We don't need it right now" can be taken too far.  
  • Over-processing - Under-processing: We know the system will need to eventually need to handle millions of transactions, but instead of designing the system to support it we build it with the idea that we can just "throw hardware" at it when when the time comes.  Then when the time comes, throwing hardware at it doesn't actually work.  
  • Transport - Monolith: "Well it's just easier to put the sql in the JSP page."
  • Motion - Comprehension: "Just pass the recordset/array/hashmap/request around, everyone will know what is supposed to be in it."
  • Defects: Many times caused by the anti patterns above. 
As with most things it's a balancing act, defining how much is too much takes experience and discipline in both directions. 


Johannes Brodwall replied on Fri, 2013/12/13 - 5:13am in response to: Robert Brown

Love your list, Robert!

Balance is essential especially when it comes to architecture.

Would it be okay with you if I wrote a follow up about "balanced architecture" where I steal your points?

Robert Brown replied on Fri, 2013/12/13 - 9:44am in response to: Johannes Brodwall

Absolutely, Johannes, 

All too often I hear people looking for absolutes, and using buzzwords to justify those absolutes, "Lean means no architecture", "Waterfall means no deviation from the original design", "Agile means no planning" etc. 

Balance is best in all things.  

Thanks

Bob


Raging Infernoz replied on Sun, 2013/12/15 - 1:37pm in response to: Oleksandr Alesinskyy

 Agreed too "Lean Engineering" can lead to:

  • Too little time spent designing data structures, including databases, so stupid latent sticky bugs.
  • Very dated and unsafe coding practices.
  • No separate and properly designed configuration.
  • No proper logging, and grossly inadequate amounts of logging.
  • Inadequate early error trapping, so leaking errors e.g. NullPointerExceptions.
  • Inadequate, NIH, too simple buggy processing.
  • Poor compartmentalisation of code, so impossible to test in isolation as-is.
  • Too much monolithic code, because it was rushed and not refactored.

I saw and had to spend loads of time fixing the above in a business critical piece of software, and so have a rather low opinion of the so-called experienced contractor who hacked it together, and of the old management who asked for and allowed this!

Robert Brown replied on Sun, 2013/12/15 - 6:04pm in response to: Raging Infernoz

Agreed Raging, 

Lean Engineering/Just In Time engineering etc is often used as an excuse for these issues.  The real problem is that there are a lot of developers out there who want to solve problems.  (I know that sounds like a good thing but hear me out).  People who are too excited about solving problems will invariably want to get to the problem and then get it solved, things like architecture, logging, testing, coding practices, etc, are all distractions from the "Solving the problem".  I don't know how many times I've heard "We can Just .... " when mgmt has a problem.  Then devs and mgmt trot out these buzzwords like Lean and Agile and Continuous Integration.  And they use these words to justify their actions.
So "Lean" becomes "No" architecture,  (if Lean is Good NONE is better)
Agile becomes "Wing it as we go"  (How much more agile is it than to hack the production code on the server as it's running). 
and Continuous Integration means "Throw it out there and let the end users test it"  (It's Continuous right so as soon as the issue is discovered by the end user we can put out a fix continuously). 

And these are used to justify the issues you identified above.  Even though all of those things are STRINGENTLY defined in Agile and Lean and Continuous Integration mechanisms.  
You can't do Agile without unit testing Period.  You also can't do Agile without coding standards and a defined paradigm or you will wind up not being able to be Agile because everything is too brittle.
You can't do Lean without a strict adherence to standards of coding, and configuration so that when you need to add the next piece of architecture in you can get at it quickly and easily and in the same way as everyone else.  Oh and Unit Testing of course.  

You can't do Continuous Integration without Unit Testing PERIOD Exclamation Point.  Oh and you can't do Continuous Integration without well defined coding standards and paradigms and practices, because that checkin that Bob did last night just before he went to Alaska for 2 weeks just broke and now Deb needs to fix it.  So if Bob didn't follow the strict rules, Deb is going to struggle to fix the issue and meanwhile the end user is feeling the Pain. 

These are things that are baked into the definition of each of these items, yet they are also the items that are most often thrown out and then the buzzword gets used to justify it.  

Again Balance is key.  

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.