Engineering Ecosystems Architectures

Looking back, it’s possible to remember the rise in interest just before Objects and Object-Oriented Design were formalised. At the time many professionals were thinking along similar lines and one or two were applying their ideas under other names, but, in the final analysis, the breakthrough came down to a single act of clarity and courage, when the key concepts were summarised and labelled in an acceptable way. The same was true with Enterprise Architecture. By the time the discipline had its name, its core ideas were already in circulation, but practice was not truly established until the name was used in anger. So, in many ways, naming was the breakthrough and not any major change in ideas or substance.

With hindsight it’s now clear that such naming events have little to do with changes in approaches to problem solving, but lots to do with the increasing scale and complexity of the challenges that drive them. Both are side effects of general technical progress. As we become more proficient with a tool or technology, we generally learn how to build bigger and better things with it. Be they bridges, skyscrapers or IT solutions, the outcomes are largely accepted as business as usual. What really matters is that the tools and techniques used for problem solving evolve in kind as demand moves onward and upward. For that reason, when a step change in demand comes along it is normally accompanied by an equivalent advance in practice, followed by some name change in recognition. For instance, IT Architects talk of “components”, whereas Enterprise Architects talk of “systems”. Both are comparable in terms of architectural practice but differ in terms of the scale and abstraction levels they address. In this way, IT Architecture focuses on solutioning at the systems level, whereas Enterprise Architecture is all about systems of systems.

Interestingly, the increases in scale and complexity responsible for Enterprise Architecture were themselves a consequence of advances in network technology, as platforms like the Internet and World Wide Web catalysed progress. This trend has continued with movements like social media having a profound impact on business. So much so that today conventional definitions of “the enterprise” are being challenged, as businesses enhance their capabilities with resources from outside their organisation. This is driving a need for solutions that reach beyond traditional enterprise networks and out into the broader digital ether. We are therefore seeing the next step change to face IT Architecture and again the profession is awash with emergent practice. We even have a name for it already. When networks spread beyond the influence of any single entity or system we generally call them an “ecosystem”. All that remains is for the realisation to dawn: the era of Ecosystems Architecture is upon us.

Enterprise Architects have been familiar with the idea of ecosystems for some time and the pressing need to describe networks of systems working towards shared goals. This is no longer a matter of debate. What is still up for discussion though is how we establish credibility in this new era? Past lessons point to some likely answers, and common sense reminds that tried and tested approaches tend to hold value when modified to embrace change. Nevertheless, this time around the change involved brings with it at least one significant difference. Whereas previously, building things bigger and better typically involved more cost, time and effort, advances in information technology have produced the opposite effect. Today, users expect their IT to be delivered ever quicker and at lower cost, and in response professional practice has evolved to become ever more agile and cost efficient. So, given that previous generations of problem-solving techniques have relied less on being reactive to changing demand, perhaps the jump to ecosystems architecture presents more of a challenge than at first sight?

It is therefore considered that a lightweight framework of pragmatic architectural best practices will be fit for purpose. At its core it provides a surprisingly elegant set of tenets that allow multiple delivery styles to mix and match without conflict:

1. Coverage: Ensure that the portfolio of connected parts is sufficiently covered and understood across all design and delivery activities. Depth is not as critical as breadth, but all parts (networks, systems, components, etc) must be identified and adequately positioned within any broader architecture.

2. Skills & Leadership: Ensure that adequate skill levels are available to address all identified needs. This applies across all known contexts and abstraction levels, and should safeguard technical direction across the entire systems lifecycle. Coverage should be at the significant part level (every justifiable part deserves a capable technical owner across its life).

3. Semantics: Create a scheme for naming parts at different abstraction levels and stick to it. Established convention, such as “network:arbitraryName”, “system: arbitraryName”, “component: arbitraryName”, etc, is perfectly acceptable.

4. Architectural Decisions: Ensure that an accurate record of technical choices is maintained and accessible. This is to ensure the viability of future decisions and help build a body of knowledge in support of future practice.

5. Operation: Ensure that justifiable method(s) and tooling is applied. This should provide guidance when needed and support essential feedback loops, such as decision making and knowledge harvesting.

6. Building Codes & Regulations: Ensure that architectural decision makers follow relevant guidelines, rules, and standards. These must comply with all applicable constraints, like external legislation, ethical consideration, security pressures and so on.

To understand the value these tenets might offer going forward, it’s perhaps worthwhile finally pausing to consider what IT architectures at the ecosystems level actually look like. The following list came out of some recent work at IBM and is not intended to be exhaustive. Nevertheless, it hopefully provides a taster of what lies ahead:

1. Functionality: Participating parts must be able to do something that contributes to all, or part, of the ecosystem

2. Communication: Participating parts must be able to communicate and co-ordinate resources with other parts, either within their immediate context (ecosystem, sub-network, system, etc) or outside of it (system, wider-network, complete-ecosystem, environment, etc). Parts must possess amplification and attenuation capabilities to suit

3. Controls: It must be possible to control the ways in which participating parts group (structure), communicate and consume resources in a common or mutually agreed manner

4. Awareness: An ecosystem must support instrumentation and observation at both participating part and higher-group levels. This includes implicit awareness of its environment, given that this can be considered as both a unit and group participant in the ecosystem itself

5. Regulation: An ecosystem must support constraints at the group level, that guide it to set policy and direction

6. Adaptability: Participating parts and higher-level groups must be able adapt to variance within the ecosystem and its environment

7. Support and Influence: Participating elements must be able to use resources supplied from other participating elements, groups and/or the environment itself

8. Self-Organisation: Structures must allow self-similarity (recursion/fractal) at all scales and abstractions

Source: ibm.com