Andrey Kulikov

My takeaways from the book "Architectural Coordination of Enterprise Transformation"

Summary of the Summary (TL;DR)

This is 300+ pages book by scientists about the ways to improve success of enterprise transformations. Complicated, but very rewarding read.

What the book is about

The book Architectural Coordination of Enterprise Transformation" is based on papers written by 16 European researchers during 4 different projects and its goal was to build a comprehensive method or architectural coordination of transformations. The core goal of ACET is to inform decision-makers in a way that "inconsistencies are reduced and local decisions contribute to overarching goals" during enterprise transformations. The book also covers some components to perform such coordination.

Why Is the Coordination Needed?

Enterprises, as organisations with common set of goals, are constantly evolving. But not every change is transformation. "Transformation is about fundamentally changing the business, not about running the business". Typical transformations are changes of business model, large-scale outsourcing or replacements of enterprise IT systems.

Due to their large scale, transformations require a lot of planning, and programme management and project management methods are not enough to plan and implement transformation. Risks of "local optimizations" reduce the overall success of transformation, hence the coordination to "manage dependencies between activities" is needed. A lot of different disciplines (leadership, HR management, financial control and others) aim to provide means to achieve coordination.

"Enterprise architecture intends to provide holistic perspective on an enterprise as a socio-technical system", and managing the architecture requires to work with three different dimensions:

  • artefacts (e.g. objectives, processes, projects)
  • stakeholders and their concerns (e.g. business and social ones)
  • entire lifecycle of transformation

To enable transformation, transparency "throughout Business-to-IT stack" is needed. This transparency can be used as a basis for decision-making processes of different stakeholders.

Transformation Cases and Challenges

Authors include the examples from real-life transformations and summarize different concepts used in those cases.

First case is about the insurance company, which performed the transformation to increase client centricity, operational excellence and revenues. Enterprise architects offered their support to business via "capability catalogue". Architects perform different activities from different perspectives:

  • from the strategy perspective - expectations' gathering, analysis and consoldation of interview results
  • from value and risk perspective - planning of benefits realization, consolidation of business case, risk analysis (incl. "risk of doing nothing")
  • from design perspective - concerns regarding processes and information
  • from implementation perspective - programme integration (e.g. identification and realisation of common tasks among projects
  • from change perspective - stakeholder management, change readiness assessment, establishment of change agent networks, communication

Architects acted as consultants at first, when structuring of activities was needed, and later handed over those tasks to specialized corporate functions.

Second case is about the transformation project of Greek social security system. The goal was to establish a centralized system for pensions and payment. Architects developed two scenarios ("Fully consolidated architecture" and "aggregation of pension reports"). The aggregation was selected due to strong need to deliver solution as fast as possible, though full consolidation was a better choice long-term.

Third case is about alignment of business and IT in Dutch government agency. Transformation was planned to increase efficiency of subsidies' management. "General Enterprise Architecture" (GEA) method was used to build enterprise coherence network. After design phases and workshops possible solutions were identified and clustered, and handed over to change programme.

Fourth case is about another Dutch government agency. Goal of transformation was to make agency open and flexible organisation and perform restructuring, adding architecture board and innovation department. There were challenges with new architecture board, including its unclear role, long communication lines, double roles of architects. Big issue was "change of mindset" of agency's employees, who were not ready for innovations.

Key Concepts

In the Part III of the book authors share the core concepts, principles and models used in ACET. Presented in the classic scientific manner, each concept is explained, used theories are referenced and examples of concepts are provided.

Catalogue of Capabilities

The first big artefact is the catalogue of capabilities, which provides structure for doing ACET. Capabilities are described on abstract level and should be implemented based on specific enterprise's needs and environment.

Degrees of Changes

Authors introduce the typology of different degrees of change. This typology uses a lot of dimensions, including:

  • three domains of work (added-value domain, innovation domain and value systems domain), which are also aligned with requisite strata (Jacques 1998).
  • environment analysis
  • types of change interventions (restructuring, reengineering, rethinking)
  • IT realms (technical, socio-technical, ecosystemic)

All dimensions are used to describe three main degrees of enterprise change, where each successive degree is wider in scope and more sophisticated. Authors also propose to use Giddens framework to analyse social change.

Stakeholders

Architects need to pay attention to the existing organisational subcultures, because org. culture is a moderating factor between EA mechanisms, their effects and EA success. If cultural differences of stakeholders are ignored, communication defects may occur (lack of communication, over-communication, different interpretations of models and texts).

Stakeholder fragmentation (a condition in which the people see themselves as more separate as united) is a key threat to transformation success. To address that issue, more than one core perspective on change processes should be used:

  • yellow-print thinking - negotiation enabling consensus or a win-win solution
  • blue-print thinking - formulation of goals and results and systematic implementation of a plan
  • red-print thinking - motivation of people to perform better and with desired behaviours
  • green-print thinking - settings for learning and allowing people become more competent
  • white-print thinking - identification of things blocking org. evolution

ACET requires inolvement of at least two frameworks - design framework (e.g. Zachman, TOGAF) and engagements framework (yellow-print style).

GEA

Another important concept discussed here is enterprise coherence. GEA is proposed as a framework to define org-specific management dashboard for ACET.

It is very important, that GEA framework includes elements both on the level of purpose (mission, vision, etc.) and elements on the design level.

Boundary Objects

Authors also introduce the concept of boundary objects - means and artefacts to cross the knowledge boundaries between different stakeholder groups. Examples of boundary objects are prototypes, IT apps, maps and models. Authors also explain specific properties (visualization, modularity, abstraction, stability) of models and their relevance for the use of models as boundary objects. The mentioned properties are used to formulate design principles, which can be used by readers to improve their enterprise models.

Model Engineering

Conceptual models (purposely abstracted ones) help with communication among stakeholders through visualisation. Authors mention the popularity of ArchiMate, but also list the restrictions of it (lack of domain-specific issues - linking architectural design to economic rationale). Authors propose e3value as a suitable language for economic viewpoint on architecture. The book included some examples of combine meta-models of e3value and ArchiMate with DEMO transaction patterns.

EA Decision Modelling

In the next two chapters authors offer two models to establish the practice of analysis and observation of EA decisions. The first meta-model (EA Anamnesis) is to analyse the decision's impact, decision-making strategies, rationales behind the choices. The second one is a more mathematically formal decision graph, which shows relations between enterprise issues, enterprise decisions and observed impacts. Due to the formal depiction of decision process, authors are able to define integrity constraints to check the decision graph for consistency.

Conclusion

"This book could only provide a humble beginning towards the creation of a more complete understanding of ACET and the development of an integrated set of instruments supporting ACET in practice"