by Jackie O’Dowd
Business and Enterprise Architectures commonly describe the logical organisation and alignment of ICT infrastructure, applications, business processes and data into the organisation’s operating model. The connection between the designed conceptual model and its actual implementation is important. It is important because Enterprise Architectures typically comprise several reference architectures which describe how the various technologies and layers fit and work together. Having clarity and visibility of these reference architectures is crucial as they translate requirements into an integrated technology and systems solution. However, with each reference architecture and additional component comes increasingly broad complexity, often involving non-linear relationships and ad-hoc feedback loops along with other emergent properties that may only surface once systems are in use. It’s fair to say that in the world of Enterprise Architecture, the whole is greater than the sum of its parts.
Historically, efforts have emphasised simplifying complexity. From an Enterprise Architecture perspective, simplification can introduce its own set of problems, such as loss of context, a shift to reductionist thinking, and not having visibility of emergent risk.
Complexity in Enterprise Architecture can mean different things to different people. This diversity of interpretation is not surprising given the multiple types of complexity in play. Remington and Pollock1 suggest five different types of complexity are commonly found in organisational initiatives, these being; Structural, Technical, Directional, Temporal, and Socio-Cultural. This raises a critical question; “How do we identify and adapt to the complexity inherent in the Enterprise Architectures we design, build, and deploy?
It is time to advance the conversation on the inherent complexity found in the majority of Enterprise Architectures that almost every organisation, regardless of size or industry, must contend with.
Understanding complexity characteristics
Complex architectures are characterised by attributes that make it challenging to manage using traditional project or program management methods. These architectures often have many layers, interconnected parts, variables, and dynamics that are not immediately apparent or easily understood. Complex architectures are also unpredictable (Theiss 2023)2 due to the communication and interaction required across and between the components.
Managing an architecture build and deployment requires both broad and deep understanding of the interdependencies, interactions, and inherent constraints. As increasing levels of automation are deployed at scale, greater visibility and transparency is needed to understand not only the technologies and applications in play, but also the intended and unintended consequences and behaviour that they generate.
Architectural artefacts and systems documentation (even if up to date) typically show elements such as nested operational processes as simple, generalised linkages and design patterns which results in greater levels of ambiguity, not clarity. They only allow us to understand in part. As systems architectures become more complex in build, capability and scope, enhanced sense-making capabilities are needed to navigate components, to ensure a coherent, adaptive systems design. The International Centre of Complex Project Management (ICCPM) considers sense-making an essential skill3. Sense-making involves understanding complex situations, interpreting ambiguous or uncertain information, and deriving meaning to make informed decisions. Sometimes it is easier said than done.
Why visibility is important
It is rare to find any one individual in an organisation who fully understands how the systems in use are built and operate. Visibility into not only the technical architecture but also the many data stores, connections, and relationships at play is important. Visualising architectures can be insightful in helping to reduce the risk of overgeneralisation or misunderstanding specific properties, as it can help in highlighting unintended consequences. This is where node and edge models become practical tools for architecture teams as these models help make better sense of the environments they design, build, and manage.
These types of models provide a holistic view, placing the architecture, and more importantly its many components, into context. Interactive models like these enable interdisciplinary teams to provide specialist inputs and perspectives, improve knowledge sharing, and enhance understanding of the inherent complexity within the various systems and the architecture as a whole. Whilst the models illustrate the various components and their connections, they also allow the architecture teams to navigate, explore and analyse the many parts, connections, and relationship types. Unlike traditional 2D models where systems are represented using generalised boxes, lines, and abstract processes, these models provide both an analytical and systemic view.
Being able to understand the interactions between the various elements and architecture components becomes as important as the systems and components themselves, especially when grappling with complexity. Being able to understand and explain architectural relationships and their complexity is a necessary capability for the 21st century (Professor Geoffrey West 2024)4. There needs to be greater clarity and awareness of relationships and linkages that are formal, informal, one-to-one, one-to-many, many-to many, event driven, commercial and non-commercial, etc. Not understanding relationship and linkage details has strategic consequences that extend across innovation, performance and reputation.
Leading in complex situations
Although numerous Enterprise Architecture frameworks are available for design guidance and reference, leadership frameworks are not as commonly utilised. As Enterprise Architects take on a greater leadership role within organisations and as systems complexity grows, a complexity leadership framework can help to bridge the leadership capability gap. When applied effectively, leadership frameworks help to reduce misaligned activities, improve communication, and can act as a catalyst for innovation, growth and resilience. One such model is Leaderplex (Hooijberg, Hunt and Dodge 1997)5 which connects leadership to principles of complexity science. These principles include Complex Adaptive Systems, Emergence and Interdependence, all of which are increasingly relevant to Enterprise Architectures and architecture teams.
Over the past few years complexity science and leadership have become an area of focus for many organisations. The Australian National University (ANU)6 has recently established a Complexity Leadership Lab, creating a space to research complexity leadership and develop new leadership and management capabilities. Many researchers have identified the inherent complexity in enterprise systems (Schneider, Zec, and Matthes 2014)7 (Uhl-Bien, Marion, Seers Orton 2006)8 and historically efforts have emphasised simplifying complexity. From an Enterprise Architecture perspective, simplification can of cause introduce its own set of problems, such as loss of context that can lead to poor judgement and decision-making, or it can result in a shift to reductionist thinking which often leads to skewed priorities and overlooking areas of emergent risk. Oversimplification sacrifices adaptability, scalability and resilience as it often removes critical nuances and decreases the ability to react and respond.
But what if complexity is the system itself and attempts to simplify it is part of the problem? The combination of ICT infrastructure, data networks, enterprise grade security, specialised applications and increasing levels of interoperability can result in both anticipated and unanticipated complexities including:
- Structural complexity – arising from the number and diversity of technologies.
- Interaction complexity – the number and types of system relationships and interactions.
- Computational complexity – algorithms, reasoning and problem solving.
- Regulatory complexity – compliance with laws and regulation within and across different regions.
- Operational complexity – the intricacies of day-to-day functions.
- Behavioural complexity – behaviours the system and its components exhibit.
- Cognitive complexity – the mental effort required to understand and holistically manage systems.
There are always aspects that are hard-to-change
A key issue with current Enterprise Architecture frameworks is their embodiment of early, far reaching, and in some instances difficult to change decisions that have a long-term impact. These frameworks rarely address questions such as “Are there any unintended consequences that will result from the system’s build and use?”; “What ESG metrics will be used that will measure the performance of the system over its lifetime?” and “What is the intentionality of the system?”. Such questions are seldomly factored into architecture conversations.
Ideally, hard-to-change and long-term impact areas of complex Enterprise Architectures should be defined and understood early in the lifecycle, ensuring that all parties appreciate dependencies, risk and impact. As Grady Booch the renowned Software Engineer has mentioned in his many presentations and on his website, “Architectures represents the set of significant design decisions that shape the form and function of a system, where significance is measured by the cost of change”9. These hard-to-change aspects may include integration patterns (what needs to connect to what), vendor demarcation (responsibilities and boundaries), and a clear definition of what constitutes a fully effective, functioning, secure system. It is also crucial to recognise that architectures, particularly those forming part of complex multi-year builds, will evolve over time as technologies, methods and standards change. What is designed and contracted, may not always be what is delivered, which further underscores the importance of contextual considerations.
As Enterprise Architecture evolves it effectively becomes a complex adaptive system. In such systems relationships are not primarily hierarchical but are defined by the intricate interweave of interactions within and external to the system itself. Understanding and maintaining visibility of these aspects is vital.
Enterprise and Business Architectures today do not self-design and generate, although this is a future possibility. They require leadership and orchestration to create the structures, systems, processes, and governance mechanisms to manage internal and third-party contributors effectively. Introducing an architecture leadership and orchestration role provides the capability to decompose a system design from a high-level abstraction to a detailed, granular design that can guide and integrate architecture activities. The need for the leadership and orchestration role is linked to the purpose of an Information Systems Architecture, because both focus on ensuring a structured, consistent, and aligned approach. The purpose of an Information Systems Architecture is to progressively decompose high level requirements into specifications with enough detail for systems and software engineers to build a system that conforms to the requirements (McDowell, 2019)10.
Architects must also manage the many competing narratives that emerge during the course of a system’s build. These narratives evolve over time and guide far-reaching decisions, particularly those related to systems integration. The digitisation of business processes places greater emphasis on data, information, and integration to support both human and systems decision-making. “Integration solutions can quickly become complex because they deal with multiple applications, data formats, channels, routing and transformations” (Hohpe & Woolf, 2011)11.
Evolving and Emerging Architectures
In today’s world, data and information are seen as valuable assets that enable informed decision-making and greater insight. Organisations tend to accumulate and curate data for profit, evidence, and the opportunity it holds. When we take a contextualised and holistic systems-level view of data and how it is acquired and used, it allows us to make better sense of the world we operate in. It highlights how we can use data and information to achieve greater insight into the things that are important. We can start to see and leverage the value of data both as an input and output as well as an enabler of circularity.
As Enterprise Architectural patterns evolve and over time grow more complex due to the continuous introduction of new technologies, systems, and data types, a combination of orchestration, systems knowledge, and systems-thinking is required to meet functionality, performance, security, quality and availability requirements responsibly.
Technologies like artificial intelligence and quantum computing will further complicate systems while offering opportunities to decipher vast amounts of real time information. To manage this complexity, research emphasises the importance of incorporating both positive and negative feedback loops (Dubberley & Pangaro 2015)12 (Weiner, N. (1945, 1985)13. The inclusion of feedback loops can highlight how systems are designed, monitored and controlled, and homeostasis achieved.
The majority of organisations set their own direction for what they deem an effective architecture to suit their business model and ecosystem. As new deployment models, technologies and capabilities are adopted, having a well-orchestrated, interdisciplinary team that has input and insight into systems design and deployment will help organisations to navigate the evolving and emerging systems architecture, and its inherent complexity, by allowing for:
- A broader and diverse perspective on business and organisational requirements
- Alignment of the architecture to organisational goals and objectives
- Greater adaptability
In a complicated, multi-layered, highly automated organisation, interdisciplinary teams need to be able to solve problems that cut both horizontally and vertically. They need to be able to temper architecture overhead and be able to design, build, and deploy adaptive systems. As technology innovation progresses, the development of new complexity leadership skills and competencies will be vital for navigating the ever evolving and emerging Business and Enterprise Architecture landscape. Understanding complex relationships and putting vast amounts of data and information into context is an imperative for organisations wanting to gain visibility of impact and performance. In the realm of increasingly complex Enterprise Architectures, we need to be able to seize the advantage of complexity and not fall victim to it.
References
- Remington and Pollock: International Centre for Complex Project Management www.iccpm.com
- Theise. N. (2023) Notes On Complexity. Speigel & Grau New York.
- Data Analytics for Informed Decision-Making in Complex Project, www.iccpm.com
- The Menzies Leadership Forum: The fundamentals of leadership complexity Podcast
- Hooijberg, R., Hunt, J. G., & Dodge, G. E. (1997). Leadership Complexity and Development of the Leaderplex Model. Journal of Management, 23, 375-408.
- https://cybernetics.anu.edu.au/projects/complexity-leadership/
- Adopting Notions of Complexity for Enterprise Architecture Management, (2014) Schneider, A.W., Zec. M, Matthes. F.
- Complexity Leadership Theory: An interactive perspective on leading in complex adaptive systems (2006) Lichtenstein. B.B.: Uhl-Bien. M.: Marion. R., Seers. A.; Orton. J.D; Schreiber, C. University of Nebraska.
- Booch G. https://handbookofsoftwarearchitecture.com
- McDowell, J. D. (2019). Complex Enterprise Architecture – A New Adaptive Systems Approach. In McDowell, Complex Enterprise Architecture (p. 8). Apress Berkeley, CA.
- Hohpe, G., & Woolf, B. (2011). Enterprise Integration Patterns. Addison – Wesley.
- Cybernetics and Design: Conversations for Action, Dubberley H. Pangaro P. (2015) Cybernetics and Human Knowing Vol 22 2015, p73-82.
- Weiner. N. (1948, 1985) Cybernetics or control and communication in the animal and the machine. The Massachusetts Institute of Technology USA.
About the Author
Jackie O’Dowd is the Founding Partner and CEO of Realising-Potential. With a Master of Leadership and Management from Curtin University, Jackie is a recognised Advisor in Enterprise and Business Architecture. She helps organisations optimise performance, enhance operational efficiency, and align strategic goals with measurable outcomes. Her career spans ICT and professional services, with experience across industries such as government, healthcare, mining, and civil construction. Jackie has partnered with executive and leadership teams to turn around failing projects and implement robust systems architecture, process improvement, and data management strategies. She also serves as an expert witness in legal disputes, tackling complex organisational challenges with precision and insight.
© Realising-Potential Pty Ltd
All due respect, but I cannot get rid of feeling that the approach mentioned is a hard system’s one. Jackson (in his Critical Systems Thinking and the Management of Complexity) recognizes 6 types of complexity: technical, process, structural, organizational, people, and coercive. If nothing else, the last two types of complex situations will require to add yet another important aspect to infrastructure, applications, business processes and data – people, being it customers, partners, or employees. In fact, this aspect can often be the determining one, or at least have enough power and importance to impede the other aspects. This is true even for an operational model, but it is more obvious in a context operating with terms such as value or (business) capability. More to be found at https://strategyintoreality.com/