Communication Architecture

In my previous research, I have investigated the relationship between transformation, planning, and communication in large-scale architecture programs. Obviously and unsurprisingly, communication has a huge impact on the perception and relative success of enterprise architecture and change management initiatives. The important turning point, that I have argued so far, is the way communication shapes and is shaped by the organisational systems in which it takes place. The German sociologists Dirk Baecker and Niklas Luhmann have been my primary sources of inspiration and research for formulating a set of guiding principles for change programs that do not simply assume that communication is a fully informed and unambiguous process of sending and receiving objectified information. Organisations and their people are all systems in which communication takes place. The boundaries, values, and cognitive processes of each system influence and complicate the practice of communication, which, in turn, requires a complex systems model to model and explain its behaviour.

Most architecture methodologies highlight the need to share and communicate architectural plans and roadmaps with key stakeholders in a timely fashion. Whilst frameworks often offer templates and tools, they often fail to explain how and why stakeholders may not understand or simply ignore the intent and agenda of enterprise architecture. Technical problems, overtly detailed artefacts, and too abstract abstractions are often mentioned as the reoccurring problems when attempting to “sell” enterprise architecture to the CXO level. Paradoxically, what was meant to help, guide, and transform the enterprise has now become its own architectural swan song as it drowns in a bureaucracy of templates, procedures, and formalities. This is an indication that the intent and purpose of architecture was not communicated properly to the right people at the right time.

Architectural layers and principles ensure that enterprise transformation is carried out in a coherent fashion. The prime role of the architect is to balance and align business and technology and link these factors back to the enterprise’s objectives, mission, and vision. However, despite communication having a huge impact on people, change, and actual outcomes, it has never been an explicit part of this equation. Communication is often assumed to be rational and presumed to be well-functioning, running in the background of people’s minds and the organisation’s offices just as the Java garbage collector picks up and purges empty object pointers in the Java virtual machine. Assuming a highly complex, volatile social process to behave in such an ordered, rational manner is all too simplistic: human communication and social processes simply don’t behave that way.

So what is the alternative? The obvious choice is to integrate communication as a core concept and layer in enterprise architecture itself – the communication architecture. Here, communication refers mainly to the social processes of human and computer interaction and – not pure computer networks or algorithmic manipulation of signals. On the other hand, communication is not only about people and utterances – computers and technology play a vital role as well as an efficient transport medium. My point is that communication in itself is a socio-technical system describing the complex message exchange between humans, intentions, and machines – or, in C. S. Peirce’s words, a semiotic system. Semiotic systems have dissipative structures of signs in networks constituted equally by humans and machines. Communication in enterprises can be interpreted as complex signs, manifested in dialogues, written emails, and network packets in the router. Some communications are relatively stable (a published document or a sequence of bytes representing an email) whereas others are fragile and chaotic (human intentions, political agendas, gossip by the water cooler).  Their manifestations are entirely different, but the purpose remains the same: exchanging ideas, values, and intentions – utterances – between people in- and outside the enterprise in order to ensure its long-term survival. As I havepreviously pointed out in this blog, enterprises as socio-communicative systems have rhizomatic properties – the modern enterprise should not be solely viewed as a hierarchy of processes, layers, and computers, but also as a constantly transforming multiplicity of events and signs. Thus, the theoretical foundation for describing the communication architecture of the modern enterprise must be found within the theory of organisational semiotics and sign theory.

In upcoming blog posts I will attempt to tie these very theoretical reflections back into a practicable architecture framework for organisational communication.

Enterprise Portfolio Management and Enterprise Architecture Paper Available

I have added another paper to my list of papers.  This one is on the central role of the Enterprise Architect in the Enterprise Portfolio Management Process and how Systems Engineering, System Architecture, and Enterprise Architecture are inter-re…

Enterprise Portfolio Management and Enterprise Architecture Paper Available

I have added another paper to my list of papers.  This one is on the central role of the Enterprise Architect in the Enterprise Portfolio Management Process and how Systems Engineering, System Architecture, and Enterprise Architecture are inter-re…

Enterprise Portfolio Management and Enterprise Architecture Paper Available

I have added another paper to my list of papers.  This one is on the central role of the Enterprise Architect in the Enterprise Portfolio Management Process and how Systems Engineering, System Architecture, and Enterprise Architecture are inter-re…

New: Links to My Papers

I added a new page (above and to the right).  It contains links to some of my papers.  I will be posting more from time to time.  I am ordering the papers so that the readers might be better able to follow my discussion in each.  I …

New: Links to My Papers

I added a new page (above and to the right).  It contains links to some of my papers.  I will be posting more from time to time.  I am ordering the papers so that the readers might be better able to follow my discussion in each.  I hope that helps.  Let me know with comments, what you think.

Bob

The Papers include:
1. Enterprise Portfolio Management and Enterprise Architecture
Coming shortly

2. The Role and Development of an Enterprise Architect: A Devil Advocate’s Perspective

3. Systems Engineering and System Architecture in an Agile and Short-cycle Transformation Environment

New: Links to My Papers

I added a new page (above and to the right).  It contains links to some of my papers.  I will be posting more from time to time.  I am ordering the papers so that the readers might be better able to follow my discussion in each.  I …

Lack of Cloud Ready Apps is a Software Architecture Failure

Seemingly a lifetime ago (2009!), I shared how security concerns have to be “baked into” any cloud platform, as well as a simple set of capabilities to consider when addressing said security concerns.  Of course, information security is just one a…

Common Pitfalls of Solution Architecture Governance

Framework-ism: Form and structure over content and good practice (not best practice). Best practice is all too often a cover for theoretically ideal, but practically non-functional solutions.
Boil-the-ocean-ism: All too generic frameworks intended for large-scale program transformation lack local focus and technical guidance.
Architecture astronaut-ism: Abstraction upon abstraction upon abstraction until everything is so conceptual that end-users have dissolved into TOGAF deliverables.

My mantra for solution architecture governance is:

“In IT governance land, it is OK (read: critical!) to be IT- and solution-centric. After all, it is called solution architecture, not conceptual framework theory.”

Clouds and scalability

This post comes from an online exchange with Roger Sessions (@rsessions on twitter) Leo de Sousa (@leodesousa) and Chris Potts (@chrisdpotts).Roger makes the point that the various cloud vendors make their case on “scalability” without defining the ter…