True? "Companies shouldn't apply digital transformations with a strict technologic focus”. Yes!
Lagging development processes hindering to swiftly adapt to the rapidly changing market, often bring the desire to start transformations. Boosting business flexibility is, however, something which should be done on a strategic and personal level. This means that a digital transformation in which a large part of the technology is re-engineered, should have the main focus in recovering and preventing the imbalances, which originally caused the need of this rebuild.
"In many companies, business and IT processes work
on a strict trust basis."
The business doesn't understand the actual process of software development but trusts IT support its goals. The development process trusts that the business will stay reasonable in its requirements, but generally isn’t in touch with the business’ concerns. This alignment on basis of trust, instead of understanding, works as long as both parts within the organization deliver reasonable performance. Without understanding or without common language in communication, the distance between these planes will only become apparent when the agility of either part start lacking; putting collaboration to a standstill when either IT or the business starts to feel serious limitations in their execution.
Liquidity
As described in my previous post Swimming with the faster fish - Part 1”, today’s battles are fought on an user-experience level to createcustomers-first strategies. While disruptive at first,“the Faster Fish’” customer experiences are becoming the default in customers’ expectations. The decision of 
changing your proposition to outclass these experiences is made in an instant. It is, however, the speed and cost of implementation which challenges the route to change.
The agility to make changes on a business level organizes around talent and financial capacity. With the right people, new business propositions can be sought out and supported in its financial needs. If the liquidity of a company starts lacking, the business will not longer be able to support its
processes. To survive, the business has to either bring down the burn rate or is forced to pivot in new market positions. On an IT-strategy level, talent manages the quality of solutions. The agility of the development process is, however, also bound to the ability of the underlying architecture to conform to the - potentially fast-changing - business' needs.
Putting pressure on the delivery of functionality without an investment in the quality and agility of the solution, results in the loss of technical liquidity; a technical debt inhibiting the business in taking swift and crucial actions while adapting to their environment.
Melvin Conway stated that organizations build software which: “Will follow a design whose structure is a copy of the organizations communication structure.”. When you only see your IT organization as a mere supplier and burden towards your needs; software will never be built as something resembling or an acceleration to your goals. Debt accumulated in years of building software without the freedom of autonomy and a strategy on a technical level will also prove the dual of this law: complex and rigid software architecture will prohibit you in increasing much-desired flexibility and agility.
Technical Profit
Confronted with the consequences of not making the correct checks and balances to improve quality and flexibility over functionality during the development process, full transformations on a technical level are often seen as the only resort. Instead of reinventing a company on a technical level every so many years, a strategic transformation should also embed the cultural change to understand technical debt and to transform it into technical profit.
A collaboration between business and IT during a transformation, embedding quality, agility and autonomy as top priorities in a business strategy will make the management of technical liquidity a company-wide responsibility. This action no only protects future product viability and financial profit on business level, it will also ensure that the benefit-cost ratio of your IT organisation will increase over time.
Such a disruption in values should, however, not only be applied on a process level. These values should fall through towards the actual design of the software architecture. Following Conway; true agility and autonomy in teams can only be achieved when the system is designed following the same traits. Aligning your business, development processes and actual codebase towards the same goals of increased flexibility during the complete life-cycle requires an investment, but will eventually empower your company with the same level of flexibility as your disrupting competitors.
