Christoph Tonk – Enterprise Transformation Circle

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

Resolving Team Dependencies the Agile Way

Christoph Tonk — Mon, 21 Nov 2022 09:30:39 +0000

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.

To resolve complex functional dependencies, we strongly recommend introducing a new role to establish ownership for a specific overarching requirement.

The main purpose of this role is to act as the go-to-person, as he or she is tasked with maintaining the holistic picture for an overarching requirement in terms of:

domains and stakeholders affected by the requirement
architectural dependencies that need to be considered during IT delivery
features which are contributing to or are pending on the requirement

As an employee in a large-scale agile project, one experiences these challenges first-hand, especially when a lightweight agile framework such as “Scrum” suddenly becomes enterprise strategy relevant and needs to be scaled, for example via “SAFe”.

As several teams are involved in the delivery, requirements can grow beyond the capabilities of one single team. Dependencies can then only be resolved if the different teams collaborate accordingly.

A decisive factor for identifying potential dependencies, in the first place, is the regular exchange between different roles within the agile teams involved, e.g., Product Owners (PO), Architects as well as Business Analysts (BA). This happens within the framework of fixed ceremonies, e.g., the so-called Community of Practice (CoP).

Ceremonies Do Not Always Need an Agenda

According to the SAFe framework, an Agile Release Train (ART) consists of several agile teams, which need to refine functional requirements from features to autonomously create user stories. Therefore, the business functions required must be broken down and described in a comprehensive manner by the acceptance criteria within the user stories. Although some agile frameworks do not explicitly define this role, a Business Analyst (BA) often acts as a sparring partner to the Product Owner (PO). One of the main tasks of the BA in this context is to ensure that business requirements are well understood and holistically addressed by the acceptance criteria.

To enable cross-team alignment, the SAFe framework includes setting up Communities of Practice (CoP) in addition to the team-internal ceremonies. Usually, these CoP meetings are intended for roles typically working on topics with impact on other teams, e.g., PO and Architects. Here, we strongly recommend also setting up a CoP or any similar alignment ceremony for Business Analysts.

In the beginning of each alignment ceremony, the members can express urgent concerns. To enable discussions about current team topics, the ceremony continues with a mood survey.

Although a CoP typically has neither a Scrum Master to moderate, nor a fully timed agenda, a lively exchange about the current topics and various action points that serve to overcome possible challenges will typically arise.

The action items which result from these discussions should be documented in a central place, e.g., a Confluence page. If the discussion shows that the topic has strong interdependencies between individual teams, a separate documentation needs to be considered.

Management Does Not Always Have To Come From "Above"

To deal with these core topics in a structured way, we recommend establishing a so-called “Core Topic Responsible” (CTR).

A Business Analyst with good communication skills and the ability to take a high-level perspective is especially well suited to assume this role and facilitate the teams as a topic owner, e.g., providing the holistic business context in architecture circles.

While the PO focuses on the team’s backlog, the BA often has more capacity to gain deeper insights into topics. Depending on the overall project complexity, the CTR might also take ownership of requirements for multiple products.

Managing Dependencies is Key

The challenges mentioned above often consist of interdependent cross-team requirements. To reduce the degree of complexity for the respective overarching topic, teams must work together in a coordinated manner and identify potential dependencies on a regular basis.

In principle, dependencies between individual requirements should already be identified while they are still in the program backlog and at the latest during PI planning in order to enable planning across the affected teams. For this, Jira offers out-of-the-box analysis such as the Dependencies Report in Advanced Roadmaps. Due to the complexity of functional and technical aspects, however, dependencies may also be identified later on, i.e., when the agile teams have already started the design or development phase.

In this case, it is important that these so-called “core topics” with their individual dependencies are documented and passed on to the Product Manager (PM) so that he or she can design and manage the overarching target picture together with the System Architect (SA).

To visualize the dependencies, we recommend a dependency diagram that contains all necessary details, is easy to read and, above all, can be adapted successively:

With this holistic overview, the CTR should also be available as a direct contact person for Developers, Testers and Software Architects, and to provide expert input in the design of the future solution.

In weekly meetings, the CTR can report the implementation status to the Product Manager and address potential problems at an early stage. Through their thematic understanding, the Core Topic Responsible can support the Product Manager and System Architect in defining the roadmap and architectural runway.

The basic idea behind this role is to establish a supporter rather than a manager. The CTR coordinates the processing of their core topics’ individual components, but also actively participates in the writing of the user stories and is willing to gain deep thematic insight.

Furthermore, the CTR takes part in alignment meetings, e.g., the CoP as well as in architectural meetings, to encourage a continuous exchange of information about the respective core topic and to manage upcoming tasks.

Summary

Especially in complex agile environments, it can be challenging to maintain a holistic overview of interdependent requirements. In this article, we described how the Business Analyst can take ownership as the Core Topic Responsible for a topic containing several requirements. This overarching role ensures the alignment between different teams and maintains a holistic view of the target picture, resulting in a consistent implementation of the requirements within the core topic.

However, one must consider that the introduction of such a role should not generate additional work for the teams, but rather reduce the overall effort. Therefore, we want to highlight the following principle of the agile manifesto:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

Agile Sin #5: Complex Architecture

Christoph Tonk — Mon, 29 Mar 2021 16:10:22 +0000

“Everything everywhere” – the age of digitalization requires convenient access to and constant availability of IT systems throughout all channels and devices. However, this means additional complexity in company processes and procedures. As a result, the digital transformation is accompanied by a rigorous agile restructuring of organizations – often blindly following every trend. A consistent enterprise architecture often falls by the wayside and technical debts pile up continuously. Whilst agile evangelicals often fail to pay the necessary attention to sustainable architectural approaches, conventional enterprise architects and lead architects lend weight to holistic architectural management.

Based on the views of these colliding worlds, we call the fifth sin, the “Deadly Sin of Architectural Superbia”.

One of the key design principles of agile organizations is self-organizing teams. These teams are intended to promote the creativity of employees, free them from complex dependencies in their environment and thus increase productivity.

But, does this also work when developing IT applications in large companies? Especially here, the coordination and collaboration between projects and architecture departments is often perceived as inefficient and associated with red tape. It actually seems as if the introduction of agile methods is changing the rules of the game. Agile teams are granted far more autonomy than traditional project teams regarding architecture decisions.

Almost every IT application landscape is characterized by complexity and numerous dependencies, which cannot be managed by small and possibly isolated agile teams. For a lot of companies’ considerable damage can occur when traditional and agile dogmatists clash and fail to jointly set up a contemporary agile architecture management approach.

Agile mindset and architecture - does this add up?

Architecture in traditional companies usually consists of clear guidelines, rules, principles and decisions that are made by architectural committees. In most cases, architects specify artefacts and processes to establish a sustainable enterprise architecture. When implementation projects require the expertise of (lead) architects, e.g., for architectural decisions, they often constitute organizational bottlenecks due to a large number of projects. Nevertheless, anyone who does not follow the architectural guidelines must explain themselves in committees and the project is temporarily on hold due to architectural discussions.

Agile teams, on the other hand, are of a manageable size and complete architecture tasks independently. Architecture rules, guidelines or even processes and committees do not exist or are self-organized. Architecture tasks tend to focus on the day-to-day project activities and their progress. In addition, architectural knowledge varies from team to team and is characterized by continuous learning and acquiring experience.

As a result, missing architecture documentation can give rise to “head monopolies”, which makes it difficult to establish a sustainable enterprise architecture.

Architecture management in the digital age demands a changed and more agile set-up with an accordingly adjusted mindset. It is important to allow both agile and also classic perspectives when designing the architecture environment. In this, one’s own ego and architectural pride (superbia) should not get in the way. The focus of the teams has to be to finish architecture task quickly and successfully. In addition, a suitable approach is necessary to make the increasingly complex (enterprise) architecture more manageable and controllable.

Architecture in an agile environment means being part of a community

On the one hand, an agile mindset means freedom, self-determination and continuous learning. On the other hand, it also means being more consistent and efficient in everything we do or did in the past. These rules do not only apply to managers, but to every member of the team. Projects are not “only” done for the senior management, but for an actual customer with concrete requirements and a vision. As a result, any action of each team member has a crucial impact on the overall outcome and everyone bears responsibility for this result. It is therefore important to support each other and celebrate success stories together. As a result, team members develop a group identity which lets teams grow together on another level.

Support is not only provided within one’s own team but also across teams. Thereby, it is important to proactively promote communication with other teams, to help each other and to learn from one another.

The agile manifesto underpins these approaches: It underscores mutual support and the importance of individuals and interactions.

Overall, it does not matter whether these interactions take place in a casual atmosphere over a game of table football, over a drink or at an organized event or meetings. Every employee is a noticeable vital part of a community and can see and feel their added value.

Architecture – the agile way?

The well-known, agile frameworks address the topic of scalable architecture work and recommend different approaches in this regard. Nexus, for example, says that an “integration team” is responsible for informing the teams about the company’s architecture standards. In Large-Scale Scrum (LeSS), architecture tasks at the team level are handled by experienced team members, eliminating the role of the enterprise architect. In Scaled Agile Framework (SAFe), on the other hand, enterprise architects combine architectural questions and decisions at different levels and provide the technical vision and strategic direction.

But what can be derived from the frameworks in terms of architecture and what other recommendations are there based on practical experience?

In the agile world, the main objective is to follow a collaborative, decentralized and light-weight approach. Lean governance is used to define important issues while intentionally leaving other issues open for the community and teams. Teams can make decisions independently, discuss them in the community and thus help to shape the guidelines bottom-up. One could assume that an agile approach to architectural issues would result in a chaos of different, decentral “designed” architectural styles. In order to avoid such cross-team or company-wide issues, teams must be enabled accordingly. On the one hand, architecture assets such as guidelines, standards and frameworks must be accessible in a common and uniform language at a single point of information and documentation. On the other hand, it should be possible to get assistance from architects with a comprehensive and strategic perspective. Therefore,

it is necessary to clearly define roles and responsibilities and to spread them across “broader shoulders”.

With the help of the developed architectural knowledge, teams can solve simple architectural issues by themselves without the need to involve architects.

Ideally, “architecture gurus” provide guidance by acting as facilitators in close cooperation with the teams and assisting them with active (methodological) support. Moreover, architecture services are “bundled” in the form of a community of practice (CoP), comparable with a guild or a shop, and can be requested by the teams according to the “pull principle”. CoPs thus maintain an overview of critical or cross-team issues. If necessary, they also take care of formats for comprehensive communication and decision-making.

Preferably, comprehensive decisions are based on prototypes or walk-throughs and feedback is solicited from architects, teams and other stakeholders. Such cross-team formats, which are also suitable for casual exchanges and brainstorming sessions, include open spaces, architecture snacks or architecture cafes.

Nevertheless, the independent architectural work of the teams should also be promoted whilst adhering to the standards in place. CoPs can use gamification approaches such as hackathons, scoring boards or architecture belts to playfully create competition and showcase achievements. This allows to distribute and establish architectural knowledge and understanding in the agile organization.

Recommendations

The architecture discipline plays a key role in the strategic orientation of companies. Especially when scaling across multiple teams, business and organizational dependencies lead to challenges in communication and coordination. To establish modern and efficient architecture management and overcome architectural pride, we recommend the following:

Architectural awareness must be omnipresent throughout the entire (enterprise) community, from the employees to the top managers.
Key roles (managers, product owners, scrum/agile masters, architects, etc.) of the (enterprise) community must be directly involved in the architectural work and have to embody the changed architecture mindset.
Architecture management must be established in the form of a suitable, agile organizational setting, such as a CoP or a guild.
Lean architecture governance has to be based on providing certain architectural solutions (e.g., documentation, guidelines) or leaving them deliberately up to the agile teams.
Architecture decisions must be encouraged to be addressed and demonstrated by the teams (bottom-up).
Architecture guidelines and standards have to be proactively designed by the teams.
Creative communication formats (e.g., architecture snacks, architecture cafes) have to be set up for the entire enterprise community.
Cross-team assistance must be promoted and appreciated. The necessary capacities have to be allocated.
The architectural autonomy of the teams has to be increased by leaving problem solving and responsibilities to them.
Successful architecture work and community-wide communication have to be stimulated and rewarded.
All employees and roles must be provided with opportunities for ongoing training and professional development in the field of architecture.

Summary

If it is possible to integrate a community-based architecture management approach into the agile organization and thus to anchor architecture tasks and ways of thinking across the board, (enterprise) architecture management can become significantly faster and more efficient than in traditional organizational set-ups. Consequently, architectural adjustments, redundant functionalities and time-to-market can be reduced which helps to satisfy customer needs within the digital age.

9.6 Digital Backbone

Christoph Tonk — Tue, 31 Oct 2017 23:00:00 +0000

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. In this context, the digital capabilities of a company are mapped onto this set of building blocks, which in turn can easily be joined together to create new, specific solutions. This is illustrated in the figure below.

The digital backbone provides a rapid way of implementing various new digital processes – e.g., for providing different sales channels, such as mobile apps – as well as reducing the time to market of digital products.

This makes the digital backbone a very important tool for adapting to shorter product and innovation cycles,[1] changing customer needs, global competition and evolving markets.

A digital backbone supports the idea of a resource-based view of an enterprise[2] and relates to the approach of Michael Porter’s value chain.[3] In essence, there is a focus on the interactions between the corporate business functions and resources in order to achieve a competitive advantage. Therefore, each building block represents a corporate business function, made available within the company through the digital backbone.

It has to be noted that there is no universal backbone spanning all sectors of industry; in fact, each enterprise must carefully design its own individual backbone based on its specific market needs and derived digitalisation strategy.

Reusability is one of the main attributes of a building block. For this reason, it is a common practice to define the so-called entity building blocks based on the fundamental business objects. The entity building blocks are the basis for nearly all business functions and ensure that these can fulfil their defined output. That is why, as a next step, these functions should be defined in the digital backbone as process building blocks. Process building blocks represent concrete business actions, such as solvency checks or invoicing, which can be located in a process service for banking. In a best-case scenario, the digital backbone comprises all the business functions of a company. To guarantee a high quality of building blocks and their corresponding specifications, the SOA (service-oriented architecture) principles of service design[4] have to be applied. Technical building blocks may additionally be defined in the backbone in order to cover matters concerning adapters, logging and security. When working with building blocks, it is important to consider that they can have interactions or even interdependencies between them. For example, process building blocks almost always require entity building blocks and, in some cases, technical building blocks – e.g., the sales service requires the customer and the contract.

When defining entity building blocks, master data management[5] – including a definition of relevant business objects and their corresponding responsibilities within the enterprise – serves as an excellent basis. By using the existing structures, entity building blocks can be identified efficiently. It is also easier to assign responsibilities to the corresponding teams or business lines. In general, all building blocks have to be allocated to a domain within the domain model of the enterprise. The domain model acts as a stable classification framework for building blocks, which is always independent of the current organisational structures and existing applications. This means that neither organisational changes nor changes in IT systems lead to a transformation of the domain model. Using this stability, responsibilities for building blocks can be defined in a future-proof way.

Process building blocks embody one or more business functions. When defining them, the business capability management approach can be of great help.[5] Here, all business functions (called business capabilities) within the enterprise are identified, specified and structured using a business capability map.

‘A business capability defines the organisation’s capacity to successfully perform a unique business activity.’[7]

It can be said that capabilities: (a) are the building blocks of the business, (b) represent stable business functions, (c) are unique and independent from each other, (d) are abstracted from the organisational model and (e) capture the business’s interests. In the field of business capability management there is also a variety of analytical methods and tools which can be used to obtain insights into several economic and technical topics. These insights can be used to validate KPIs and collect information from which further actions can be deduced – examples include statistics about the business value, the frequency of use or the technical implementation of a capability.

This particularly helps planning and prioritising the implementation of building blocks. Other criteria when prioritising building blocks should be their contributions towards the degree of the digitalisation, a positive customer experience or the possibility of achieving a unique selling proposition (USP).

Within the context of a two-speed architecture,[8] the elements of a digital backbone are usually provided by the ‘slow’ speed, transaction-focused, legacy back end, and used by the ‘fast’ speed, customer-centric, front-end applications. Therefore, the design and implementation of building blocks tend to be slower and more complex. This is a consequence of important requirements such as security, scalability and flexibility. For this reason, the building blocks should be assigned to specific implementation and maintenance teams.

To guarantee a continuous and target-oriented development of the digital backbone, these teams must also be part of the line organisation.

This is important from an enterprise architecture viewpoint, because architectural governance structures can now be integrated more efficiently.

_____

[1] Brynjolfsson, E., McAfee, A.: ‘Race Against The Machine: How the Digital Revolution is Accelerating Innovation, Driving Productivity, and Irreversibly Transforming Employment and the Economy’, Digital Frontier Press, 2011.

[2] Penrose, E., Pitelis, C.: ‘The Theory of the Growth of the Firm’, Oxford University Press, 1959.

[3] Porter, M. E.: ‘Competitive Advantage: Creating and Sustaining Superior Performance’, The Free Press, 1985.

[4] Erl, T.: ‘SOA – Principles of Service Design’, Prentice Hall, 2007.

[5] Berson, A., Dubov, L.: ‘Master Data Management and Customer Data Integration for a Global Enterprise’, McGraw-Hill Osborne Media, 2007.

[6] Leonard-Barton, D.: ‘Wellsprings of Knowledge: Building and Sustaining the Sources of Innovation’, Harvard Business Review Press, 1998.

[7] Cameron, B., Kalex, U.: ‘Webinar on Business Capability Management‘, Forrester Research and alfabet AG, 2009.

[8] Bossert, O., Ip, C., Laartz, J.: ‘A two-speed IT architecture for the digital enterprise’, McKinsey, 2014.

9.7 Digital Matrix

Christoph Tonk — Tue, 31 Oct 2017 23:00:00 +0000

As we have seen in the previous sections, digitalisation predominantly entails (a) transforming an enterprise’s portfolio of products and services and (b) acquiring capabilities the organisation 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 visualise the necessary change.

The Digital Matrix provides a hierarchical breakdown of the required capabilities of the organisation and compares the existing maturity of the digitalisation initiative with the target state.

Thus, it allows the CDO Office to keep track of the transformation process of the whole organisation. The Digital Matrix must be effective in at least two aspects. First, the Digital Matrix must provide a ‘big picture’ that is discussed at board level and serves as a ‘digitalisation dashboard’ of the whole enterprise. At that level, the matrix allows cross-cutting topics to be tackled, such as corporate culture or global training programmes. Second, in order to steer change at the level of business units with specific contexts, submatrices are needed and provide a more fine-grained view. It is important to note that there is no universal matrix; the dimensions needed vary from industry to industry and are unique for each enterprise. It is, therefore, up to each enterprise to set up its own Digital Matrices.

A digital assessment of the company must be undertaken to determine specific digitalisation dimensions and maturity levels. Here, internal and external factors have to be taken into consideration. First, market and trend analyses should take place.

The digitalisation requirements of the company are investigated based on critical success factors. In this context, a benchmark analysis is also recommended, since it will make the current market position transparent with respect to competitors. One possible approach is to base the market analysis on the Five Forces Model by Porter.[1] In this model, the following aspects are evaluated: (1) the threat of new entrants, (2) the bargaining power of suppliers, (3) the threat of substitutes, (4) industry rivalry and (5) the bargaining power of buyers. One result could be the need for a fundamental change in the business portfolio (i.e., of the existing business model and business strategy), in the course of which new digital capabilities are developed.

In addition to the external analysis, an in-depth evaluation of the internal digitalisation status with regard to technical (IT) and business capabilities must take place (for example, ‘the interoperability of IT systems’ or ‘the ability to change’). If a digital readiness assessment has already been conducted, this can be used as a valuable underlying base.

Finally, the enterprise must determine its critical success factors and its own digitalisation dimensions and maturity levels. This is important because different industries and market conditions typically result in different success factors. The various digitalisation dimensions can be deduced from the following clusters:

Since data has become a key asset (e.g., in the form of an API or integrated products) and customer centricity is one of the driving forces of digitalisation as a whole, the Data and Customer clusters are two especially central pieces of the transformation process.

When defining maturity levels, frameworks such as COBIT or CMMI can be used as references. It is important to refine the maturity levels of each dimension by defining specific action plans or checklists, including required deliverables. This has to be done for the ‘big-picture’ matrix as well as all submatrices. It then becomes possible to visualise the whole digitalisation initiative in a quantitative and qualitative way, as well as identifying the current and target states.

This ensures that all stakeholders have a clear understanding of when a maturity level is reached in any given dimension that affects them. The example shows a submatrix depicting the distribution of organisational and technical skills across the value chain of the enterprise.

It is important to note that the concept of the Digital Matrix must be integrated into existing corporate processes. This can be based on the documented results from the internal and external assessments. The ‘big-picture’ matrix should be located in a prominent strategic place – e.g., the digital headquarters – from where the digitalisation initiative can be steered. There, it can be used as a transformation dashboard in the day-to-day work of the CDO or an equivalent governance body.

The integration of the digital matrices into the project portfolio management process is also key, since the transformation of the company is driven by concrete projects.

In this respect, the matrices become an integral part of the roadmap planning. ‘White spots’ can be identified early on and new projects can be initiated accordingly. In addition, governance structures, e.g., a digitalisation board, and defined KPIs ought to be established.

This enables senior management to make the right direct strategic investment decisions with respect to the modernisation of the business portfolio, which in turn leads to an efficient management of the digitalisation initiative.

_____

[1] Porter, M. E.: ‘Competitive Strategy: Techniques for Analyzing Industries and Competitors’, Free Press, 1998.