Best Practices – Enterprise Transformation Circle

FIDA Architecture Patterns

EnTranCe Community — Tue, 01 Jul 2025 11:38:20 +0000

Overview

The FIDA architecture …

Leadership Triangle In Action

EnTranCe Community — Tue, 01 Jul 2025 11:37:43 +0000

Introduction

The Leadership Triangle …

Scaled Agility – The Path to Enterprise Adaptability means Verticalizing Your Architecture!

Matthias Besch — Tue, 24 Sep 2024 05:46:59 +0000

Does your organization want to increase the adaptability of an existing business model and reduce the time to market of the associated products?

However, do you face the challenges that come along with a (historically) grown, monolithic application landscape? This is the ideal scenario when agile approaches can add value – by definition. However, many agile solutions just describe a simple “greenfield” approach. Such an approach is applicable to the development of a genuinely new business model. What about the much more complicated case of an existing one, where planning and managing the transition becomes the main challenge?

A flexible and decoupled business and system architecture is the basis for building an efficient agile organisation (see Scaled Agile at Work: Efficient Team Orchestration). A decoupled system architecture enables teams to work technologically independently of each other. Decentralised business processes give teams the necessary decision-making authority to organise themselves. Hence, a promising approach must take both into account.

We provide you with an approach how to successfully transition from an inflexible monolithic to a vertical slice architecture which is flexible, decoupled and therefore enables business agility on enterprise level. To illustrate a real-life scenario, we will use a fictious case study and our practical experience from various transformation projects.

What are Monolithic and Vertical Slice Architectures?

Before going into the details of the case study we would like to briefly define what a monolithic and what a vertical slide architecture mean.

Monolithic architecture

A monolithic architecture integrates all application components into a single, indivisible unit. Typically, it involves large applications that centrally provide several closely connected functions. This leads to improved performance and simplified development, but less flexibility and higher dependency.

Vertical slice architecture

In a vertical slice architecture, an IT application is divided along business lines rather than technology. This division creates ‘verticals’, each focused on specific business features and use cases, delivering dedicated business value. This results in a strong market focus, flexibility, scalability, and reduced vulnerability to errors. On the other hand, convergence of functions increases, operational overhead rises, monitoring gets more complicated, and troubleshooting during interactions becomes more challenging.

The transition from monolith to verticals includes a significant technological and organizational change. Each vertical slice of business functionality could be further broken down into an independently deployable microservice. The vertical slice architecture further allows for a gradually transition toward a microservice architecture, rather than making such a huge change all at once. Next, we introduce related challenges from the field, along with appropriate solutions, in a simplified fictional case study.

Case study: Retailer transition to enhanced business agility

Fictional online retailer eShop operates in one European country. The entire value stream is represented through a monolithic IT application (see Figure 2).

Its monolithic application landscape faces slow changes due to size and complexity. Customer demands for modern and digital features led to the strategic goal of modernizing the shop. The decision was made to move to agile development to improve customer-centricity and increase time-to-market. A radical verticalization of the architecture shall set the foundation. Challenges include where to start, handling technological complexity, addressing redundant functionality, and managing overarching business logic.

How to start the agile transformation journey?

The approach must ensure business value-based prioritization. The transition strategy must gear towards enhancing customer’s experience and economic impact. A gradual approach is preferred to ensure undisrupted and seamless day-to-day business.

The methodology that supports this is value stream mapping in which the relevant workflow step(s) that deliver the most value are identified.
In our case study the ‘Visit to Order’ step is identified as a crucial point in influencing customer purchasing decisions as it significantly impacts the customer’s perception and likelihood to make a purchase. By improving this step, the company can potentially increase customer satisfaction, sales and overall profitability. The prioritized goal is to make the ‘Visit to Order’ step more flexible, responsive, and economically impactful. This paves the way that eShop can adapt quickly to changing customer needs and stay competitive in the market.

The initial design of the transition architecture focuses on the decoupling of the ‘Visit to Order’ as a vertical solution from the other steps (see figure 3). Starting to ‘agilize’ one step only might be beneficial to learn from experience and improve before scaling. The initial, optimized vertical can serve as a blueprint for how the changes will be implemented and integrated into the existing landscape.

As a first measure, agile teams can be established within the clearly defined scope of the vertical solution. The gradual approach allows iterative learning, faster development, testing, and deployment.

The rest of the value stream will be further supported by the monolith. This ensures that the transition is gradual and does not disrupt the entire business operations at once.

How to manage technological complexity?

The construction and operation of the entire software stack requires high technological competence from the vertical teams.

Since other value stream steps are supported by the monolith, interfaces are required for handover points. The teams will need new development infrastructure for agile development of their solutions. Examples include cloud configuration, monitoring, and testing. Covering all of these disciplines in large IT environments like eShop would be overwhelming for agile teams of 5-11 members, both cognitively and capacity-wise. Additionally, as the remaining steps of the value stream will be progressively implemented by own dedicated vertical teams, similar needs will arise.

Therefore, the transition architecture is further refined:

The layer beneath the value stream is renamed into ‘Customer Facing Solutions’ – these IT solutions directly provide business functionalities.
A ‘common domain’ called ‘Platform Solutions’ is introduced. This domain consolidates solutions that offer IT support for development and operation to teams within the Customer Facing Solution domain. Dedicated teams will be established for this purpose.
To facilitate interactions, the monolith is decoupled through an API layer, termed ‘Modularized Legacy Solutions’. These APIs are developed and maintained by teams consisting of developers from the monolith.

How to address redundant business functionality?

In the ‘Visit to Order’ value stream step, messages such as order confirmations or notifications of item restocking are sent to (potential) customers. Similarly, in later steps, messages like shipping notifications, invoices, and payment reminders are also sent to customers. When dealing with such a cross-vertical business function, there are two approaches:

Independence with redundancy: Each vertical independently manages and develops its business solution. This approach strengthens independence but leads to redundancy and increased coordination needs for ensuring a consistent user experience and compliance. It also necessitates alignment on the underlying data model and business functions across domains.
Centralized business platform solutions: Business-context-specific solutions remain as ‘Customer Facing Solutions’ within the verticals. Business-agnostic solutions are outsourced to a ‘Common Domain’ named ‘Business Platform Solutions’. Templates for these can still be provided by each vertical. This approach slightly limits the independence but reduces redundancies and leverages synergies.

For the case of message dispatch mentioned above, eShop’s architects opt for the second approach. They establish a ‘common domain’ called ‘Contact Management’. For this and other cross-functional business solutions (e.g., reporting), a new domain named ‘Business Platform Solutions’ is introduced similar to the approach for technical cross-functional solutions.

How to handle cross-domain business logic?

At eShop, customers are assigned a ‚Customer Category’ based on their purchasing behaviour and Customer Lifetime Value. This globally defined customer attribute impacts business functionalities across the entire value stream, such as pricing, delivery speed, and payment options.

Such horizontal dependencies, inherent in the business logic, cannot be resolved through verticalization alone but require overarching management.

eShop has decided to introduce a new role, the ‘Value Stream Owner’, responsible for identifying and orchestrating such business dependencies. In collaboration with the architects in the verticals, it is determined how and when, for example, Order Fulfilment knows about the delivery speed appropriate to the customer’s ‘Customer Category’. The corresponding business solutions orchestrate features of the verticals and the ‘Business Platform Solutions’ domain.

To ensure the end-to-end operability of the processes and use case models derived from the value stream, we assign the following activities to the role ‘Value Stream Owner’:

Identification of cross-domain business logic along the end-to-end customer journey,
Definition of steering logic and data for cross-domain business dependencies,
Alignment about an overarching data model and definition of interfaces,
End2end monitoring, e.g. via shipping times per customer service level.

All the measures described above enable the agile transformation of the first step of eShop’s value stream. Insights gained from its implementation would be fed back into the model, facilitating the successive transformation of the remaining steps.

Our approach at a glance

Based on the above outlined challenges and derived solutions, we advise the following approach:

