Saturday, September 17, 2011

Organic Architecture. Part 1

Organic - "4a. Forming an integral element of a whole" / "4b. Having systematic coordination of part" - Merriam Webster Dictionary

Most of you may assume I'm referring to the works of people like Frank Lloyd Wright, or some artist or sculptor.  Close, but no cigar, at least not yet.

I'm going to try to dive into a rather nebulous and obscure topic within the microcosm of software/systems architecture: a term one of my professors once used: "organic architecture".  He didn't articulate this in class, but he did so during a private discussion, and I've always held it in the back of my head when concocting any "solution" to a systematic challenge.  Basically, it denotes the pursuit of designing and building something that just feels "natural".

Trying to quantify that definition would be about as simple as quantifying what makes you feel love or sadness (or what my wife wants for dinner).  But I'm going to try to smoke out some constraints by example to help develop a shape to this concept.  It's going to require multiple parts in order to properly dissect this invisible beast, so hopefully you can (and will want to) bare with me on this journey into nerdville.

Organic Architecture plays a major part in many aspects of our lives and our environment.  From things we participate in, to the tools we use, and the machines we operate and travel within.  It's an inherent part of bio-medicine and chemical engineering, as well as traffic management systems and air traffic control.  It's everywhere.  Rather than try to tie a rope around something this broad in scale, I'm going to break off the tiny chunk that pertains to computer software architecture.

Why?

I really don't know.  It's raining.  My wife is on travel and the house is quiet.  I've been cleaning, cooking, eating, and hanging out with my kids, the cat and dog.  It's one of those brain-incubator environments where the mind wanders and tends to develop ideas that beg to be externalized.  Whoa! I think I just said something logical?  Maybe not.  In any case, this is one small area of software technology that doesn't get much discussion or illumination, anywhere; Not in schools, or conferences or in the workplace.  There are a few books that discuss this but most are obscure and way outside the mainstream for even the geekiest of geeks.  Typically, it is hinted at, rather than outright bagged and tagged.  Some examples I may touch on:
  • Interface Design
  • Systems Management Architecture
  • Configuration Management Architecture
  • Systems State Management
  • Workflow Design
  • Self-Healing Processes

Example 1 - Agent vs Agentless

You've probably heard this term before.  It's used by quite a few products and technologies.  It refers to a basic concept of where nodal processing is performed within a distributed system.  But this concept is not confined to software or technology at all.  It's used in the intelligence community, as it pertains to HUMINT versus SIGINT (geeks, you may commence to beating off over the acronyms... now!).

An "agent" in this context would refer to a component or process which runs on a remote node within a distributed system.  The agent performs the majority of processing locally. In most scenarios, the agent receives general "instructions" or control parameters from a higher "authority" or higher node in the system.  It also typically transmits the results of its processing to a higher authority or node in the system.  A biological example of this would be nerve receptors within the nervous system in the human body.  A computer example would be monitoring agents deployed as part of a systems management technology (e.g. Microsoft System Center Operations Manager®).

An "agentless" scenario would be one where nodes are not configured with any distinct autonomous processing components, but instead are acted upon directly from external/remote nodes in the system.  A social reference example of this would be cash registers in most modern shopping centers (when the power goes out, they cannot function on their own).  A computer example would be a web application, or remote systems data interrogation (think file systems, CIM (WMI), registry, event logs, etc.).

A "system", according to Merriam Webster's Dictionary, can be many things, but in simplest terms: it is a collective body of elements or components that participate in some common goal or outcome.  A football team is a system.  A McDonalds hamburger is a system.  A government is a system.  A farm is a system.

A "distributed system" is not clearly defined by any official dictionary (at least, none that I've encountered), but it basically builds atop the "system" concept to include a qualification of having elements or components which are not physically collocated or in close "proximity".

Putting all of these things together you get one of two distinct concepts for monitoring and managing a distributed collection of components:
  • Agent - components are deployed to each member of the system to perform most of the querying and maintenance of the node locally.
  • Agentless - members of the system are managed directly from a central node (or hierarchical layer node).
This general concept is used for all sorts of functions within a computer system (i.e. network environment).  It's used by software licensing services (e.g. Flexera FlexLM® and FlexNet®), distributed processing (i.e. 3DS Max® "net rendering"), and so on.

Summary

Why is it important or even worthy of knowing about this stuff?  Because the more you see the basic concepts laid out, the more familiar you will be to the "50,000 foot view".  The 50,000 foot view is important because it provides the most general, basic understanding of how something works.  It's how you explain something to someone else who has absolutely no insight or understanding about anything remotely related to the thing you are explaining.  It's also how you keep things in context when a slick vendor rep is pumping your hand and waiting for your signature on the P.O. after he tries to bullshit you into believing they have inventing something "radically new".

In most cases, the "radical" stuff has been around since the 1950's and 1960's (the last era when people actually used their brains to invent new things).  Ever since, most of everything labeled "new" is really a refinement or repackaging of something old.  Knowing what snake oil is, helps you spot new snake oil.

Next Part - Nodal and Agent Autonomy

No comments: