Archive

Posts Tagged ‘systems’

A Skeptical “No”

May 5, 2014 7 comments

Just about every agile video, book, and article I’ve ever consumed assumes some variant of the underlying team model shown below. The product these types of teams build is comprised of custom software running on off-the-shelf server hardware. Even though it’s not shown, they also assume a client-server structure, request-response protocol, database-centric system.

SW only

The team model for the types of systems I work on is given below. They are distributed real-time event systems comprised of embedded, heterogeneous, peer processors glued together via a pub-sub protocol. By necessity, specialized, multi-disciplinary teams are required to develop this category of systems. Also, by necessity, the content of the sprint backlog is more complex and intricately subtler than the typical agile IT product backlog of “features” and “user stories“.

SW and HW

When I watch/read/listen to smug agile process experts and coaches expound the virtues of their favorite methodology using narrow, anecdotal, personal stories from the database-centric IT world, I continuously ask myself “can this apply to the type of products I help build?“. Often, the answer is a skeptical “no“. Not always, but often.

A Danger To Themselves And Others

May 16, 2013 3 comments

“Efficient systems are dangerous to themselves and others” – John Gall

A new system is always established with the goal of outright solving, or at least mitigating, a newly perceived problem that can’t be addressed with an existing system. As long as the nature of the problem doesn’t change, continuously optimizing the system for increased efficiency also joyfully increases its effectiveness.

However, the universe being as it is, the nature of the problem is guaranteed to change and there comes a time where the joy starts morphing into sorrow. That’s because the more efficient a system becomes over time, the more rigid its structure and behavior becomes and the less open to change it becomes. And the more resistant to change it becomes, the more ineffective it becomes at achieving its original goal – which may no longer even be the right goal to strive for!

Eff vs Eff

In the manic drive to make a system more efficient (so that more money can be made with less effort), it’s difficult to detect when the inevitable joy-to-sorrow inflection point manifests. Most managers, being cost-reduction obsessed, never see it coming – and never see that it has swooshed by. Instead of changing the structure and/or behavior of the system to fit the new reality, they continue to tweak the original structure and fine tune the existing behaviors of the system’s elements to minimize the delay from input to output. Then they are confounded when (if?) they detect the decreased effectiveness of their actions. D’oh! I hate when that happens.

Thought Actual

Sensors AND Actuators


Sensors And Actuators

D4P4D

May 11, 2012 6 comments

I just received two copies of William Livingston’s “Design For Prevention For Dummies” (D4P4D) gratis from the author himself. It’s actually section 7 of the “Non-Dummies” version of the book. With the addition of  “For Dummies” to the title,  I think it was written explicitly for me. D’oh!

The D4P is a mind bending, control theory based methodology (think feedback loops) for problem prevention in the midst of powerful, natural institutional forces that depend on problem manifestation and continued presence in order to keep the institution alive.

Mr. Livingston is an elegant, Shakespearian-type writer who’s fun to read but tough as hell to understand. I’ve enjoyed consuming his work for over 25 years but I still can’t understand or apply much of what he says – if anything!

As I slowly plod through the richly dense tome, I’ll try to write more posts that disclose the details of the D4P process. If you don’t see anything more about the D4P from me in the future, then you can assume that I’ve drowned in an ocean of confusion.

Complementary Views

March 8, 2012 2 comments

One classic definition of a system is “a set of interacting parts that exhibits emergent behavior not attributable solely to one part“. An alternative, complementary definition of a system served up by Russell Ackoff is “a whole that is defined by its function in a larger system of which it is a part“.

The figure below models the first definition on the left and the second definition on the right. Neither is “righter” than the other. They, and I love saying this because it’s frustratingly neutral, “just are“.

Viewing a system of interest from multiple viewpoints provides the viewer with a more holistic understanding of the system’s what, how, and why. Problem diagnosis and improvement ideas are vastly increased when time is taken to diligently look at a system from multiple viewpoints. Sadly, due to how we are educated, the inculcated tendency of most people is to look at a system from a single, parochial viewpoint: “what’s in it for me?“.

A Thing In Context

January 11, 2012 2 comments

Can’t And May

January 7, 2012 Leave a comment

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!

Follow

Get every new post delivered to your Inbox.

Join 455 other followers

%d bloggers like this: