Lean management practices have been applied in recent years to virtually all business functions and processes, including of course Lean Integration. IT architecture is no exception. But what exactly does a Lean Architecture look like and how could you measure its “leanness”? Since there is no generally accepted definition lean architecture, and since I won’t bore you with mine, it might be easier to describe what a non-lean architecture looks like. Or to ask it differently, what are some non-lean approaches to architecture?
The first approach that comes to mind is architecture by exception. This is where you only solve part of the problem by defining the problem scope very narrowly. For example, to address the need to get sales data into the data warehouse, you could say that you ONLY need sales data and proceed to architect a solution that meets that specific need; in other words you treat it as an exception that is not related to other data integration needs. The end result of this approach is well known – the integration hairball – which is filled with waste and inefficiency. So the first characteristic of a lean architecture is that it must be holistic.
A second non-lean approach is architecture by PowerPoint. This is where the focus of architecture activities is to produce nice-looking architecture artifacts like Visio models and standards documents. Don’t get me wrong – models and standards are extremely useful tools, but if they are static snapshots that are custom crafted by individuals which soon collect dust on a shelf. Architectures are dynamic and evolving, so they need to be represented as structured data in metadata or EA repositories with appropriate role-based user interfaces to allow different stakeholders to see the view that is relevant. The second characteristic of a lean architecture therefore is automation of architecture artifact rendering.
A third approach is architecture by committee. Consensus and collective intelligence of a group of people can be good, but it can also result in groupthink which Wikipedia defines as “The mode of thinking that happens when the desire for harmony in a decision-making group overrides a realistic appraisal of alternatives. Group members try to minimize conflict and reach a consensus decision without critical evaluation of alternative ideas or viewpoints.” The result of consensus is often an overly complex solution that satisfies everyone’s interests, but as a result ends up being a heavy-weight solution that performs poorly, is expensive to maintain and contains functionality that is never used. The third characteristic of lean architecture therefore is simplicity – generally developed by only one architect. In the world of lean this roles is satisfied by the Chief Engineer which brings together technical, functional, business and operational skills into one person. These people are hard to find, but not impossible once you start looking.
A fourth approach is architecture by tribal knowledge. Basically, this is where teachings in the form of anecdotes, personal experiences and rules of thumb are handed down to junior staff from experienced architects. This is useful in part, but it is not systematic and repeatable and therefore two architects can easily end up with totally different architectures because their personal experiences (tribal knowledge) are different. The fourth characteristic of a lean architecture therefore is the use of systematic (scientific, data-based) methods such as Design Structure Matrix which results in a mutually exclusive and comprehensive collection of architecture components which represent the whole enterprise.
All of these (and other) non-lean approaches to architecture end up creating a huge amount of waste – software functions that aren’t used, tables with no transactions, reports that no one reads and data that is stale and not adding any value. All this waste clogs up application systems, servers and networks; consumes IT budgets; distracts management and staff; and acts as a drag on transforming the business to remain competitive over time.
Informatica may not have ALL the IT architecture answers, but when it comes to enterprise information management, the company is a global leader and has a collection of industry best practices. Read more at Informatica Best Practices. Or if you want to learn more in person, why not attend Informatica World in May 2012 www.informaticaworld.com.
 Described by Carliss Y. Baldwin and Kim B. Clark in Design Rules: The Power of Modularity, Massachusetts Institute of Technology, 2000