Archive

Posts Tagged ‘systems’

Growing Wings On The Way

September 17, 2011 Leave a comment

If you don’t have wings and you jump off a cliff, you better hope to grow a pair before you go splat. With this lame ass intro, I introduce you to the title of the latest systems thinking book that I finished reading: “Growing Wings On The Way“.

GWOTW is yet another terrific systems thinking book from small British publishing house “Triarchy Press“. The book defines and explains a myriad of tools/techniques for coming to grips with, understanding, and improving, socio-technical “messes“. Through numerous examples, including a very personal one, Rosalind Armson develops the thought processes and methods of inquiry that can allow you to generate rich pictures, influence diagrams, system maps, multiple-cause diagrams, and human activity system diagrams for addressing your “messes“. If you want a solid and usable intro to soft systems thinking, then this may be your book.

SOI Sauce

May 9, 2011 2 comments

Assume that you’re given a bounded “System Of Interest” (SOI) you desperately want to understand. Cuz it’s a ‘nuther whole can of worms, please suspend “reality” for a moment and fuggedaboud who defined the SOI boundaries and plopped it onto your lap to study.

So, where and how do you start attacking the task at hand? Being a member of a western, logical, science-revering culture, you’ll most likely take the analysis path as depicted in the left side of the figure below. You’d try to discern what the SOI’s elemental parts are (forming your own arbitrary part-boundaries, of course) and how each of the parts behaves independently of the others. After performing due diligence at the parts level, you’d aggregate the fragmented part-behaviors together into one grand theory of operation and voila….. you’re done! Because the reductionist approach doesn’t explore the why of the SOI, you’d  most likely be wrong. If one or more of the system “parts” is self-purposeful, uh, like people, you’d most likely be 100% wrong.

A complementary approach to understanding a SOI concerns formulating the why of the system – first. As the right-side path in the above figure conveys, the synthesis approach to understanding starts with the exploration of the super-system that contains the SOI. Upon gaining an understanding of the operational context of the SOI within its parent system (the why), the what and the how of the SOI’s parts can be determined with greater accuracy and insight.

The figure below illustrates side-by-side state machine models of the two approaches toward system understanding. Which one best represents the way you operate?

Feedback Insertion

October 18, 2010 Leave a comment

Let’s say that you come up with a great product idea that is both wanted and needed by a large market (ka-ching!). Let’s also say that your product is non-trivial and it requires specialized expertise to produce it from raw inputs to its value-added end state. After mustering up enough courage and scrounging up enough money, you become an entrepreneur – whoo hoo! So, you design the system below, hire the expertise you need, and kick off the enterprise. Of course, you rightly put yourself in the controller position and serve as the system coordinator.

Uh, what’s missing from your design? Does the next picture below help? Still can figure it out?

Is feedback missing? Even though your customers need and want and buy your product, how do you know when/if your quality goes down hill and/or your customers want and need new features? Voila! You figure it out and design/install a feedback channel from your customers to you, and only you:

By responsively acting on customer inputs on your new feedback channel, you steer, guide, and direct your team back on track – until the complaints on the feedback channel start rising again. What’s wrong with your system now? Does the system augmentation below answer the question?

Because of increasing product complexity and your lack of in depth knowledge of it, (if you’re not an egomaniacal control freak,) you own up to the possibility that you could be misunderstanding and filtering out some customer feedback and you could be directing your team poorly. Accepting your humility, you set up a second feedback channel from your customers directly to your development team.

Now you’re back on track again – whoo hoo! But wait, something goes awry again and the customer complaint rate starts rising again. Since feedback solved your problems before, you set up additional feedback channels between yourself and your producer team and between your sub-teams:

Will this latest system enhancement work? Hell, I don’t know. Complexity begets complexity. Your increasingly complex system design might implode because of all the communication channels in the system and the fragmentation of contradictory messages that flow at high rates within the channels. If it doesn’t work, you could keep experimenting with changes to fine tune the system for stability and robustness.

The figure below shows yet another system enhancement possibility – the addition of another controller to ensure that the production sub teams receive coherent and filtered info from your customers. It may work, but it will fail if your second controller issues guidelines, advice, commands, and orders to your production team that contradict yours.

To solve your cross-management problem, you can setup a two way channel between yourself and your second controller to resolve contradictions and ambiguities:

So, what’s the point of this long and boring, multi-picture post? Geez, I don’t know. I wrote it on the fly, in a stream of consciousness with no pre-planned point in mind.

But wait, a possible answer to the question just popped into my head out of nowhere. The point of this post is to keep adapting and trying new things when your external environment keeps changing – which it always will. One thing is for sure: don’t design your operation like the very first picture in this post – open loop. Ensure that feedback channel(s) from your customers are in place and the information that flows on it (them) is acted upon to keep your product in synch with your customers.

Sheesh, I’m finally done!

Deterministic, Animated, Social

September 5, 2010 Leave a comment

Unless you object, of course, a system can be defined as an aggregation of interacting parts built by a designer for a purpose. Uber systems thinker Russell Ackoff classified systems into three archetypes: deterministic, animated, and social. The main criterion Ackoff uses for mapping a system into its type is purpose; the purpose of the containing whole and the purpose(s) of the whole’s parts.

The figure below attempts to put the Ackoff  “system of system types” :) into graphic form.

Deterministic Systems

In a deterministic system like an automobile, neither the whole nor its parts have self-purposes because there is no “self”. Both the whole and its parts are inanimate objects with fixed machine behavior designed and assembled by a purposeful external entity, like an engineering team.  Deterministic systems are designed by men to serve specific, targeted purposes of men. The variety of behavior exhibited by deterministic systems, while possibly being complex in an absolute sense, is dwarfed by the variety of behaviors capable of being manifest by animated or social systems.

Animated Systems

In an animated system, the individual parts don’t have isolated purposes of their own, but the containing whole does. The parts and the whole are inseparably entangled in that the parts require services from the whole and the whole requires services from the parts in order to survive.  The non-linear product (not sum) of the interactions of the parts manifest as the external observable behavior of the whole. Any specific behavior of the whole cannot be traced to the behavior of a single specific part. The human being is the ultimate example of an animated system. The heart, lungs, liver, an arm, or a leg have no purposes of their own outside of the human body. The whole body, with the aid of the product of the interactions of its parts produces a virtually infinite range of behaviors. Without some parts, the whole cannot survive  (loss of a functioning heart). Without other parts, the behavior of the whole becomes constrained (loss of a functioning leg).

Social Systems

In a social system, the whole and each part has a purpose. The larger the system, the greater the number and variety of the purposes. If they aren’t aligned to some degree, the product of the purposes can cause a huge range of externally observed behaviors to be manifest. When the self-purposes of the parts are in total alignment with whole, the system’s behavior exhibits less variety and greater efficiency at trying to fulfill the whole’s purpose(s). Both internal and external forces continually impose pressure upon the whole and its parts to misalign. Only those designers who can keep the parts’ purpose aligned with the whole’s purpose have any chance of getting the whole to fulfill its purpose.

System And Model Mismatch

Ackoff states that modeling a system of one type with the wrong type for the purpose of improving or replacing it is the cause of epic failures. For example, attempting to model a social system as a deterministic system with an underlying mathematical model causes erroneous actions and decisions to be made by ignoring the purposes of the parts. Human purposes cannot be modeled with equations. Likewise, modeling a social system as an animated system also ignores the purposes of the many parts. These mismatches assume the purposes of the parts align with each other and the purpose of the whole. Bad assumption, no?

Go, Go Go!

August 6, 2010 Leave a comment

Rob Pike is the Google dude who created the Go programming language and he seems to be on a PR blitz to promote his new language. In this interview, “Does the world need another programming language?”, Mr. Pike says:

…the languages in common use today don’t seem to be answering the questions that people want answered. There are niches for new languages in areas that are not well-served by Java, C, C++, JavaScript, or even Python. – Rob Pike

In Making It Big in Software, UML co-creator Grady Booch seems to disagree with Rob:

It’s much easier to predict the past than it is the future. If we look over the history of software engineering, it has been one of growing levels of abstraction—and, thus, it’s reasonable to presume that the future will entail rising levels of abstraction as well. We already see this with the advent of domain-specific frameworks and patterns. As for languages, I don’t see any new, interesting languages on the horizon that will achieve the penetration that any one of many contemporary languages has. I held high hopes for aspect-oriented programming, but that domain seems to have reached a plateau. There is tremendous need to for better languages to support massive concurrency, but therein I don’t see any new, potentially dominant languages forthcoming. Rather, the action seems to be in the area of patterns (which raise the level of abstraction). – Grady Booch

I agree with Grady because abstraction is the best tool available to the human mind for managing the explosive growth in complexity that is occurring as we speak. What do you think?

Abstraction is selective ignorance – Andrew Koenig

Arbitrary Boundaries

Processes, Threads, Cores, Processors, Nodes

May 27, 2010 2 comments

Ahhhhh, the old days. Remember when the venerable CPU was just that, a CPU? No cores, no threads, no multi-CPU servers. The figure below shows a simple model of a modern day symmetric multi-processor, multi-core, multi-thread server. I concocted this model to help myself understand the technology better and thought I would share it.

The figure below shows a generic model of a multi-process, multi-threaded, distributed, real-time software application system. Note that even though they’re not shown in the diagram, thread-to-thread and process-to-process interfaces abound. There is no total independence since the collection of running entities comprise an interconnected “system” designed for a purpose.

Interesting challenges in big, distributed system design are:

  • Determining the number of hardware nodes (NN) required to handle anticipated peak input loads without dropping data because of a lack of processing power.
  • The allocation of NAPP application processes to NN nodes (when NAPP > NN).
  • The dynamic scheduling and dispatching of software processes and threads to hardware processors, cores, and threads within a node.

The first two bullets above are under the full control of system designers, but not the third one. The integrated hardware/software figure below highlights the third bullet above. The vertical arrows don’t do justice to the software process-thread to hardware processor-core-thread scheduling challenge. Human control over these allocation activities is limited and subservient to the will of the particular operating system selected to run the application. In most cases, setting process and thread priorities is the closest the designer can come to controlling system run-time behavior and performance.

Follow

Get every new post delivered to your Inbox.

Join 465 other followers

%d bloggers like this: