Ecosystems Architecture

Ecosystems can also be recursive in their structure and reach, so it is often hard to understand where one ends and the other begins. As such, it is perfectly valid to speak in terms of ecosystems of ecosystems, where one or several may be embedded into others. Consequently, participants can be part of one or many ecosystems while playing out multiple evolving roles. Likewise, the purpose of any single ecosystem may well be directed toward a single purpose, whereas others might legitimately focus on multiple agendas. Nevertheless, purpose will always be targeted in support of some underlying human-centric^[2] need, with examples of broad categories including:

Such categories fall in line with many recognized models of psychological and social behavior and are also strongly influenced by the 2015 United Nations (UN) Sustainable Development Goals [36]. Relevant models include Abraham Maslow’s Hierarchy of Needs [37], which provides a hierarchy of motivational drivers associated with the human condition, covering everything from basic survival instinct up to personal enlightenment, belief systems, and beyond.

Models like Maslow’s Hierarchy of Needs nicely highlight the symbiotic relationship between human and machine in an enterprise ecosystem world. As such, they act as a cornerstone in a broad field of study focused on how people and technology merge to form Sociotechnical Systems (STS) in the modern world. The ideas behind Sociotechnical Science [38] [39] can therefore be directly overlaid to help frame the notion of enterprise ecosystems in terms of IT architecture. This is because they succinctly sum up how the various actors, elements, and constraints involved can meld into one singular whole. An enterprise ecosystem can further be seen as:

“The emergent summation of a self-organizing network, or networks, composed of human-centric participants, be they individuals, groups, enterprises, or organizations, the technologies they use, the information at their disposal, and the environment in which they all co-exist. In such arrangements, connections between constituent parts (artifacts) can therefore be explicit, through either direct communication or integration, or implicit, as in being more osmosis-like, where connections are transient, implied, inferred, or informal.”

Participants and/or constituents (artifacts) in a sociotechnical ecosystem, therefore, make use of technologies, information, and resources provided to and from other participants and/or constituents and their environment, and provide and receive reciprocating feedback as a natural response. Together, both participants and/or constituents and their environment create a system of dynamically evolving parts and properties that often display episodes of convergence, diversification, and extinction in much the same way as experienced in diversely natural ecosystems.

Enterprise ecosystems, therefore:

Although the idea of working with IT above enterprise-level might feel daunting at first, the parallels between Enterprise and Ecosystems Architecture can be quite striking, especially when it is considered that the delineation between the two may often be just about how we formalize the boundaries involved. For instance, it could plausibly be proposed that what we perceive as an enterprise is, actually in practice, nothing more than a small, self-contained ecosystem, and that the principal differences between Enterprise and Ecosystems Architecture are simply about scope, complexity, and scale. In other words, where we establish any boundaries of discourse or closure.

Enterprise Architecture, therefore, simply corresponds to a hypo-enterprise^[3] mindset, whereas Ecosystems Architecture is predominantly hyper-enterprise^[4] aligned.

On the surface then, the idea of an enterprise, as a legal entity at least, generates a singularity that just makes sense — even when considering that such entities emerge out of a collective of business or mutually beneficial functions. Cumulatively these amass solidity around corporate identity and higher-level purpose, and so exhibit external alignment, continuity, and a general lack of internal friction — while under the covers, individual functions may well be jostling for position or even partaking in all-out war. You may, of course, disagree, exclaiming that the enterprises you have worked with are nothing like that in practice. But hopefully, you get the point. As a model and as a generalized architectural pattern, enterprise implies a oneness inherited by the use of a term that is singular in nature and which masks the plurality of its form as a series of lesser business units, in its connected internal areas of specialization or function. As such, we might conclude that because an enterprise is composed of such units, it is actually an ecosystem in its own right; an ecosystem manifesting from a networked clustering of specializations. Thus, any enterprise must impose the boundary for its internal ecosystem, based on the footprint of its legal identity. Likewise, any enterprise ecosystem can be considered as a similarly closed, connected, and whole continuum, only this time accommodating higher levels of abstraction than at the enterprise-level. As a result, Ecosystems Architecture encompasses group types like domains, regions, communities, or colonies of enterprises (or lower abstraction constituents), and above that whole ecosystems, worlds, or universes as types for singular compound entities at or above the notion of the individual enterprise. In that way, Ecosystems Architecture simply extends the recursive hierarchy of abstraction, categorization, and containment formed when Enterprise Architecture positioned itself above the level of systems architecture.

With that in mind, ask yourself how many times you have heard the sentiment that all IT-based features or functions should be aligned with the business? Perhaps you yourself have even presented such an argument? That is because the very nature of architectural practice in IT is to work toward a definition of enterprise that appears, both internally and externally, to be seamlessly in line with commercial and legal intent, rather than just a patchwork of specialized functions, stovepipes, or silos, all individually contributing piecemeal. This is, of course, interesting from an ecosystems perspective, simply because the removal of any demarcation between silos should be aligned with how an enterprise, or more specifically its business and legal intent, is actually composed, rather than how it is perceived to be set up or directed. As such, any intent to align IT with the enterprise, or its surrounding ecosystem(s) should be handled carefully, as it could first be construed as rhetoric prone to misaligned thinking, and second, it could serve to create unnecessary friction between IT and the purpose it seeks to serve.

Whereas IT architects perceive the world in terms of functions, attributes, and so on contained within components, Enterprise Architects do the same in terms of components within systems. So that begs the question: what should Ecosystems Architects trade in?

Because of the breadth and scale of the ideas requiring representation at the ecosystems level, categorization and containment must be handled in a very generic way — granted there is the issue of scale and the fact that ecosystems can have a recursive nature, it is, therefore, counterproductive to use competing sets of definitions at differing levels of abstraction. Instead, Ecosystem Architects will likely need to talk in terms that are agnostic of scale, abstraction, and complexity. This leads to the cover-all idea of representation via nodes; with a node simply providing a generic way to describe either a single idea or thing worthy of mention, or, likewise, a collection of either or both, and regardless of level of scale, abstraction, or complexity involved.

An Ecosystem Architect will, therefore, take these nodes and correlate them to clusters, domains, regions, communities, colonies, enterprises, systems, components, aspects, attributes, or whatever and at suitable abstraction levels, as needed. In that way, nodes can be typed according to whatever features require representation, and then connected to produce whatever coherent representation is required in the form of a generic graph — an ontological^[5] schematic showing how nodes are related.

This is much the same as is done at both systems and enterprise levels, in that all architectural schematics can be considered as specialized forms of graphs. The only difference being that ecosystems-centric schematics are not so precious about the levels of abstraction and graphical nomenclature used to classify and describe node instances. Instead, associated typing is expected to be explicitly side-lined from the graphical symbology in play and documented as a node attribute in accompanying documentation. This increases the semantic expression available by making graph representation both flexible and extensible.

In general terms, then, nodes are represented at the ecosystem level using a flattened nomenclature of either boxes, or more commonly circles, connected by lines or arrows. There are no constraints on whether lines should be straight or not. The use of arrows normally indicates some form of directional flow, but again, typing can be moved out into accompanying documentation. This includes typing associated with composition, association, implication, and so on. For more details, please see Chapter 3.

The transition from graphical typing to documented attribution might, at first, feel misplaced and foolhardy, especially to those steeped in more traditional IT architecture practice. Nevertheless, the move is deliberate at the ecosystem level.

Of old, we, as IT architects, might have been asked to write down what we knew of a problem space, then analyze that text to help identify its various entities, actions, and properties of interest. In that way, prominent nouns typically translated into architectural entities, verbs their actions, and adjectives their properties or aspects. From there, composition flowed from decomposition, and architectural structure arose from the design and engineering processes being followed.

With Ecosystems Architecture, however, the complexities and scale of the problem spaces involved might well mask any system’s structure up front, so all we can do is state what is known and include whatever assembly is obvious as we go. This is analogous to throwing all our thoughts, ideas, and discoveries at a wall and allowing an architecture to emerge of its own accord — much like the singular idea of an enterprise spontaneously emerging from the cumulative contribution of its individual business functions. That is, rather than deliberately forcing out structure through a sequence of reductionist and/or compositional design tasks.

