What Do Birds Have to Do with Enterprise Architecture?

Lots of complexity in life. The business world is one of them. With current technological advancements, the business world is affected. Like it or not, he must follow the ‘rules’.

Enterprise IT is facing a difficult conundrum. On one hand, it’s being asked to improve its agility, alignment with the business, and ability to innovate. At the same time, though, it’s expected to adhere to existing constraints such as completeness, efficiency, and security. Enterprise Achitecture struggles to address this conundrum with seemingly mutually exclusive strategies. The need for completeness, efficiency, and security calls for centralized governance. The need for agility and creativity points in the opposite direction. Is it possible to unify them? I believe an answer could come from naturally occurring complex adaptive systems such as flocks of birds and schools of fish.

Complex Adaptive Systems

Courtesy : i.pinimg.com

Simplistically put, complex adaptive systems have the following characteristics:

  1. They consist of large numbers of independent agents
  2. These agents interact with each other and with the surrounding environment
  3. Each agent pursues local goals based on a relatively simple set of rules
  4. There are no explicit rules defining the overall collective behavior
  5. The collective behavior emerges implicitly from the actions of the agents in adherence to their local rules
  6. The emergent behavior is both coherent and flexible

Three Simple Rules

Courtesy :www.sheknows.com

Again simplistically put, members of a flock follow three simple rules:

  1. Separation: Don’t get too close to your immediate neighbors
  2. Alignment: Travel in the same approximate direction as your neighbors
  3. Cohesion: Travel towards the same approximate position as your neighbors

These rules are all that’s needed to create elegant, consistent “flocks”. At the same time, though, a flock is flexible and adaptable. If it encounters a shark or a windmill, it doesn’t mindlessly swim or fly into it. Instead it splits apart to avoid the threat or obstacle, then comes back together afterwards.
Solution to the Enterprise Architecture conundrum
It occurs to me that “flocking” might provide a solution to the Enterprise Architecture conundrum. By not relying on centralized imposition of global rules, it avoids compromising agility and creativity. By leveraging the right set of local rules, it generates coherency and efficiency through emergent behavior. Emergent behavior also has the potential to solve scalability problems that plague centralized-governance as well as agile methodologies.

Courtesy : img.okeinfo.net

To be honest, at this point I have no idea what the agent-level rules should be. I think it would be interesting to explore possible rule sets based on the natural-world flocking rules: separation, alignment, and cohesion. Imagine each agent as a “two-pizza team” within a radically Service-Oriented Architecture. Each team could follow rules along the lines of:

  1. Separation: don’t get too tightly coupled with other services upon which you depend. Use techniques like circuit breaker patterns to mitigate those services’ ability to risk your own availability or scalability. Abstract your interfaces with other services to allow yourselves to shift relationships as needed.
  2. Alignment: be prejudiced to use technologies similar to those used by your neighbors. If, for example, all your surrounding neighbors use Ruby and Linux, seriously question a suggestion to use Cobol for AS/400. On the other hand, if one service within the architecture does decide to use .NET/Windows instead of Ruby/Linux, it will set up a small amount of momentum that could eventually lead to enterprise-wide migration in that direction.
  3. Cohesion: be prejudiced to prioritize similar features and requirements as your neighbors, track similar schedules, and so on.

Other rules could involve team makeup. Yammer, for example, puts an interesting twist on the two-pizza team SOA approach. At the end of every project, the project team is dissolved. Members re-coalesce in new combinations on other teams for other projects. Knowledge, learning, and prejudices are thus disseminated through the organization.

These rule sets are no more than suggested starting points. More work also needs to be done to define what compromises a “neighbor”. One way or another, though, Enterprise IT has to solve its conundrum. I believe that “flocking” in particular, and complex adaptive systems in general, are promising approaches to the problem. I’m interested in continuing the dialogue and exploring potential flocking rules that could generate emergent IT practices which solve problems of governance, efficiency, security, agility, alignment, and innovation.

Post Comment