Lean Architecture Principle #11: Freedom where possible, standardize where needed

This is the eleventh and last post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The eleventh principle we discuss is called "Freedom where possible, standardize where needed".
Out of fear to lose control over projects and in an attempt to maintain cohesion on IT systems , tight controls and thus tight restrictions are often placed on IT projects. These restrictions, or standards and regulations as they are also called, have evolved historically in organizations. Ideally these standards result from best practices and experiences during projects, but often the are based on personal preferences, wishes to gain some experience or other non rational reasons. Updating these standards frequently is left behind resulting in outdated standards which as a result hinder projects in creating the solutions the business needs.
Standards should be only concerned with reducing complexity. Suppose that your team is in the business of enterprise application integration, and your company has tens of dozens of dedicated systems for separate departments to be integrated. Your mission statement could be that this team has to solve all integration problems between all these systems, and thus that you shun no integration problem, however difficult and intricate. In a narrow perspective this would be correct, however in perspective of the larger picture solving every possible integration problem on your way is undesirable. This will result in tens of dozens of dedicated solutions with a nightmare in administration and maintenance as a result. So in this case standardization of both proces and techniques is clearly called for.
Examples of relevant standards in this environment are:

• Use JMS for asynchronous communication.
• Use SAML2, OpenId, or some other open standard for authentication company wide.
• Use one central directory for storing authentication information.
• And so on…

On the other hand, continuing in the field of enterprise application integration, suppose the standards and regulations in your company dictate the use of web services using the WS- stack. A lot has been written on the pro’s and con’s of the WS- stack in comparison to REST for instance, so this is clearly a case of a disputable standard. Now suppose you need to solve a publish and subscribe integration problem. In this case using JMS instead of WS- or REST is a viable, and much cleaner and easier way to implement solution. Being limited to the WS- stack in this case is clearly not in the benefit of the business, which should be the most significant factor in the end.
So what are the requirements for good standards ?

• For every standard there should be a clear connection with the business goals. If a standard is not endorsed by the business, then it probably does not help the business reaching their goals.
• Standards should leave room for innovative idea’s. Very tight standards kill creative new idea’s not thought of at the time the standards were devised.
• To get support and endorsement for the standards, these standards should be accompanied by the argumentation behind the standard. This makes the argument on following standards in projects much easier.
• Standards should be continually updated to comply with the current best practices in the field.

The Cohesion of the 3 C’s of architecture is supported by this principle due to the fact that standards are prescribed where needed, thus creating the cohesion between IT solutions where applicable, and limiting complexity. Connection is accomplished by being able to create the solutions the business really needs, within the burden of to constraining standards.
This was the eleventh and last in a series of blog posts on Lean Architecture principles. Next week will show a short summary of the discussed Lean Architecture principles.