This change, therefore, demands increased diligence in documenting our thoughts across the board and at all times. In that, the analogy of an imaginary wall, or architectural workspace, becomes very real, and an abstract mathematical framework replaces the architect’s favored pen and paper to record progress. This specifically allows all the aspects of an architecture to be pinned down precisely, and in a very Taoist^[6] way — almost like a highly expressive mind map with little concern for scale or complexity. That introduces its own rigor and a unique set of advantages, by way of the mathematical formalisms introduced. But more of that in Chapter 3. All that really changes is the order in which we recognize architectural elements, and the moments at which revelations become apparent. In the end, the same aim is reached, in a coherent understanding of how a system is, or should, be configured, even though the route to achieve that might not be totally clear at the outset and may also need the help of some advanced tooling^[7] along the way.

Relying less on sequential progress to squeeze out structure means that understanding integration and interoperability must rise in prominence, especially during the early stages of architectural thinking. In short, the notion of connectivity needs to always be at the forefront in an architect’s mind, especially when it is understood that typing moves from being graphically explicit to an act of assigning property via additional documentation across all architectural elements. This stance is transferable to Enterprise Architecture as well, but the potential inability to perceive the enterprise as an ecosystem can serve to increase the dysfunctionality within that enterprise — through misalignment, discontinuity, and friction created by the deployed systems already in place.

Enterprise Architects are well positioned to become Ecosystem Architects, by the virtue that it is only the boundary of discourse that changes when moving up from one abstraction to the other. First, however, there must be a significant shift in the appreciation of how an enterprise is meaningfully constructed. So much so that the value of isolated specialization is worth reiterating.

To nail this home, simply think of any organizational chart. What do you see? A box for Sales, a box for Marketing, a box for Engineering, and so forth, all followed by the other boxes for essential areas of business specialization. In other words, and in less flavorsome terms perhaps, a silo for Sales, a silo for Marketing, a silo for Engineering, and so on.

In an ecosystems approach then, each silo simply becomes a node, that, in turn, might act as a container for further nodes at increasing levels of detail. These nodes, as repositories for contributing functionality, data, and so on, are then fundamental and necessary. In fact, they become, in part at least, a best practice essential, in that the nature of the node affords delineation, specialization, flexibility, performance, and efficiency in an ecosystems view. Nodes, therefore, act as the basic means of aggregation at the ecosystem level.

In part, this realization comes down to appreciating that each silo establishes a set of motivations and behavioral patterns that directly support its existence and separation from other silos. There will, of course, always be some overarching motivations that transcend the individual unit, but these are more akin to accepted social behavior within some higher means of decomposition, and might actually act as connections between nodes when that level is considered formally. Therein, and in business terms, each silo may be associated with a primary sponsor, as in a Vice President or Director perhaps. This leader may or may not then get along with other Silo Leads, and so competition can take hold and distort reality as seen by IT. This not only plays out around extra-silo composition, but also intra-silo composition, with Silo Leads perhaps being prone to subdivide their own domains into lesser areas of speciality. This obviously creates more silos and more opportunity for isolating motivations and behaviors. As a result, sub-speciality silos can often present as badly formed nodes. This is a never-ending story. As no doubt most experienced IT architects will realize, internal organizational conflicts of one form or another can permeate and simmer into perpetuity. This creates one of the eternal challenges facing all IT architects.

In summary then, modern enterprise is a blend of both dependent and independent business units that co-exist within and across a complex ecosystem. Invariably, that ecosystem can transcend corporate boundaries, bringing further into question where the idea of an enterprise ends and the reality of open-ended ecosystems thinking begins. A starting point for aspiring Ecosystem Architects is therefore to learn how their own enterprise functions and behaves. Alignment needs to be toward supporting the organizational silo view and not disarming it or causing further friction. The bane of IT is the silo, and yet it is also its savior, as the enterprise is, at its simplest level, nothing more than a conglomeration of silos — or, as the Ecosystem Architect will come to call them, nodes. Some nodes interoperate better than others, some compete, and some, at times, are stubbornly dysfunctional. It is not the job of IT to fix the enterprise per se, and it is not a job of the business to change the enterprise to conform to IT’s perception. Nevertheless, it is the role of IT to support the enterprise in any manner that the enterprise itself wishes to exist. And to do that, IT must take to heart its mantra: “We want to align ourselves with the business”. This, therefore, is the starting point for the Enterprise Architect to transition up to hyper-enterprise ecosystems thinking levels.