Adopting the 3 systems of engagement/transaction/perception layers and going for integration of the whole landscape via a platform as a service approach is a first important step. But it will be worth nothing if not combined with the ability to deliver changes fast. But fast deliveries are risky. The solution to this dilemma has been pioneered before, with overwhelming success, by the manufacturing sector:
Combing speed of delivery, quality and productivity is a very hard task indeed. How the hell to do that all at once? Well, manufacturing has done exactly that, starting 60 years ago in the 1950’s.
Japan buys the world! A story of manufacturing
In the 1950 to well into the 1980’s the manufacturing sector had been undergoing a major revolution. Japanese manufacturers like Sony and Toyota out-engineering their american and european rivals with unprecedented levels of quality and productivity. Coming out of nowhere in terms of Market share, they outcompeted every competitor in the market, bought iconic hollywood studios, Manhattan sky scrappers and plunged Detroit automotive giants is a crisis they have not recovered from to this day. There was a feeling that Japan could buy the whole US.
At the peak of the real estate bubble in the late 1980s, the 1.32 square mile of Imperial Palace grounds in the center of Tokyo was said to be worth more than all the real estate in California. (CNBC, 2015)
One, arguably the key element of Japanese success was the superior manufacturing process. This became apparent to industry leaders in the 1960’s. And so they went to copy the manufacturing process, installing Total Quality Management, Kaizen and Kanban practices, with very little success. It took them 20 years to learn that the real problem to create the superior outcomes of Japanese Manufacturers is not at the process level, but at the cultural, leadership and value level. Speed, Quality and Productivity must be woven into the fabric of all enterprise layers of an manufacturing organization: Process, Organization and People to get a Culture where quality is engineered into the process.
Now, 60 years later we are facing the same challenge in IT: How to revolutionize speed, quality and productivity to new levels all at the same time? The answer comes from the start-up realm – Lean Development. Started by Erik Ries with the hugly successful book “The Lean Startup” there is a whole series of follow-up works and a global movement within the software and even the business communities reworking existing enterprise structures, not only IT, along this model.
The model originated in the start-up scene, but is applicable to traditional companies seeking a way out of the slow response times and low levels of quality of their IT operations.
Silicon valley is buying the world! A story of software engineering
Todays scare is the might of silicon valley (and China), not Japan anymore. Look at the market valuations vs. traditional companies. Today, November 2015, Amazon, 20 years of age, is worth more then 4 times as Daimler, 130 years of age.
A reason for silicon valleys success is the speed and quality of delivery of software solutions. Within the month of May 2011 Amazon deployed 1079 changes to production systems within an hour (see Humble/Molesky/O’Reilly, p.155). An unheard of number for a traditional company that struggles to bring out even a major release upgrade every few month. This number is even more surprising, as Amazons environments are strongly regulated according to the Sarbanes Oxley act.
Without these revolutionary new ability to deliver changes continuously at high quality all silicon valleys business models would not have been able to be so successful so fast, as a lack of stability and a lack of experimentation would have slowed down their progress massively.
Silicon valley has out-engineered traditional companies in software engineering – just like Toyota, Sony et al did out-engineer their american and european competitors in the 1980’s in manufacturing. About time companies pick up and start implementing these winning IT practices in their organizations.
Continuous delivery is the ability of an organization to work and deploy changes in small batches, deployed continually. This is no big deal, given the changes are small and insignificant, e.g. change a text description, move a field in an user interface. But it is a huge deal for complex changes, with huge interdependencies, e.g.structural changes to master data, reworked business processes featuring changes to document flow. Because of all these interdependencies, these changes need to be deployed at the same time, creating a lot of risks in the deployment and a lot of delays, all contributing to the aforementioned “cycle of stuttered innovation“.
The art of continual delivery is to break down even major changes with lots of interdependencies into small workable bits. This won’t happen by “thinking harder” to break down relationships. However hard architects will think, there will always be relationships that dictate changes to be deployed together. But there is a way out: Agility must be engineered into the system landscape:
- If the software platform is specifically engineered to reduce the number of dependencies, with small, more independent software functions coupled via SOA approaches, continual change flow will be increased
- If changes occur mostly in the systems of engagement layer and system of perception layer, which is much less riddled with interdependencies, continual change flow will be increased. There will still be the odd major, dis-continual upgrade of the system of transaction layer, but it will no longer be the bottle neck slowing down all changes
But this is not enough. Many more changes are needed to organization, processes, Tools and even IT philosophy:
Continuous delivery is huge subject in itself. For those seeking further insights have a look at Humble/ Farley Continuous Delivery, 2010. At continuousdelivery.com you will find some beautiful illustrations by Nhan Ngo that provide a summary:
The change needed to implement continuous delivery is tremendous, costly and time intensive. But: Skim through the table above – is there anything outrageous or new? Sure, the demand to have production data ready for testing at all time is costly, but hasn’t this always been a requirement simply necessary to do a good job? Every of these points is simply a professionalization of todays IT practices.
It requires investment, time and perseverance to build a professional IT organization. Just like the investments, time and perseverance that have been done to build a performing manufacturing organization in the 1980 to 1990s.
Time to professionalize IT. Not to change is tempting fate.