Abstract coming soon

Each domain creates and maintains their own data model in a dedicated system of record based on ubiquitous language and identical understanding of technical terms.

Create and maintain a central overview of all data objects, systems, capabilities, APIs, and domains and their dependencies.

During the various meetings and communication within the first EnTranCe Circle on the topic of “Monolith2Modular”, the participants noticed that the same terms were used again and again in the context of the discussions.

In order to make it easier for future Circles and entrepreneurs to hold discussions along the lines of the transformation idea, these terms were compiled by the members and defined in their own words.

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!

This article therefore highlights history as an important influencing factor for digital transformation and discusses its impact on such transformations. According to many publications and interviews, a lot of digital projects and initiatives fail. For instance, successful innovator Google currently lists more than 280 failed projects on its cemetery website killedbygoogle.com (e.g., the video calling app Google Duo). Most often, projects turn into failures when they become more expensive than initially calculated, consume more resources than planned, or do not achieve their intended business goals.
Whether or not a digital initiative ends up as a failure heavily depends on the history of the company accumulated throughout the various phases of its existence. This history can include changes in such factors as strategic priorities, technological developments, organizational structures, long-term visions, or stakeholder alignment, all of which often influence each other. But why does history matter so much in digital initiatives?

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!

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

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. 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.

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.

Transformation initiatives aim at ambitious goals such as maintaining a competitive edge or driving revenue and growth opportunities. This article summarises four chapters of the digital cookbook which explain how the ambitions on the program level can be broken down into individual projects:
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.

This article is about increasing the competence of employees to manage their own performance as opposed to top-down micromanagement. Employees who carry out their work with creativity and enthusiasm contribute to the well-being of the entire company. Seems logical, so far. In the real world, however, employees must follow organizational rules and practices, such as filling out the notorious timesheet, which is often perceived as stifling and micromanagement. Knowing the true value of time reports, leaders often struggle to sway the negative perceptions of their employees. This article highlights the importance of communicating the benefits of time tracking to your employees and offers advice on how to convince your employees that their timesheets are everything but a waste of time.

Many issues in companies are related to Master Data. Accordingly a company, having full control of its Master data and their accuracy and precision, will face significantly less issues in its daily operations and by that, it will save a lot of precious resources. And that’s a huge competitive advantage!

Developing complex software systems for large enterprises in a truly agile way 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 improvement.

Scaled agile development requires many teams working towards a common goal. An optimal team structure minimizes communication and coordination effort and thus shortens the time to market – the length of time between idea and delivery. But is there even an optimal team structure? Unfortunately, the answer is: usually not. But there are building blocks and heuristics that can lead to a significant improvement over an ad-hoc topology, as we have seen in practice.

“Is ‘Agile’ Really the Way to Go?” In my article I wrote for #Enterprise Transformation Circle I analysed the weaknesses of agile methodology in enterprises. Reading all the articles about the success of agility at Spotify and other tech companies, it sounds so easy introducing agility. But there are many aspects which can affect the success of introducing agility in an enterprise. So I ask myself the question if agility is the right way to go for an enterprise. If you ask yourself the same question enjoy the article.

Agile companies in industries such as banking or insurance encounter a higher level of complexity due to extensive regulations. While existing stage-gate governance bodies face the challenge of quickly changing projects, the informal Community of Practice – i.e., teams that address cross-cutting topics – are disconnected from the governance processes. Their work is slowed down by central boards which are needed to reach approval for the discussed issues. To bridge the gap, we recommend creating guilds — virtual communities responsible for a specific cross-cutting issue—with a specific governance mandate.

For any enterprise-wide transformation initiative and particularly the digital transformation of organizations, architecture is a key success factor on several different levels, e.g., software or enterprise architecture. Despite the importance of architecture within the transformation process, many organizations struggle to establish a successful architecture practice, often due to the well-known “ivory tower” antipattern in which architects have no impact on actual projects. Another problem is that architects and their expertise are highly critical resources, and their valuable time needs to be prioritized better, e.g., architects working on trivial topics or spending too much time in useless meetings. For both situations, this article offers an overview about the key responsibilities for a successful architecture practice.

This article describes the role of “Core Topic Responsible” (CTR) – a caretaker for overarching requirements that are spread across multiple teams.

When working in a complex agile setup, such as SAFe or the Spotify approach, teams might need to deal with requirements that have strong interdependencies not only within their own team, but across the whole organization, including non-agile lines of business. We therefor recommend introducing a new role, which we call the “Core Topic Responsible”. Ideally, this role is to be assumed by a Business Analyst, who represents a central point of knowledge and assumes ownership for the overarching topic.