Seemingly random...the evolution from chaos to complexity

Today, in discussing with a client, my approach to enterprise architecture and the application of chaos theory, he asked me what I see as the difference between complex systems and chaotic systems.

This made me think that it is probably worth looking at why I see them as different and what the relationship is between the two. Both are dynamic in nature, but in the one there is a defined structure based on knowledge of all components and factors, the other however…

For me (and most sources seem to agree with me) the difference between dynamic complex systems and chaotic systems is that in a chaotic system all the attributes, components and deterministic behaviours are not 100% known or model able.

In the complex dynamic system, the components are all known and all their attributes, behaviours and relationships understood and modelled.

The random or rather, the unknown and not-understood/undefined nature in ecosystems lends all ecosystems (and Enterprise architectures) to really be chaotic, even where it is believed to be optimal (within a contained scope).

The true understanding and definitive structure (relation) can only be defined for what is clearly known and contextualised - the moment there is one change that was not previously known of, then the complex dynamic system migrates to a chaotic system.

In considering that Chaos theory centres on "random" deterministic behaviour, I believe (and it is a belief, rather than having absolute proof) that behaviour can really only be defined as seemingly chaotic/random, because of the lack of understanding or context. This random behaviour can however become known and understood (even modelled) over time or from the right perspective, providing potentially for returning a chaotic system to a complex dynamic system.

Complex dynamic systems are really just snap-shots or contained extractions from chaotic systems (or the greater ecosystem) – ultimately everything in the universe has an influence on anything else (however minute).

To bring this back to Enterprise Architecture – my function should be to provide an organisation with the view (plus change analysis and governance) of the current (or future state) dynamic complex system (basically the contained structure within the chaos), but also to work on resolving and moving from a chaotic system when an unknown change/factor comes into play.

Chaos Theory applied in project environments

Today I discovered, what is one of the closest related approaches in applying Chaos Theory to a business, as what my focus is around the application and value of applied chaos theory to the Enterprise Architecture function (and business in general).

Randy England, published and article titled "Applying Chaos Theory in a Project Based Organization" (based on his presentation to the PMI Global Congress 2009 EMEA).

The essence of the article is that most people think of Chaos and immediately make a negative connotation, rather than to try to understand and exploit the benefits of an dynamic and deterministic ecosystem that is a business. With the focus on projects within organisations, Randy indicates, that there is huge benefit in uncovering latent capabilities as well as unidentified factors, highlighting the need to manage projects through active collaboration and focus on a shared purpose. He highlights that there is therefore a far greater need for communicating effectively and working closely with all influencer (in this context the people in an organisation) with an effort on influencing them through intervention at the right points. To do so it is important to uncover the factors that could drive and/or restrain activities toward project goals, and to focus on utilising positive but to manage the potentially negative forces (not just limited to the project, but based on wider impacts) - this in my approach is a core component of the Enterprise Architecture function as part of change management (in programmes and projects).

Since I use the business ecosystem concept actively, both in enterprise architecture consulting and in the intelligence embedded in Confluxes, this statement held a lot of value for me - "View people and the organization as an integrated part of a natural living system, subject to ambiguities and chaos, and capable of coalescing forces into powerful outcomes"

This was the first time that I come across the work of Randy Englund, but it will not be the last. With an approach and view that is so closely linked to my own use of Chaos Theory, I will keep closer track of information coming from him.

Only the tip of the iceberg

I'm currently doing some work on profiling businesses (their products, requirements, customers, suppliers and partners) to contextualize them within the greater business ecosystem. This is to support both my PhD research work (in applied chaos theory to enterprise architecture in relation to business change management) and to further refine the intelligence models for Confluxes (currently a closed network, but with final touches being put on for public launch as a web based service).

In this task I use the model and intelligence embedded in Confluxes to uncover the existing inter-business relationships (B2B customers, partners and suppliers) as well as to the links between the relevant businesses (products and procurement requirements), leading to some very interesting results with regards to how and which businesses intersect on various value chains.

This lead me to discover a a service called Iceberg (by Fractis Ltd), an easy to use software as a service for creating workflow and web applications. The solution aims to enable users to use the web based service (or on premise solution) to create integrated workflow for weaving together enterprise solutions - no code writing required....unfortunately this send my mind running, especially around the name of the solution - Iceberg.

Having dived deep in the oceanic trenches that is the enterprise operational and technology landscape (not even thinking of the wider business ecosystem context beyond the boundaries of a single business), I have been fortunate (because I survived the ordeals) to uncover that the solutions being addressed are usually only the tip of the iceberg, and have little chance of noticing that there are also other iceberg tips attached to the same base.

I'm all for solutions that reduce complexity and empowers the business user, but this leaves a huge opportunity for activity in isolation to creep in, really disrupting (or even destroying) the carefully crafted architecture that supports the interlinked technologies, data and functions that exists in a business.

This is by no means a critique on the Iceberg service, but purely an observation in relation to the use of software as a service or really any software/technology/process implemented on site, but in isolation with out factoring the impact beyond its immediate reaches.

I have to admit, I have not been able to put the Iceberg service to the test, so it might just make me eat my words of warning, if it does have safeguards in place to guide users to consider the wider context (which is especially important when you deal with creating enterprise workflow and solutions!) - From the surface and the testimonials, Iceberg looks like a good tool...in the right hands and carefully used as guided by a competent enterprise architecture function.

I'm a big supporter of Software as a Service (SaaS), Confluxes is really a SaaS solution (targeted at micro, small and medium businesses), that through understanding a business context within the greater business ecosystem, can then automatically discover new business to a business, as well as to find (and compare) potential suppliers for the business' requirements (plus the supporting interaction management and market information tools to support this). Confluxes, after launch, will also open the platform to other software providers to deliver their solutions through the platform to the business ecosystem and can integrate with the functions and information from Confluxes, thereby driving more SaaS solutions to the market.

While we may be implementing (and me working on improving) the intelligence in Confluxes to be able to apply chaos theory for the discovery of opportunities, and to use system complexity and relational dynamics to understand a specific business context to the greater business ecosystem - it is still a far way off from being able to have an AI like enterprise architecture function for managing the use of software (and processes, organisational design, infrastructure, etc.) as it is purchased, implemented and used inside a business at a far more granular level...with far more minute and seemingly unrelated impacts.

To ensure that SaaS solutions (and other buzz items like "Cloud Computing" - nothing other than virtual infrastructure really!) actually deliver benefits to the business as a whole (and not duplicate or negatively impact somewhere else), you will need an EA function to govern it.

Service Orientated Architecture - not just a technology perspective

Service Orientated Architecture (SOA), as with most references to Enterprise Architecture, seems to technology focused, rather than an all encompassing architectural approach covering and cross-integrating between the domains of business, applications, information and infrastructure (think of the value of SOA relevant to process, people and technology).

Having just read a few comments on a Linkedin discussion around SOA, the feeling I get is that the approach of SOA is still dominated (and hijacked) by IT and development, rather than to include the considerable benefit of a holistic, business and technology approach in the utilisation of SOA.

Admittedly the origins of SOA sits in systems design principals for development and integration to facilitate the multiple applications of services, but it is of vital that the actual business operational processes and structure requires/support the reusability of functionality or information.
In this context, the Service orientated architecture fits very well in the business design where the business operational architecture utilises the same theoretical approach as the classic software based SOA. In fact, the two poles can actually be drawn significantly closer when the technology SOA side mirrors the business SOA side and then draw the application lines through the linking of the relevant information (irrespective of the technology interface be it xml or a web service based exchange).

In business redesign and process optimisation, the application of SOA is actually very prevalent - most of these change activities are centred around reduction of duplication, simplification of processes and the specific reuse of information and activities, thereby reducing the actual operational load while ensuring that all functions are executed effectively. It is with this in mind that I approach both the technology and business architecture from an integrated SOA, where business (people and process) is the dictator of the technology requirements (technology is just a resource, though of high value to enable optimal business function...some times even to drive optimisation) and the application, information and infrastructure architecture is designed to ensure that it effectively and efficiently support the business operational needs - creating the mirror SOA for a holistic Enterprise Architecture.

LEGO - the easy way to explain server virtualisation

I stumbled on this very cool and simple explanation of server virtualisation using LEGO...while browsing through the archives of one of my favourite blogs, Brick Brothers.



I have previously mentioned my love for LEGO and that I have used it for work purposes as well, but this must be one of the best uses of LEGO to demonstrate something business related.

Even though my work focus mainly on the strategic architecture of entire organisations (business, operational and integration approaches during change), the technical Enterprise Architecture/infrastructure questions around virtualisation are frequently asked. I don't think I can explain it any better (or easier).

BlueLock, thanks for helping me answer this topic in the future, and Brick Brothers for providing such a cool view on LEGO use.

Note - I'm not endorsing BlueLock, the company behind the video using Lego to explain server virtualisation. I take a merchant/provider independent approach in all my engagements, focusing on the most appropriate and viable solutions for the specific customer, while considering all known external and internal factors during the change.

Confluxes - the business ecosystem in perspective

On Saturday we, opend Confluxes for businesses all over the world after a period of running the service only on a closed network for a few hundered businesses.
Confluxes is still in Beta, but have already had a number of business registering them selves and definign their business relationships, products/services and requirements.
Over then coming weeks Confluxes will see a transformation that will greatly add to a smooth user experience and intuitive interaction...as well as to improve the look and feel of the service that is currently in Beta.

Confluxes (plural of Conflux), as the name indicates, is the point where business come together from various value chains to create an exponentially expanding value network, where through collaboration the individual businesses can achieve far greater success within the business ecosystem.

"Buy, sell, collaborate…businesses are part of an ever evolving ecosystem. Each business has an influence on others and business can’t exist in isolation."
Confluxes empowers businesses to work better together in achieving greater success in the business ecosystem

Confluxes is focused on small/medium businesses, to provide an effective platform for them to drive market inter action, by factoring their unique business context in an ever expanding and dynamic value network.

The Objective behind Confluxes is to create an extensive and dynamic business ecosystem platform to drive effective opportunity and solution discovery for small/medium businesses, and to enable inter-business collaboration.

One of the key enablers of the Confluxes platform is the applied intelligence within a multi dimensional network that can accurately profile and contextualise a business within the greater value network.

Confluxes aggregates diverse bits of information and uses a bit of AI (a combination of applied chaos theory, combinatorial optimisation and complexity analysis) to contextualise a business in relation to the greater business ecosystem and to also weave their extended value network reach based on the specific business' customers, suppliers and partners. A business defines itself by confirming their relationship with other businesses already registered on (Confluxes intuitively identify potential duplications) the value network platform or by inviting their customers/suppliers/partners to register on Confluxes and confirm the relevant relationship.
All these relationship connections and the extended reach through the value network, and businesses' specific products/services and requirements (and the various platform integrated communication, collaboration and transaction tools) creates thee dynamic and intelligent business ecosystem.

Confluxes uses a business' unique perspective on the business ecosystem to provide market intelligence, discover relevant opportunities, identify appropriate suppliers/providers and facilitate inter business collaboration.

The key benefits of Confluxes are:

• Effective and automated business opportunity discovery
• Efficient and accurate solution and provider identification
• Drives and facilitates inter-business collaboration
• Exponentially expands a business’ reach and market exposure within the greater value network

Take advantage of getting in on the platform at an early stage, register and start building your value network and benefit from truly using the business ecosystem.

Is Business a Zero-Sum Game?

A Zero-Sum game is a situation where there is no 'win-win' possibility, where whatever a party/player gains is matched by a commensurate loss by other players, so it always comes out even.

As Wikipedia puts it:
"If the total gains of the participants are added up, and the total losses are subtracted, they will sum to zero. Zero-sum can be thought of more generally as constant sum where the benefits and losses to all players sum to the same value of money (or utility). Cutting a cake is zero- or constant-sum, because taking a larger piece reduces the amount of cake available for others."

Like any ecosystem, the various players (creatures or business entities) will each strive to do the best for it self. This demands that ultimately another player (not necessarily directly connected) will experience an impact that is detrimental to them on a whole (from an out side view), but this required to sustain the entire ecosystem.

In my oppinion, it is not really a zero-sum game, but rather a game of the fittest will survive and those that want to succeed will have to evolve to ensure that they also thrive (or survive) in a competitive and changing environment.

The business ecosystem also follows chaos theory (where there is order in the apparent chaos), system dynamics and entities will/must display self determination.
In the business value network there will always be business that lose out on a opportunity to another bidder, but this either ensure that the better business survive or thrive – except where there is lack of intelligence, clarity of market demands and opportunity, or subjective business behaviour (such as collusion or nepotism – all which will ultimately be to the detriment of those involved) – so where perspective based insight, objectivity and evidence base decision making is used, the negatives should be encountered in another area.

All this stated, each business (and creature in an ecosystem) will at some point need to experience a negative exchange as part of a zero-sum game in a specific ecosystem.

It isn't really zero-sum...just winners and losers

Global market ecosystem and Economic architecture

Seems like I have been a bit too busy working (not really a good excuse) and keep forgetting (neglecting) to publish, so there will hopefully be a few posts coming more regularly - first one in....

Our world, the global economy, the mess we are in made me think of the wider ecosystem, beyond the reaches of a single enterprise, but the entire global market.

Incidentally, I noticed there was a discussion started on one of the Linkedin groups where I contribute on the topic of "The future of EA in Government. What should stay, What should go?" - now it is more related to management approaches like BPR, ITIL, Agile, etc. (more to come on EA in relation to all the other methods/concepts/approaches/frameworks/etc.), but I thought it is also very relevant if we let our minds wonder for a bit and "investigate" if such economic horrors as seen recently can be avoided (or rather subdued) if “Economic Architecture” was implemented and exploited, similar to what Enterprise Architecture within a "contained" company/enterprise ecosystem?

I'm talking about the higher levels of architecture, not necessarily down to the lowest level of detail (though there might be value in looking at even the smallest things in an ecosystem.

Would we (and more pointing to governments, regulators and businesses) have been able to gain advance insight into what future impact there might be linked to current actions.

If we do implement an approach to economic architecture (or really a global market ecosystem), then there should be an approach similar to what Enterprise Architecture, with a similar value and benefit aspect...though there will be a far more complex application of chaos theory, but in essence we should be able to explore potential risk areas, discover areas requiring change, model solutions where change were required...and in the unfortunate case of something horribly happening, to be able to discover the root cause through “reverse chaos theory”, to ensure that the right corrective (change) measures is put in place and that the change would not just a short lived positive impact to some, but that a sustainable and symbiotic effect.
If applied correctly (though in theory, practice is science fiction at the moment in my view) we should be able to avoid potential future disaster states, instead of the usual desired state...for now.