Articulate the rationale. Define the vision and business value of the initiative, and ensure top management is committed to the transformation.
Select a market-oriented value stream. Choose the value stream with the highest urgency for action. If not already identified, start by identifying the value streams.
Identify the optimal step(s) in the value stream. Find the step(s) with a favourable balance between contribution to goal achievement and technical change effort.
Establish solutions:
- Customer Facing Solutions: Specific business defined solutions enabling a particular value stream (step).
- Business Platform Solutions: Generic business solutions used across multiple value stream(s) steps from the Customer Facing Solutions.
- Development Platform Solutions: Cross-functional technical solutions supporting business design and development (LOW- and PRO-Code), verification, validation, and operation in the upper domains.
- Modularized Legacy Solutions: Parts of the monolith provided to other domains, aiding in its gradual decoupling and replacement.
Manage cross-domain business logic. Establish responsibility and capability to ensure the end-to-end operability within the value stream.
Assign solutions to agile teams. Based on the solution categorization and requirements.
Start with the first value stream step(s). In each development iteration, ensure existing functionalities work with new components. Inspect and adapt the architecture and process organization. Scale horizontally, reviewing the upper phases.

Our approach leads to a significant organizational and technical change.

A sustainable implementation requires an invest into technology and, above all, in employee expertise.

The transition itself must be implemented in a separate (agile) initiative with the relevant initiative owner, requirements engineers, architects, etc.

Conclusion

A vertical slice architecture serves as the cornerstone of an agile organization, and it should be carefully planned before initiating any organizational transformation.

To achieve meaningful results without overwhelming the organization, a structured, gradual approach is essential.

Our best practices emphasize transitioning incrementally, dismantling the monolith step by step, and eventually replacing it with a more flexible architecture.

In this blog, we’ve discussed the transition to a vertical slice architecture within the context of an agile transformation, focusing on a single value stream. This approach allows for agile, business-driven innovation, minimizing disruptions while maximizing adaptability.

Moving forward, we will explore how this methodology can be applied to multiple value streams in larger enterprises, further enhancing scalability and operational agility.

Support from top management remains fundamental to the success of such a transformation. Without leadership commitment, the necessary cultural, organizational, and technical shifts cannot be effectively realized.

Scaled Agile at Work: From Agile Leadership to true Self-Organization (we need to talk about money)

Matthias Besch — Fri, 08 Sep 2023 09:00:24 +0000

Agile development of complex software systems for large companies presents us with challenges on many levels: cultural, organizational, financial, infrastructural or architectural. In our blog series, we look at various problems of scaled agility from a holistic company perspective and try to give practical suggestions for optimization.

Business agility, which is the ability of a company to react flexibly and quickly to market requirements while also being able to optimally use the available skills, can only fully develop in interaction with entrepreneurship.

Entrepreneurship, on the other hand, cannot be achieved through agile methods and processes alone, but also needs the stimulus and freedom of financial decision-making authority. A promising way to get there is far-reaching self-organization in combination with shared leadership.

By far-reaching self-organization, we mean not only the sovereignty of cross-functional teams over the way the assigned work is organized, as is usually assumed in scaled-agile frameworks, but also the creation of an entity, its purpose, its dissolution and also their financial sovereignty and budget responsibility.

In this article we look at shared leadership and entrepreneurship in the context of extensive self-organization using the example of metafinanz, which has been successfully practicing this principle for over six years.

But can the findings there also be transferred to the context of scaled agility in large companies and corporations? We show that this works and will decisively change and optimize your agile transformation!

Agile Leadership is a Start

In times of constant, rapid change and disruptive innovations, many companies are looking for a solution to this challenge by switching to agility and agile leadership. Specifications, delegation, knowledge of dominance and control in hierarchical structures become role models, treatment at eye level, error culture, participation, openness to new things, transparency and trust in flat hierarchies. Ideally, inspiration and transformational creativity are added.

But has agility already been achieved at business and corporate level?

The Stunted Agile Dream

If you take a closer look at where (very) large software systems are being developed the agile way, you will often find that despite (or perhaps because of) a literal orientation towards scaled frameworks, optimized “flows”, well-intentioned leadership concepts and exciting, innovative products something is missing.

“We are building an innovative partner platform”.

“Are you agile?”

“Yes. We develop in cross-functional teams and now have our 3rd PI meeting (planning interval) behind us.”

“How’s the financing working?”

“We got a budget.”

“Why?”

“The management really wants to enter this market. “

No clearly formulated and operationally measurable goals, no MVP (minimum viable product) that stakeholders could use to review their investment. None of what is at the core of business agility and what is also referred to as the Lean Startup Cycle due to its similarity to the idea of a startup (e.g., in SAFe: https://scaledagileframework.com/epic/). In other words, the entrepreneurial spirit that is characteristic of business agility is also missing here.

Sometimes scaled-agile software development is also reminiscent of a factory (see figure), in which each and every individual or team purrs efficiently to themselves day in and day out. The (not always) generously granted “innovation and further training phases” do not fundamentally change this. Human creativity doesn’t work that way, needs spontaneity and space as needed. Even real empowerment can look different.

At this point it is worth looking at the agile model of metafinanz.

The Path to Self-Organization

In April 2017, metafinanz transformed into an agile company with far-reaching elements of self-organization. The classic hierarchy and the associated roles, processes and thought models were abolished to make room for a customer-centric model of autonomous, flexible business units and quick decisions (“Value Creation Structure”).

Analogous to the idea of Kotter’s “Dual Operating System” (Kotter, John P. Accelerate: Building Strategic Agility for a Faster-Moving World. Harvard Business Review Press, 2014.), at metafinanz structural and process organization (“formal” and “value-added structure”) separately. Added to this was the emphasis and promotion of the “informal structure” for the diverse use of networks between colleagues and teams (see figure).

The value creation structure consists of shops and business areas. The latter have direct market access and are responsible for the business, while the former take on supporting cross-divisional functions such as HR or marketing. Business areas are founded by employees. They adapt according to the market development, grow or dissolve again. There are currently over 80 business areas.

The decision-making powers of a business area are comprehensive and range from the foundation, definition of its business orientation (purpose), market and customer acquisition, recruiting, participation in training courses or events, investments in research activities to its dissolution. As is usual in companies, coordination with the relevant stakeholders is a matter of course, including with financiers and mentors.

In contrast to the Kotter model (https://scaledagileframework.com/advanced-topic-balancing-the-dual-operating-system/), which is also propagated by SAFe, the governance structure at metafinanz has only three levels (management, staff Development Manager and employees) very lean. In addition to key advisory functions (e.g., compliance) and special advisory functions (e.g. health & wellbeing), disciplinary management and employee welfare obligations are anchored here in particular. However, disciplinary leadership is kept to a minimum and is rarely visible in everyday life. For example, many classic tasks of disciplinary management such as vacation and travel permits, or employee evaluations are no longer required because they are simply not needed at metafinanz.

Shared Leadership in Practice

However, the decisive differences to the “Dual Operating System” model lie in the great dynamics of the business area structures and their very extensive autonomy, as well as the principle of shared (agile) leadership (“Shared Leadership”) in the shops and business areas.

It is not just the sheer number of business areas that is constantly changing, but also their size. As a rule, a business area initially consists of a team of three to five people and can then grow to three or four times the size depending on market requirements. The optimal size depends heavily on the business model of a business area.

There is no business area lead, but that doesn’t mean there is no leadership. This organizes itself, and quite differently, depending on the existing skills, the needs and the culture of the people in the team. And: it is dynamic and can basically develop anew with every change in the team.

This (shared) leadership includes the so-called technical leadership, more precisely all leadership without authority. In addition to classic specialist management such as in the area of software development, strategic business development, sales or agile coaching, this also includes personnel development, for example personal advice and assistance with career development or conflict resolution. This is supported by the Staff Development Management and their more corporate global orientation as required. Last but not least, there is a special role for agreeing on salary adjustments. This process is also carried out in close coordination with the Staff Development Managers. Last but not least, in addition to shared leadership within the business area, further external leadership skills are required: in dealing with other business areas, other organizational units as well as customers and partners.

By the way: how are decisions made in a self-organizing team? To avoid a typical misunderstanding: Decisions in a business area do not have to be made by consensus. Rather, a very pragmatic Laloux procedure has prevailed, in which decisions are made by those who are concerned (Frederic Laloux, Reinventing Organizations, 2015). But it is also true that there are people in the meta, and sometimes old leadership patterns break through. Nevertheless, one observation remains: Compared to conventional, hierarchically structured companies (also of a similar size), the speed with which decisions are made is usually many times faster.

And now about Money

Why has the model worked in practice for years? Attractiveness factors such as management commitment, a high level of empowerment, incredibly short decision-making processes and extensive entrepreneurial freedom for individuals and teams certainly play an important role – also at the price of higher demands on proactive behavior and networking ability. But that is only one side of the coin. The other is financial. Business areas are profit centers that initially receive a start-up loan and are supposed to repay it with a profit.

Of course, that doesn’t always work. There is always a certain entrepreneurial risk involved. It is one of the core tasks of the management to find the right risk mix for the time. If no positive trend emerges for a business area after a defined period, it must consequently be dissolved again. The team members then apply to other business areas or coordinate a new business idea with management, the establishment of a new business area.

Two tools are available to the business areas on their way. First: Complete transparency of all company key figures in almost real time, both those of your own area and all others. Second: regular alignment meetings with various stakeholders including management and pairs from other business areas. These meetings serve to provide mutual orientation and support on strategic issues.

In essence, we are dealing here with the deal “freedom against entrepreneurial commitment”. However, we are not all equally entrepreneurial, not all colleagues use this entrepreneurial model equally.

But that doesn’t have to be the case – as long as each team member contributes to the success of a business area in their own way and can enjoy the advantages of autonomous efficiency. Diverse teams can – and need – that.

How are the cross-sectional tasks financed? Shops are managed as cost centers and financed by the business areas via a percentage fee. The Chinese company Haier, one of the world’s leading manufacturers of white goods and an almost unknown pioneer in self-organizing structures (https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/a-business-of -its-times-haiers-self-evolving-organization), takes a different approach here. There, supporting services must be purchased via specific fees. Both models have advantages and disadvantages, which we cannot go into in detail here.

Transfer to Scaled Agility

If so, what would be the equivalent of a business area in a scaled-agile environment? What would be the smallest unit in which market-relevant innovation happens? Can this be dynamically adapted to the needs? Where can we find entrepreneurial elements pitching and fighting for an idea? Where could credit or advances be made, which can then be turned into successful business by a group of people and teams? The answer may lie in the concept of initiatives (in SAFe: Portfolio Epics) and the Lean Start-up Cycle (see figure above). Here is our suggestion…

Entrepreneurship needs Dynamic Structures

If a big idea condenses into a concrete innovation project or epic, a business case is presented, money is made available for an MVP and further financing depends on the success of a pilot, this corresponds to the process of a start-up or a business area at their Establishing or pursuing a new strategic project. The counterpart in scaled-agile: The “founder” or the “founding team” convinces investors, namely the executive board or higher management, of an idea and its implementation within the framework of an epic.

The staffing now also follows this cycle and relies on the need-based, gradual development of agile resources. In the beginning, small agile teams are often enough to try out an idea and its feasibility. Later, other teams or even ARTs (Agile Release Trains) or tribes can be added along with all the necessary roles such as Business Owner, Product Manager and System Architect. Agile teams can be newly assembled or taken over from existing ARTs or tribes.

Incidentally, innovation does not always have to be disruptive. The above ideas also apply to “everyday” innovation projects.

Let’s look at an example: Brokers want to open up the retail business and realize that the processes are not digitized well enough. The real digital enablement of the brokerage houses is missing. The entire investment would require 15 to 20 million euros. The MVP is around EUR 2 million, should verify the market hypothesis, has clear OKRs. The MVP in the above case, for example, can be implemented very easily with just one team. Only after the pilot has been successfully completed will it be scaled, and additional teams and roles will be added.

Dynamic Business Clusters as Entrepreneurial Units

Based on the metafinanz model, we call this entrepreneurial, self-organized, dynamically adaptable grouping for the implementation of a strategic initiative Dynamic Business Cluster (see figure above). Similar to a business area, dynamic business clusters can grow as needed, but can also be dissolved again if a benefit hypothesis does not materialize or if a solution has reached a high level of product maturity and is to be transferred to regular operation. Clear ownership is required for a dynamic business cluster. The topic must be driven, further developed and represented to investors and other stakeholders. We propose the role “Cluster Representative” (CR) for this. In SAFe you could also expand the tasks of an epic owner. Like all of the roles mentioned, this is an overall and shared leadership model.

In addition to the dynamic business clusters, which in the sense of efficient team topologies mainly consist of “stream-aligned” teams or ARTs or tribes (see also our article: LINK on efficient team structures), we may also need the counterpart to Shops at metafinanz: Supporting Cluster. These can offer common (technical) services (e.g., libraries or APIs) via platform teams (see also our blog article on team topologies and verticalization: LINK) and make them available to their customers, the business clusters. Depending on requirements, supporting clusters can be set up as cost centers (like the shops at metafinanz) or also as profit centers. We need to postpone an in-depth discussion of this topic to a future blog.

Key Take-Aways

Significant advantages of agility such as the ability to react, innovative strength and employee satisfaction are often lost when scaling in large companies because the entrepreneurial doer spirit could not be anchored in the organization. This spirit needs more than “just” empowerment and “agile leadership”, namely entrepreneurial decision-making autonomy and highly adaptable structures that follow the business value. Both are still very difficult for large companies today.

The example of metafinanz shows the potential that can be developed through the model of real self-organization in combination with shared leadership and how inseparably closely self-organization is linked to entrepreneurship and a highly dynamic process organization.

In order to be able to integrate this successful model – in a targeted manner and as required – into scaled-agile structures in large companies, we propose expanding the agile approach to include self-organized dynamic business and supporting clusters. These are based on the process of the lean start-up cycle and can grow dynamically with the respective need or, in the case of unfulfilled benefit hypotheses, shrink again or be dissolved.

A real ability to react to the highly dynamic market environment is crucial for companies. This requires the establishment of a value-driven portfolio, supported by an agile process organization that is dynamic from the basic design.

Of course, large areas (e.g., products, teams) of agile process organization will remain stable in a medium-term perspective. At the same time, a constant focus on market changes and a consequent adjustment of the agile process organization are required.

This focus and this entrepreneurial mindset are at the heart of a real agile organization, and thus real business agility.

Understand Your Past to Create Your Digital Future!

Soeren Kupke — Mon, 24 Apr 2023 07:00:57 +0000

History Matters in Case of Digital Transformation

What does history mean for a company? Simply put, a company is more than the sum of its parts. It consists of capabilities and routines and is the result of decisions and developments that have their origin in the past. Capabilities are extensive, there are certain machines as well as skills of employees or computer systems. Why does history matter in business? 40 years ago, Paul David [1] described the emergence of the QWERTY-standard for keyboards as an example of a “Lock-In” effect and the development of standards. The QWERTY standard is a perfect example for the emergence of dependencies on past decisions and developments in present and future. At a certain point, the QWERTY standard was widely accepted and from this point on every new keyboard hat the same design, the users got used to it and expected exactly this keyboard: A “lock-in” happened. These dependencies exist in entire industries, but also at the company level.

This insight is important, companies usually cannot simply reinvent themselves. There is a dependency on previous developments of the company. This means that the development of companies does not proceed in isolation but along paths: A company follows its path dependency. To sum up, every company has a history, and this legacy is especially important regarding digital transformation.

Digital Transformation is Different

Why is digital transformation different from other changes in a company? Of course, companies must constantly adapt to safeguard competitive advantages. With digital transformation, however, the challenge lies firstly in the breadth and secondly in the speed required for the transformation. Given the high environmental dynamics, it seems no longer possible to adapt a company step by step. For example, product innovations can no longer be separated from process innovations, as both must now be carried out in parallel at the same time and thoroughly coordinated.

Since technology is the foundation and an important part of digital transformation, but follows its own paths, this further increases the complexity of any digital transformation.

Path Dependencies Explained

Path dependencies play an important role in the development of companies, they are the result of previous decisions and built skills. This means that a company rarely or never starts a new development but always builds on existing capabilities, resources, and structures. If these strongly influence the future development, one speaks of path dependence. Path dependencies can have a positive effect, for example if a company can build on capabilities that are also relevant for the future. However, path dependencies can also hinder this development if existing skills stand in the way of necessary change. Path dependencies can become problematic for the development of companies when structural inertia arises. This can result in an inability to adapt to changing competitive conditions and a loss of competitive advantage or market position.

Digital transformation requires a sustainable change in the business model and, unlike other programs, therefore requires a holistic change to be implemented throughout the company.

To understand path dependencies, Jörg Sydow et al. [2] is a good read. In general, the forces behind path dependencies are systemic and cannot be controlled by actors within a company. The most critical event is the described “Lock-In” effect, which could lead to a strategic trap. At this point, a change of that pattern is extremely difficult and cost intense. Such dependencies are very relevant in the case of digital transformation, which must deal with organizational paths as well as technology-based paths. Therefore, a digital transformation seems to be particularly challenging, on the one hand the organization of the company must be adapted but at the same time new technology is often needed. Both organizational development and the use of technology have direct interactions and dependencies.

How Can Leaders Respond to Existing Path Dependencies?

To deal with path dependencies, one needs to understand them. It is the foundation for successful digital transformation. The art is to create a connection between the past, the present and the future. Hence, leaders must not only define a north star, but also facilitate the creation of the path towards them.

Know your history: It is important to accept the legacy of a company and include them in strategic considerations about the future of a company. Rarely does a company have the opportunity and the luxury to start a digital transformation from scratch. This means that leaders must develop a deep understanding of the root-cause for a company’s existing competitive advantage.
Understand technology: Regarding digital transformation, the technological basis of the business model and the understanding of this technology is of particular importance. Therefore, an honest stocktaking must be carried out to develop viable strategies as to whether and how technological renewal needs to take place. Especially with the high involvement of technology, the risk of a “lock-in” is particularly high.
Be flexible: During development and especially the implementation of digital transformation, managers must think dynamically. On the one hand, it is important to have a clear picture of the company’s future competitive advantages, on the other hand, execution and implementation are crucial. It is important to continuously adapt the strategy in iterations to the competitive environment and the progress of adaptation through digital transformation.

In summary, it should be noted that the success of a company’s digital transformation also depends on its history. If leaders understand these and integrate existing capabilities wisely into their planning, transformations will be more successful.

Although the legacy often seems to stand in the way of the future, in many cases companies have competitive advantages that can be used in the future and can even be expanded with the use of technology.

Therein lies the opportunity for digital transformations.

[1] David, P. A. (1985). Clio and the Economics of QWERTY. American Economic Review, 75, 332–337.

[2] Sydow, J., Schreyögg, G., & Koch, J. (2009). Organizational path dependence: {Opening} the black box. Academy of Management Review, 34(4), 689–709.

Scaled Agile at Work: Bring Data Literacy to Enterprise Life

Matthias Besch — Mon, 17 Apr 2023 07:00:03 +0000

Developing complex software systems for large enterprises in a truly agile way presents us with challenges on many levels: cultural, organizational, financial, infrastructural and architectural. In our blog post series, we look at various problems of scaled agility from a holistic company perspective and try to give practical suggestions for improvement.

Data and its intelligent use have always been the basis of decision and knowledge management.

With increasing digitization, data competence has long since become a question of competitive advantage and survival, even for modern agile companies.

One might think that agility and data competence are mutually dependent and mutually supportive. In practice, however, this is not always the case. In other words, there is still room for improvement. Let’s go into some details!

Data, Facts, Humans

Data and its intelligent use are no new inventions. With increasing digitization and the wide availability of AI and Big Data technologies, data literacy has become as important for each of us as reading and writing. And for companies, data literacy has become one of the most crucial factor regarding competition and survival.

If it were that easy! Already in 2009, Erik Brynjolfsson, an economist and director of the Massachusetts Institute of Technology’s Center for Digital Business, stated: “We’re rapidly entering a world where everything can be monitored and measured. But the big problem is going to be the ability of humans to use, analyse and make sense of the data”.[1]

As with optical illusions, we seem to be easily fooled by data, as well. We don’t recognize fake news and artificially generated photos or videos overwhelm us even more. Elections are rigged and before we can unmask the nefarious machinations, the wrong person is already in power. Software solutions such as chatgpt generate scientific papers and blog articles, but without marking the text as “AI-generated” and without citing sources. At second glance and with a little practice, the quality is fortunately (still) far too bad, otherwise this article might have been generated by a machine, as well.

In his book “Factfulness” (2018), Hans Rosling describes a completely different kind of data incompetence, which could perhaps be described as sociological-medial biased. Rosling provides numerous examples of how we ignore or misinterpret statistics on the basis of our very own “instincts” and, thus, time and again are mercilessly wrong when it comes to global political issues, such as poverty, education, population growth and much more.[2]

What does that tell us? We can use big data and AI for data analysis, for decision recommendations, predictions or for text and image generation; In the end, however, what counts are the ethical values and creativity of humans. And what does that mean for companies? How can agile companies in particular use data competence with all its facets and integrate it into their culture and processes? What challenges exist from the point of view of leadership, organization and professional as well as technical competence?

Data Literacy in a Nutshell

Before we turn to data literacy in agile companies, we would like to spend a few sentences on our own definition. Data literacy connects the data to be collected and the problem to be solved. In the end, it is about gaining information from data that is relevant for decisions and actions. Data literacy encompasses both technical skills, such as the use of data analysis tools, and the ability to critically evaluate data from an ethical and other perspectives in a larger context.

In essence, it is irrelevant whether intelligent algorithms and tools are involved in the automated processing of large (unstructured) amounts of data or not. Applying AI to data and hoping that structured knowledge will emerge is simply illusory.

Data processing must be planned, the search space restricted, the right parameters defined, the right questions formulated, a suitable model found or even newly developed. Aspects regarding ethics, sustainability and compliance as well as questions about the quality of data and sources do come into play here. Later, data must be checked, classified, and interpreted in context. Last but not least, there is the skilled application: a decision, a classification, a recommendation for action or even an automatic, machine-generated action. Finally, the use case is expanded, other aspects and more data are to be included: the game starts again.

We have therefore based our definition of data literacy on the AISNSW cycle model [3] (see figure; we will come back to the meaning of the colouring later). We understand data competency (data literacy) as the ability to make fact-based decisions for an enterprise on the basis of data. In addition to methodological and technical knowledge, this requires careful preparation and the critical and creative handling of data in its respective context. With competency comes the responsibility to formulate requirements for ethics, sustainability, quality and regulation for the entire data cycle. The data literacy charter [4] of the “Stifterverband” poses the following questions: What do I want / can I / am I allowed to / should I do with data?

Data literate and agile – the perfect Match

Basically, agility and data competence have a high degree of mutual affinity. Agile values such as transparency, cooperation and measurability (“measure and grow”) place high demands on data quality and assessment competency. The agile framework SAFe^®distinguishes three categories of key figures: Flow to measure efficiency, Competency as a measure of organizational maturity and Outcome to evaluate strategic goals and the actual benefits delivered (see figure)[5]. The OKRs (Objectives and Key Results) described by us in the last article belong to the third category. We added a fourth category to the standard financial KPIs: Financials.

With the advent of big data and AI, the demands for data literacy, but also the opportunities for companies, have increased dramatically. We can classify their importance for scaled-agile product development into three use cases:

Automate processes:
Data-based and AI-supported applications can deal with complex scenarios and many parameters and can be used for advanced automation up to complex decision-making systems, intelligent assistance solutions and autonomous controls.
For example, this can lead to a better understanding of customer needs, a largely automated assessment of damage reports, conducting customer dialogues with intelligent chatbots, the creation of tailor-made service offers for customers, the detection of fraud attempts in the financial sector, the transport of people and goods through autonomous vehicles, etc. The list of smart applications is endless and will continue to dramatically transform the way we live.

Support strategic decisions:
If strategic goals are formulated in a measurable way, subjective, delayed, manual decisions can be further developed into data-driven and AI-supported decisions. The quality of the data is improved (more measuring points) and the speed of decision-making is increased (being up to date, availability and processing speed).
For example, customer satisfaction can be determined automatically via an automated evaluation of facial expressions instead of manually, via feedback forms or the approval of a political candidate. Even the complex evaluation of a perfume fragrance can be determined in this way.[6]
Further, the formulation of parameters themselves could be solved by AI one day in the not too distant future. First attempts of the automated definition of OKRs can be found on the website of an OKR generator.[7]

Evaluate business models:
Business models can be expanded, optimized or secured in a variety of ways using big data and AI. Customer needs and opportunities or risks from market changes can be identified more precisely and earlier. In complex multi-scenario simulations, digital twins can provide valuable information about their originals in the physical world. Autonomous transport systems or medical micro-robots in our bloodstream are pathing the way for completely new business areas.

Anchoring Data Literacy in the Enterprise

As we have seen, the requirements for data competence, big data and AI are extremely complex and affect all areas of a company. And one thing is also clear: either a company develops this competency, or it will not be able to survive. What also matters, is the right mix between data expertise and technological competence, but also between expert knowledge and a generalist mindset. In order to be able to anchor data competence into an enterprise long term, i.e., also into the corporate culture, measures are required on four levels:

Technical infrastructure
Both company-wide cloud infrastructures and domain-specific, e.g. portfolio-wide, data lakes with high-quality data are the basic requirement for data- and AI-driven software.

Professional and technical competence
We propose the use of the existing roles “Data Scientist” and “Data Engineer” in order to give a home to the technical-conceptual-business-oriented (purple activities in the data literacy cycle) on the one hand and the architectural-implementation-technical-operative (white activities) competence focuses on the other.
In addition, the competence of many other existing agile roles is required to integrate data, model, AI algorithms and tools into new and existing value streams, into the design methods, into the DevOps pipeline and into the IT infrastructure.

Organization
From an organizational point of view, data scientists have an overarching scope and ensure that data and models are defined and functional and utilizable for the entire company or portfolio, while data engineers focus more on empowering the implementation teams (see figure “Organizational model”). We also suggest that both roles conduct specific training for complementary roles at their levels.
A second essential organizational aspect of data competence in agile companies is the provision and maintenance of a dashboard for the above-mentioned agile business agility metrics that can be viewed by everyone. Instead of classic reporting lines, such a dashboard creates extensive transparency and empowerment to everyone in real time.

Leadership
People in leadership roles should have a good understanding of the opportunities and risks of Big Data beyond their own context. They must be able to correctly evaluate business models, define strategic goals and make them measurable, correctly assess budget requirements for data-driven applications or AI models from product management and weigh them against business opportunities. They need to recognize the importance of investing in infrastructure, human resources and training, and promoting general awareness of data literacy through example and proactive measures. Particularly important in an agile context: they must be willing to actively involve roles with data competence in the decision-making and implementation processes.

Key Take-Aways

Data literacy has already become a critical factor for the competitiveness of companies. The widespread availability of Big Data and AI accelerates this development dramatically. The competent handling of data supports the quality and the efficiency of decision-making and new business models, but also helps to avert danger.

Due to the compatibility of business agility and data competence, agile companies can integrate the competent handling of data very well into their processes, structures and technical infrastructures.

The prerequisite is a data-savvy leadership culture that actively promotes data competence at all levels of the company.

Data scientists and data engineers take on other key functions. On the one hand, as data experts, they take on the data competence trainings and, on the other hand, support existing agile roles at various levels with the operational handling of data-based or AI-based applications.

With the set of measures described in the areas of “technical infrastructure”, “professional and technical competence”, “organization” and “leadership”, an agile company can efficiently and sustainably anchor data competence as a core competence in its own DNA.

___

[1] For Today’s Graduate, Just One Word: Statistics – The New York Times (nytimes.com), https://www.nytimes.com/2009/08/06/technology/06stats.html

[2] His daughter-in-law Anna Rosling-Rönnlund gives an entertaining insight into this world of data and its incorrect interpretation in a Tedd Talk:
https://www.youtube.com/watch?v=u4L130DkdOw

[3] Association of Independent Schools in New South Wales, Australia, https://www.aisnsw.edu.au/, Link to Document

[4] Katharina Schüller, Henning Koch, Florian Rampelt: Data Literacy Charter, 2021, https://www.stifterverband.org/sites/default/files/data-literacy-charter.pdf

[5] More on: https://scaledagileframework.com/measure-and-grow/

[7] https://www.workpath.com/okr-generator

Stocktaking For a Transformation

Christoph Tonk — Mon, 13 Mar 2023 08:00:18 +0000

For companies, rapid implementation of various new digital processes is of great importance. How can enterprises realize this in the best possible way? Different digitization dimensions have to be considered in order to specify and visualize the necessary change. The basis for this is a solid framework. What is this all about?

First of all, it is very important to know and understand the status quo in these 3 key areas through a comprehensive analysis:

Business-Transformation
IT-Transformation
Skill & Culture Transformation

For this Analysis we Recommend Two Tools

A digital backbone consists of individual building blocks, enabling an enterprise to react to the rapid changes and new requirements of a digital world. Each one of these blocks encapsulates an important element of the corporate’s business. The digital backbone is a very important tool for adapting to shorter product and innovation cycles, changing customer needs, global competition and evolving markets.

Digitalisation predominantly entails (a) transforming an enterprise’s portfolio of products and services and (b) acquiring capabilities the organization requires to achieve the desired target state. Here, the Digital Matrix is a central steering tool which enables the successive development of corporate capabilities, leading to a targeted and well-structured transformation process. Different digitalisation dimensions have to be considered in order to specify and visualize the necessary change.

What Steps do we Suggest:

Determine a framework for the analysis
Creation of an inventory list of IT assets (via Digital Backbone)
Analysis of skills & culture
Definition of entity modules via master data management
Identification and specification of all business capabilities in the company and structuring with the help of a business capability map.
Determine critical success factors and digitalisation dimensions and maturity levels.

Read the Articles in Detail:

Conclusion

November 1, 2017 3 Comments

Chapter 9: Shaping the Digital Transformation

November 1, 2017 3 Comments

Scaled Agile at Work: Governing Transformation and Innovation with OKRs

Matthias Besch — Mon, 06 Mar 2023 08:00:59 +0000

Objectives and Key Results – OKRs for short – are on everyone’s lips. Easy to understand at first glance, in practice, false expectations are repeatedly entertained.

We sharpen the concept by distinguishing it from related ideas and describing where and how OKRs can be used effectively in agile organizations for sustainable transformation and innovation – with the necessary commitment. Our extended OKR scheme helps define high quality OKRs for different contexts and how to integrate them into modern agile steering tools. Data recorded both manually and automatically via technical sensors can be taken into account.

Getting Things done with OKRs

Applying data literacy to business life: Set dedicated goals, make them objectifiable and then track them. This is how Objectives and Key Results (OKRs) could be summed up.

In general, OKRs are a goal-setting framework for defining, tracking, and ensuring progress towards a strategically embedded business outcome.

In the context of scaled agility, OKRs can be used for setting and aligning goals at different levels of an organization. These can be bold company-wide strategic goals such as “we want to gain a market share of 35% for on-demand insurances in Europe by the end of next year”, or rather near-term product-related objectives, e.g., “we want to see an 10% increase of user loyalty (come-back rate) each month”.

In addition, transformational goals regarding changing one’s own organization can be expressed very well in OKRs: “In 2 years, we want to be the top employer for young talents in Germany”.

But there is more to say on OKRs in an agile context – and that’s what our article is all about: How do OKRs at different levels relate to each other? Who defines them and when should overambitious objectives be corrected? How can OKRs be used for evaluating Minimum Viable Products (MVPs)? Can OKRs replace (agile) roadmaps? Finally, one of the questions we get asked most: how can “Management” ensure that OKRs are followed up upon by the teams? What role do OKR tools play in this respect? Do we need them to establish an OKR culture?

History of OKRs in 30 Seconds

OKRs were first introduced by former Intel co-founder and CEO Andy Grove in his book “High Output Management“, published in 1983. OKRs became widely known when Google adopted the framework in the early 2000s to improve productivity and accountability. Google started using OKRs back in 1999 with 40 people in the company till today with around 60.000 employees. The message is clear: OKRs can be used by organizations of any size.

What makes OKRs special?

To better understand the true nature of OKRs, it can be helpful to look at what OKRs are not.

OKRs are not the same as MBO[1] (Management by Objectives)
MBOs are annual individual or team goals, which are supposedly objectifiable and measurable and set in a dialogue between supervisor and employee, cascading from top to bottom. For OKRs there are different levels, from strategic-superordinate to specific-operative. However, the coordination is bidirectional, with more autonomy and decision power in the respective context, and the goal may (and should) be adopted over time, if conditions change. Typically, OKRs are reviewed every 2-4 months. The decisive difference, however, is that OKRs should develop a driving, visionary power. They also focus more on the process of achieving goals by defining metrics (key results). A goal can and should be formulated in an (over)ambitious way, and if the goal is not achieved in the end, there will be no loss of salary or other disciplinary consequences.
OKRs are not KPIs (Key Performance Indicators)
Both measure performance. While OKRs focus on a few key goals (“less is more”) and a strategic direction related to business outcome, KPIs are rather used for generic standard goals and for measuring and verifying the operational status and health of a system (e.g., control tower or DevOps pipeline).
OKRs are not the same as BSC[2] (Balanced Score Card)
Unlike OKRs, which focus on specific goals, BSC is a more holistic management framework, which looks at a company’s performance from four overall key perspectives (financial, customer, internal process, learning and growth) and the derivation of output-oriented goals in each of these sectors.
OKRs are not PI Objectives[3] (Program Increment Objectives)
PI Objectives are used as binding agreements between businesses and teams on the implementation of concrete deliverables (outputs). OKRs, on the other hand, set ambitious outcome goals.

The Art of OKRs in Agile

Over the last few years, we have developed the following generalized OKR scheme, which has been proven effective in practice and useful for training, in projects and as a blueprint for defining OKR dashboards (tools). The scheme helps provide clarity about context, purpose and direction, while also emphasizing measurability and tracking.

Context: OKRs can be applied at different levels (contexts) of an agile framework, from company and portfolio to an individual team, where OKRs at lower aggregation levels should consider and/or refine OKRs at higher levels. Therefore, they can be perfectly used in an agile organization as they support alignment, accountability, focus and commitment on prioritization.

Purpose: OKRs can be applied to define and track aspirational goals in two ways: for delivering valuable customer solutions (innovative) and for internal change programs (transformational).

Metric & Plan: The KR part is defined by a metric or formular plus a plan. A plan is defined as a series of triples (time, target value, current value). Depending on the nature of the metric, current values may be generated automatically by some sensors (e.g., webpage return rate) or need to be provided manually by some OKR responsible (e.g., market share).

An important application of OKRs is in the evaluation of MVPs (Minimum Viable Product). Both the benefit hypothesis of a large development initiative (e.g., Portfolio Epic in SAFe) addressing the full product implementation and the leading or proxy indicator addressing an MVP can be modelled as a single OKR:

with a single metric and a plan with (at least) two target values,
or by two metrics, where the first one represents the proxy indicator at MVP time.

By the way, NFRs (non-functional requirements) should not be modelled by an OKR. Although technically possible by using our scheme, NFRs represent binding quality constraints and not aspirational goals on their own.

So overall, we see that OKRs and scaled agility go together beautifully. The fact that OKRs should be adjusted regularly also fits well with the agile culture of “Inspect & Adapt”.

We can now also answer our question from the beginning of the article: how do we deal with overly ambitious goals? They are adjusted in dialog as part of an Inspect & Adapt meeting. It’s that simple!

Enforcing OKRs – really?

This section is about agile steering with OKRs.

Of course, OKRs can and should not be enforced. OKRs are not defined centrally and with a certain degree of self-sufficiency, but in mutual alignment between the levels. As always in agile, OKRs assume their power from agreements between affected people and roles.

But how can commitment be achieved? How can “management” be sure that the OKRs will ultimately be followed and implemented by teams?

In our opinion, essentially through four measures:

Limiting the number of OKRs (less is more),
Participation or empowerment in OKRs at various levels,
Transparency and easy accessibility of the OKRs and their metrics including visualization of progress along the plan for everyone,
Ritualized regular evaluation and updating of OKRs through consultation between the relevant stakeholders as part of the existing agile events at portfolio, program and team level.

One question from the beginning of our article regarding the context of agile steering remains unanswered:

Can OKRs replace roadmaps? We firmly believe that this is not the case, even if OKRs themselves contain a plan. Unlike result-oriented OKRs, roadmaps define concrete results.

Both concepts complement each other.

Interactive OKR Dashboard: steering with OKRs

How can we, in practice, work effectively with OKRs, i.e., integrate the previously mentioned success factors transparency, accessibility, and adaptability into our daily work? Our answer: an interactive OKR dashboard can make all the difference.

In small organizations, an Excel spreadsheet can be of great help. In larger companies, there will be no way around a specific OKR tool or a professional controlling tool.

Let’s have a look at an example dashboard, which we implemented on top of MS Power BI. The figure shows OKRs for our application co.bo (compliance bot). This is an Office add-in within the framework of MIP (MS Information Protection) for the AI-supported classification of documents into confidentiality classes. The fields highlighted in red are the objectives, the metrics are displayed in gray boxes, and the plan (the target values) is marked in blue. Each metric and its target values are also represented graphically.

What features must a tool provide to be used as an interactive OKR dashboard? In our opinion, it should ideally have these five characteristics:

Modular visualization: OKR objects that can be placed flexibly on a dashboard encapsulate the OKR scheme and present associated metrics in a visually appealing way. Target values and target/actual deviations should be particularly emphasized. Filters can be used to set the scale and visible time window of the metric.
Input of actual values: Actual values can either be automatically displayed via the connection to external sensors (in our case via MS Azure Logs) or entered manually by an authorized role.
Plan adaptation: The plan (target values and measured values) can be adjusted.
Near real time: The values shown are evaluated and updated regularly.
Feedback: Comments and feedback on values or malfunctions can be easily shared via a button.

Key Take-Aways

OKRs are a powerful tool for agile companies on their way to holistic business agility. They foster communication, transparency, and alignment between stakeholders and experts from different areas regarding the strategy and how to execute it at each level. In addition, OKRs promote responsiveness, because they can constantly be re-evaluated and adapted to market changes, if needed.

A generic OKR template in combination with a flexible OKR dashboard can extremely helpful.

Nevertheless:

More important than tools is a good understanding and feeling for the quality and quantity of OKRs. When in doubt, the following applies: less is more!

It is important to focus on what is strategically essential. Only then can OKRs develop their full power and contribute equally to the effective agile control of internal transformations and innovative customer solutions.

Sources

[1] Peter Ferdinand Drucker: The Practice of Management. Harper & Row, New York 1954

[2] Robert S. Kaplan, David P. Norton: The Balanced Scorecard – Measures that Drive Performance. Harvard Business Review,1992

[3] Scaled Agile Framework: PI Objectives, https://www.scaledagileframework.com/pi-objectives

Unlocking Transformation Success With Conway’s Law

Thomas Peter — Mon, 27 Feb 2023 08:00:51 +0000

This article advocates using Conway’s Law as a tool for transformation projects. Well-aimed organizational changes can contribute to an improved IT architecture and, conversely, an externally stipulated IT architecture can be used to influence the organizational structure.

Defined in 1967, but just as valid today, Conway’s Law states that there is an inherent relationship and, therefore, dependency between an organization’s communication structure and the technical systems it designs and/or operates. In this article, we explore the principle behind Conway’s Law and its influence on leaders, architects, and managers involved in IT-related transformation initiatives or public cloud adoption.

A solid understanding of this concept is instrumental in analyzing, designing, or implementing IT transformation initiatives that target either the organization or its technical systems.

As by keeping Conway’s Law top of mind, leaders are poised to gain an outside-in perspective, can identify communication gaps within the organization, recognize related risks and leverage these insights to drive and cultivate the transformation of both the organization and the system.

Introduction

A while ago, I onboarded a large-scale transformation initiative that blueprinted the rollout of a domain-specific standard system. An adjustment of the target operating model (TOM) for the organization was part of the initiative, yet only some high-level principles had been defined. Also, the initiative’s story explaining the change was still in the works, and I had some trouble putting my finger on what this was all about – at first. I then came across a cartoon by comics agilé that was about Conway’s Law [1], and thanks to this reminder, the scale and vision of the transformation initiative suddenly became crystal clear. The project with its basic principles and somewhat mundane technical goals referring to cost efficiency evolved into an ambitious and thorough transformation project of the organization itself, which was supposed to work with the new standard software.

The story above might sound familiar. Stories that imply a kind of relationship between an organization and its technical systems are ubiquitous throughout the IT industry. Usually, these stories surface to a broader audience when the relationship has been ignored or has not been fully taken care of: a company introduces that one standard software but then struggles for years to digest it on an organizational and process level.

A company introduces a hyped new software but then leverages only a marginal percentage of the software’s full potential, because the organization refuses to adopt it properly.

Or other stories about the pitfalls that come when building a shiny new user-centric web frontend over a product-centric legacy backend.

All these narrations hint at Conway’s Law. In this article, we explore the concept and explain why transformation teams shouldn’t ignore it, but instead consider software rollouts and organizational changes as two sides of the same coin [2, 3].

Conway’s Finding

In 1967, Melvin E. Conway, a computer programmer, submitted a paper that introduced the following theory: “organizations that design systems, are constrained to produce designs, which are copies of the organization’s own communication structures” [4, 5]. Or rephrased: “the way an organization communicates internally, is mirrored by the system it builds”. A hierarchical organization tends to yield a hierarchical system, a network-based organization tends to yield a network-based system, and so on.

The term “systems” is broadly interpreted here. It applies to software systems, but also more generally to all sorts of technical systems. Conway’s Law affects the systems produced “in” as well as “for” organizations. Furthermore, the term “communication in an organization” refers to both process-bound communication flows with a formal communication structure and communication flows incited by social networks with an informal communication structure.

Despite its name, Conway’s theory is not a law in the strict sense. And Conway’s finding had not been adopted immediately, his first submission in 1967 was even rejected due to insufficient evidence. Yet, both the Massachusetts Institute of Technology (MIT) and the Harvard Business School (HBS) eventually published evidence, which supports that there is indeed correspondence between communication structures and system structures, albeit not causation. An equivalent yet more appropriate name may therefore be “mirroring hypothesis” [6].

Reciprocity: Conway vs Reverse Conway

Before we start reflecting on the impact of Conway’s Law on transformation initiatives, we also should address the lesser-known variant of Conway’s Law, the “Reverse Conway” or “Inverse Conway” [3, 7]. This variant has become more prominent in the last decade. Just as a correspondence can be reciprocal, a system and its built-in or expected communication flows can also affect the organization that is applying them. Because of the Reverse Conway, hyperbolically, replacing a system ought to be understood as an important change driver (or even disruptor) on the organizational structure working with or operating that system.

Nowadays, we might expect Conway’s Law and Reverse Conway to be commonplace among people involved in large-scale IT-related transformation initiatives. And indeed, we often see it contained in a body of knowledge or reflected in a design principle such as “process follows system”. The number of abandoned system replacement initiatives, on the other hand, might tell a different story.

It is, therefore, good practice to keep Conway’s Law in mind when engaging in an initiative that aims to change an organization or its technical systems.

A recent showcase to illustrate the lessons of Conway is the adoption of the public cloud. Experience shows that public cloud adoption should be understood as a business transformation journey and not only a technical endeavor. And indeed, from building new solutions to securely operating the public cloud to allocating a budget for a pay-as-you-go platform, the adoption process requires an organization to adjust its internal processes, controls, design and delivery approaches, performance measurements, and communication flows if the platform and the economics of the cloud are to be fully leveraged [8].

Furthermore, when evaluating the inherent differences in public cloud platforms, we might again consider Conway’s Law and think about the organizations that developed these systems:

How were they organized internally?
How did they envision the communication flows of companies adopting their products and platforms?
And what happens if we adapt to their communication flow structure by adopting their cloud platform?
What related conclusions can we draw from their other products?

So, Conway’s Law might introduce new dimensions to our evaluation when selecting a cloud platform.

Gaps and Consequences

In considering Conway’s Law, we can assess transformation risks based on a specific transformation initiative. There are two aspects to be examined:

First, understand the gaps between the communication flow structure caused by your target architecture or system and the target operating model (TOM) for the system itself. We look for differences in planned value chains, imposed separations and organizational handoffs, role concepts, decision ownership, responsibilities, and KPIs. Overall, we are on the lookout for potential points of friction, attrition, or even fractures that will lead to inefficiency and eventually failure of the organization and the system.
“From inefficiency to failure” outlines the range of consequences that result from these gaps in the design of the communication flows, which is the second aspect to consider.

After identifying the gaps and their potential consequences, we can apply standard risk management procedures and try to close or at least mitigate/compensate for these gaps, e.g., by adjusting the system (system follows process) or the organization (process follows system).

In some circumstances, we may look at a specific gap between the target architecture/system and the TOM/organization from a different perspective and accept (or even emphasize) it. If we do not address them, they are likely to become organizational friction points (or even conflicts) that we can use to force an organizational change (Reverse Conway) or a reflection on the design of the system (Conway’s Law). Exploiting a gap can be done explicitly or implicitly. Applying Reverse Conway, also known as the Inverse Conway maneuver, requires obviously a robust architecture/system capable of inducing the desired organizational change [9, 10].

Conclusion

Conway’s Law and Reverse Conway demonstrate the presence of a relationship between the communication flows within an organization building or working on a system and the communication flows of the system itself.

Leaders, architects, and managers involved in IT transformation initiatives should be aware and understand how they can leverage these insights to identify and address transformation risks and drive the transformation itself.

The actionable insights for IT transformation are:

When we are involved in IT redesign projects, we should be familiar with Conway’s Law and Reverse Conway. We should understand that systems, especially IT systems, in some way have an opinion about how to operate efficiently and what communication flows are intended within the organization.
We should understand the differences in the communication flow between the system we are implementing and our target operating model for that system. We should treat the gaps as risks (transformational or operational) or, in some circumstances, use them as drivers for desired organizational change.
Finally, we can use Conway’s Law to examine how successful digital companies build their software and platforms and what communication patterns they have established. We could apply these learnings to our digital journey toward a more agile, network-centric enterprise. We might even consider using an Inverse Conway maneuver to facilitate our journey.

Sources

Project Execution In Large Transformation Programs

Digital Transformation Cookbook — Mon, 20 Feb 2023 08:00:16 +0000

Transformation initiatives typically aim at ambitious goals such as maintaining a competitive edge or driving revenue and growth opportunities.

This article gives a summary of four chapters of the digital cookbook which explain how the ambitions on the program level can be broken down to individual projects.

Regardless of the concrete methodology any project undergoes several typical phases in a more or less iterative and dynamic way:

Ideation: understand the value of what is being developed
Development & Design: understand how the product shall work in detail and deliver its functionality
Testing: apply quality assurance measures to ensure the proper functionality before it’s released
Implementation & Deployment: put the product and processes into operation and make sure everything runs smoothly
Evaluation: ongoing analysis of the results in ongoing operations

Implementing a project which is part of a large initiative requires a few adjustments to traditional project methodologies For example, traditional project methodologies can be limiting due to rigid planning structures and funding constraints.

1. All Projects Must Contribute To The Strategy

In order to achieve the goals of a large transformation initiative, its goals must be implemented via a sequence of smaller yet coordinated transitional steps in the form of individual business projects. Those projects must meet several criteria: Most importantly they must deliver results in a quick and agile way, and prove their strategic contribution at any time. Furthermore, the projects must be capable of reacting to changes and new insights on the level of the transformation program. In addition the projects must interact efficiently with many parallel projects and coordinate tasks and deliverables.

How do companies manage to find the best way for them when traditional project methods are often not suitable for meeting these criteria?

Let’s take a look at the different methods. For example, the so-called waterfall model emphasizes linear processes and cannot support the necessary speed and coordination required by simultaneously executed activities. While purely agile approaches may also have their limitations in supporting strategies or implementing innovation at the enterprise level, the ability to adopt agile into your digital project methodology is key to running a successful digitalization project. By pursuing planning as a series of smaller, reoccurring activities to ensure that the product or service can deliver on the highest business value, it can improve processes and performance, increase speed and team efficiency, elevate user experience and, above all, drive customer satisfaction.

In the article Modeling At The Project Level, we highlight in detail why we recommend dividing every important project into three phases, each with increasing granularity.

2. Start With Business Modelling

A method for iterative business model development is required. This starts at the highest level with the business model of the entire company. Since the business model is changing in the course of a transformation, the individual projects contribute to this comprehensive change.

A suitable technique here is the Business Model Canvas (BMC) by Osterwalder [1] or the St. Gallen Management Model[2].

The BMC, which we will focus on here, enables a simple visualization and step-by-step clarification of an otherwise rather “cloudy” subject of discussion – the elements of a business model.

The method is based on the concept of dividing a business model into nine core building blocks – customer (segments), value proposition, channels, customer relationships, revenue, resources, activities, partners, and costs.[3]

The BMC approach helps to systematically and structurally substantiate the business model and enables the evaluation of new ideas and their differentiation from the status quo. It shows competitive advantages as well as customer benefits and thus helps to estimate the potential success of a new business idea. The application of the BMC methodology is in line with the idea of an agile approach and can contribute significantly to reaching agreement on a “start set-up” for the business model discussion. The implementation scope is already well defined by the BMC and the “start set-up” can be used as a basis for further, more detailed specifications.

In the article Modelling Business Ideas we show how this technique can be applied in detail.

3. Service Modelling - Breaking Down Of Business Goals Into Business Services

In the next step the analysis becomes more detailed and the business services are broken down into discrete services using a service-oriented analysis. It is crucial to design manual as well as automated services with one common comprehensive approach. This avoids both a split between the analogue and the digital world, and between a business and an IT perspective.

Ultimately, we want to ensure that the business purpose is decomposed into implementable components, both in the business organization and in the IT application landscape.

The determination of the business service building blocks must be done quite quickly, using a light and agile approach in the first step. This requires an informal ‘whiteboard-enabled’ methodology that allows for seamless collaboration among different stakeholders.

Based on the functional target structure, once it is aligned within the enterprise, the IT services are modeled. This includes mapping onto existing or new back-end systems, data and security architecture, and message design. We recommend distinguishing between the layers ‘Front End’, ‘Process’, ‘Composition’, ‘Basic’ and ‘Back End’ due to different characteristics of artifacts within those layers.

With the help of various graphics, we outline the different steps and the detailed process in the Service Modeling article.

4. Customer Journey Mapping: Maximizing Customer Value And Understanding Customers

We have already learned that a “digital project methodology” is urgently needed for successful enterprise transformations and highlighted that such a methodology must start with defining the business purpose and customer value. Having derived services, designed a service hierarchy, and discussed the importance of remaining agile in service modeling, we conclude the topic of digital project methodology and now go into more detail about the customer value already examined at the beginning of the process. As mentioned earlier, customer value is at the heart of the Business Model Canvas recommended for modeling the business purpose.

At this point of the project process, we devote our focus to the customer journey. The term “customer journey” refers to the comprehensive experience that the customer has with the offered products or services in all his interactions across all suitable interaction channels. It begins with the customer becoming aware of the offer, then exploring and comparing the offer, and finally selecting, purchasing, and using the product or service.

To address the customer journey and also the associated emotions, we need to understand who the customer is in the first place and the context in which they interact.

Our article Customer Journey Mapping gives a description of the underlying concepts including – for example – the persona concept. We explain why this strategy brings customer and company closer together through new understanding conditions and why such a human-centered methodology fits perfectly with the concepts of design thinking.

Here you can find the individual articles:

Chapter 4: Defining Digitalisation

4.4 Digital Maturity

6.2 Indigo Digital

4.1 Digital Communication Patterns

Best Practices – Enterprise Transformation Circle

FIDA Architecture Patterns

Overview

Leadership Triangle In Action

Introduction

Scaled Agility – The Path to Enterprise Adaptability means Verticalizing Your Architecture!

What are Monolithic and Vertical Slice Architectures?

Monolithic architecture

Vertical slice architecture

Case study: Retailer transition to enhanced business agility

How to start the agile transformation journey?

How to manage technological complexity?

How to address redundant business functionality?

How to handle cross-domain business logic?

Our approach at a glance

Conclusion

Scaled Agile at Work: From Agile Leadership to true Self-Organization (we need to talk about money)

Agile Leadership is a Start

The Stunted Agile Dream

The Path to Self-Organization

Shared Leadership in Practice

And now about Money

Transfer to Scaled Agility

Entrepreneurship needs Dynamic Structures

Dynamic Business Clusters as Entrepreneurial Units

Key Take-Aways

Understand Your Past to Create Your Digital Future!

History Matters in Case of Digital Transformation

Digital Transformation is Different

Path Dependencies Explained

How Can Leaders Respond to Existing Path Dependencies?

Scaled Agile at Work: Bring Data Literacy to Enterprise Life

Data, Facts, Humans

Data Literacy in a Nutshell

Data literate and agile – the perfect Match

Anchoring Data Literacy in the Enterprise

Key Take-Aways

___

Other articles of the series:

Stocktaking For a Transformation

For this Analysis we Recommend Two Tools

What Steps do we Suggest:

Read the Articles in Detail:

Conclusion

Chapter 9: Shaping the Digital Transformation

Scaled Agile at Work: Governing Transformation and Innovation with OKRs

Getting Things done with OKRs

History of OKRs in 30 Seconds

What makes OKRs special?

The Art of OKRs in Agile

Enforcing OKRs – really?

Interactive OKR Dashboard: steering with OKRs

Key Take-Aways

Sources

Other articles of the series:

Unlocking Transformation Success With Conway’s Law

Introduction

Conway’s Finding

Reciprocity: Conway vs Reverse Conway

Gaps and Consequences

Conclusion

The actionable insights for IT transformation are:

Sources

Project Execution In Large Transformation Programs

1. All Projects Must Contribute To The Strategy

2. Start With Business Modelling

3. Service Modelling - Breaking Down Of Business Goals Into Business Services

4. Customer Journey Mapping: Maximizing Customer Value And Understanding Customers

Here you can find the individual articles: