Form Follows Function on SPaMCast 442

SPaMCAST logo

A new month brings a new appearance on Tom Cagley’s Software Process and Measurement (SPaMCast) podcast.

This week’s episode, number 442, features Tom’s excellent essay on capability teams (highly recommended!), followed by a Form Follows Function installment based on my post “Systems of Social Systems and the Software Systems They Create”. Kim Pries bats cleanup with a Software Sensei column, “Software Quality and the Art of Skateboard Maintenance”.

In this episode, Tom and I continue our discussion on the organizations as system concept and how systems must fit into their context and ecosystem. In my previous posts on the subject, I took more of a top down approach. With this post, I flipped things around to a bottom up view. Understanding how the social and software systems interact (including the social system involved in creating/maintaining the software system) is critical to avoid throwing sand in the gears.

You can find all my SPaMCast episodes using under the SPaMCast Appearances category on this blog. Enjoy!

Systems of Social Systems and the Software Systems They Create

I’ve mentioned before that the idea of looking at organizations as systems is one that I’ve been focusing on for quite a while now. From a top-down perspective, this makes sense – an organization is a system that works better when it’s component parts (both machine and human) intentionally work together.

It also works from the bottom up. For example, from a purely technical perspective, we have a system:

Generic System

However, without considering those who use the system, we have limited picture of the context the system operates within. The better we understand that context, the better we can shape the system to fit the context, otherwise we risk the square peg in a round hole situation:

Generic System with Users

Of course, the users who own the system are also only a part of the context. We have to consider the customers as well:

Generic System with Users and customers

Likewise, we need to consider that the customers of some systems can be internal to the organization while others are external. Some of the “customers” may not even be human. For that matter, sometimes the customer’s interface might be a human (user) rather than software. Things get complicated when we begin adding in the social systems:

Generic EITA with Users and customers

The situation is even more complicated than what’s seen above. We need to account for the team developing and operating the automated system:

Generic System with Users, customers, and IT team

And if that team is not a unified whole, then the picture gets a whole lot more interesting:

Generic System with Users, customers, and IT teams

Zoomed out to the enterprise level, that’s a lot of social systems. When multiplied by the number of automated systems involved, the number easily becomes staggering. What’s even more sobering is reflecting on whether those interactions have been intentionally structured or have grown organically over time. The interrelationship of social and software systems is under-appreciated. A series of tweets from Gregory Brown last week makes the same case:

A number of questions come to mind:

  • Is anyone aware of all the systems (social and software) in play?
  • Is anyone aware of all the interactions between these systems?
  • Are the relationships and interactions a result of intentional design or have they “just happened”?
  • Are you comfortable with the answers to the first three questions above?

Storming on Design

From Wikimedia: VORTEX2 field command vehicle with tornado in sight. Wyoming, LaGrange.

My youngest son has recently fallen in love with the idea of being a storm chaser when he gets older. Tweet storms are more my speed. There was an interesting one last week from Sarah Mei regarding the contextual nature of assessing design quality:

Context is a recurring theme for me. While the oldest post with that tag is just under three years old, a search on the term finds hits going all the way back to my second post in October, 2011. Sarah’s tweets resonated with me because in my opinion, ignoring context is a fool’s game.

Both encapsulation and silos are forms of separation of concerns. What differentiates the two is the context that makes the one a good idea and the other a bad idea. Without the context, you can come up with two mutually exclusive “universal” principles.

A key component of architectural design, is navigating the fractals that make up the contexts in which a system exists. Ruth Malan has had this to say regarding the importance of designing “outside the box”:

Russell Ackoff urged that to design a system, it must be seen in the context of the larger system of which it is part. Any system functions in a larger system (various larger systems, for that matter), and the boundaries of the system — its interaction surfaces and the capabilities it offers — are design negotiations. That is, they entail making decisions with trade-off spaces, with implications and consequences for the system and its containing system of systems. We must architect across the boundaries, not just up to the boundaries. If we don’t, we naively accept some conception of the system boundary and the consequent constraints both on the system and on its containing systems (of systems) will become clear later. But by then much of the cast will have set. Relationships and expectations, dependencies and interdependencies will create inertia. Costs of change will be higher, perhaps too high.

This interrelationship can be seen from the diagram taken from the same post:

System Context illustration, Ruth Malan

It’s important to bear in mind that contexts are multi-dimensional. All but the very simplest of systems will likely have multiple types of stakeholders, leading to multiple, potentially conflicting contexts. Accounting for these contexts while defining the problem and while designing a solution appropriate to the problem space is critical to avoiding the high costs Ruth referred to above.

Another takeaway is that context can (and likely will) change over time. Whether it’s changes in terms of staffing (as Sarah noted) or changes in the needs of users or changes in technology, a design that was fit for yesterday’s context can become unfit for today’s and a disaster for tomorrow’s.

Skating to Where the Puck Will Be

Wayne Gretzky

I skate to where the puck is going to be, not where it has been.

 

Business people have a thing for sports metaphors, and this one in particular is a favorite. So much so, that Jason Kirby in “Why businesspeople won’t stop using that Gretzky quote” observed:

Its popularity has much to do with the ego of businesspeople who think they’re the Gretzkys of their industry. But, more than that, it appeals, in a way no other sports cliché does, to the current obsession with that other insidious buzzword, innovation. Get ahead of the competition by figuring out what the market will look like five years from now, says the management consultant to the client, while handing him a substantial bill. It’s that simple.

Of course, it’s not. Gretzky’s uncanny ability to read plays has never been matched. The hockey world has yet to produce another player capable of coming close to matching his record. Which makes the adoption of his quote by businesspeople all the more empty and galling. Warren Buffett can get away with it. Maybe Steve Jobs. But that’s it.

Do you have to be a Gretzky, or a Buffett, or a Jobs in order to get it right?

Prediction is very difficult, especially if it’s about the future.

 

Nonetheless, difficult is not the same as impossible. Likewise, the future can be a very big target. Hitting the bits far down the road will be much more difficult than those closer in.

Greger Wikstrand and I have been discussing that “insidious buzzword”, innovation, for more than six months now. This post is the 23rd in the series.

Given the pace of change, “insidious buzzword” seems a bit dismissive. Someone born in 1903 when the Wright brothers first flew what was essentially a motorized kite might just be retiring in 1969 when the Concorde first flew. Almost an entire Radio Shack ad from 25 years ago is now available in the form of a cell phone (for a lot less money as well). Doubtless, some people misuse the term. The phenomenon, however, is very real.

So let’s return to the question of ability to anticipate change. Do you have to be a Gretzky, or a Buffett, or a Jobs in order to get it right? I think that’s a facile opinion, the Great Man theory applied to technology and business.

Greger’s last post, “Inevitable change”, contains part of the reason why I think it’s intellectually lazy to think that innovation is the province of the superstar:

Most changes in evolution are small. They are not big morphological changes. They are small physiological and immunological changes. The ability to resist new disease and the ability to consume new food is much more important than the (seemingly) bigger changes.

In his post, Greger talks about punctuated equilibrium versus phyletic gradualism, sudden radical change versus constant small incremental changes over time. In my opinion, it’s a combination. Species (and organizations) can reach a point where they are no longer fit for the ecosystem they inhabit. They reach that point, however, by degrees.

Likewise, Gretzky skated to where the puck would be, not in one leap, but step by step. Iterative sense-making and decision-making is, in my opinion, far more likely to lead to long-term consistent success than superhuman leaps of intuition. Rather than requiring just the right move at just the right time, what’s needed is awareness and adaptation. Constant, intentional learning is required to ward off the inertia that can be so deadly in an ever-changing environment.

Innovation is a matter of making changes to remain relevant/fit as the environment around you changes. Sometimes those changes may be sudden, but even gradual change can seem sudden to those standing still.

The straw that broke the camel’s back didn’t weigh any more than those that didn’t. It just happened to be one too many. That means there were lots of opportunities to move right up until there weren’t any more.

[Wayne Gretzky photo by Håkan Dahlström via Wikimedia Commons]

Learning to Deal with the Inevitable

On Reconnaissance, Józef Brandt, 1876

 

My last post, “Barriers to Innovation”, began with a question. Is innovation inevitable? By the end of the post, that question had changed. Is innovation inevitable for your organization? Tom Cagley left a comment suggesting another change:

Think about changing the question again. “Is innovation inevitable?” might be better stated as “Is change inevitable?” The answer to the latter question is yes but no to the former. Change and innovation do not have the same thing.

Tom’s comment was, of course, right on the money. Change is inevitable and while all innovation is change, not all change is innovation. Scott Berkun’s definition of innovation is still my favorite:

If you must use the word, here is the best definition: Innovation is significant positive change. It’s a result. It’s an outcome. It’s something you work towards achieving on a project. If you are successful at solving important problems, peers you respect will call your work innovative and you an innovator. Let them choose the word.

Change, however, is not guaranteed to be either significant or positive. It will, however, be. It may be unwanted, it may be denied, but it not will be avoided. Organizations, like organisms, demonstrate their fitness for purpose via adapting to change. Organizations, like organisms, die when their ecosystems change around them and they fail to follow suit. Research in Motion, who quickly went from leader to laggard in the mobile communication space provides a graphic example of this.

Back in March, I noted that I find myself increasingly drawn to exploring the fractal nature of systems, both software and social, and their ecosystems. Understanding the social systems that make up the ecosystem of a software system is, in my opinion, key to getting and keeping the best possible fitness for purpose. Technology cannot help an organization when its structure and processes are working at cross purposes. Chasing these fractals to their logical end, we move from within the bounds of the organization out into its ecosystem. This is the level that Tom Graves refers to as the whole-enterprise, the “bold endeavour”.

This chasing of the fractals to form a mental model of the environment in which you’re operating is also known as situational awareness. Situational awareness is critical to effective sense-making which is critical to effective decision-making. Just as a body of troops with poor situational awareness risks walking into an ambush, an organization with poor situational awareness risks similarly unpleasant surprises (at least figuratively).

To be effective, the sense-making/decision-making process should be a ongoing process. Likewise, it is a process that should span the levels of concern, tactical through strategic, that make up the whole-enterprise architecture. To be effective, the process should yield action, adapting the organization to the changing context, not just insights into the divergence between the organization and its ecosystem. To be effective, you need to be intentional or lucky (and you can only control one of these).

My views regarding this are based on my own experience and what I’ve synthesized over the years from a variety of sources. I was pleased to get some affirmation recently while attending an event where Professor Edward Hess of the University of Virginia’s Darden Graduate School of Business discussed his book, Learn or Die: Using Science to Build a Leading-Edge Learning Organization. His premise was effective learning, something that humans can be really bad at, is key to organizational effectiveness. This view obviously resonates with me (which carries a hint of irony given that he talks about confirmation bias as something that inhibits effective learning – you’ll have to trust me that that’s not the case here).

Because of time constraints, Professor Hess’ talk did not go into the same depth as his book (which I’ve since read and will be referring to in upcoming posts), but some of the key points relevant here were:

  • a learning culture is useful regardless of whether the goal is efficiency or innovation
  • a learning culture is created intentionally
  • candor, facing the “brutal facts” is essential to a learning culture
  • permission to fail and psychological safety does not equate to lack of standards/control, a learning culture takes risk tolerance into account

His most important point is that while it is in our nature to be “suboptimal learners” who let ego and fear get in our way, we can learn to be better learners, both individually and as a group. Diversity, by virtue of bringing multiple mental models to the table, can diminish cognitive blindness (Gooch’s Paradox – “things not only have to be seen to be believed, but also believed to be seen”). By understanding that we are not rational thinkers, we can take measures to avoid the pitfalls of fast thinking.

In a changing world, sitting still can be deadly. Motion, however, provides little benefit if it’s not purposeful and intelligent. A cohesive whole-enterprise with a culture of intentional, effective sense-making and decision-making (learning) is well placed to make better moves in a dynamic world.

Abstract Dangers – When ‘And’ Meets ‘Or’

There’s an old saying that if you put one foot in a bucket of ice and the other in a bucket of boiling water, on average you’re comfortable. Sometimes analyzing information in the aggregate obscures rather than enlightens.

A statistician named Francis Anscombe pointed out this same principle in a more visual (though less colorful) manner more than forty years ago:

It’s an idea that I’ve been meaning to write about for a while, but was brought back to mind last week while reading an article on the Austrian school of economic theory posted on a site about medical practice and health care in the U.S. (diversity of interests and a very broad reading list is something I find useful, but that’s a topic for another day). The relevant passage:

When Ludwig von Mises began to establish a systematic theory of economics, he insisted on what he called the principle of methodological dualism: the scientific methods of the hard sciences are great to study rocks, stars, atoms, and molecules, but they should not be applied to the study of human beings. In stating this principle, he was voicing opposition to the introduction into economics of concepts such as “market equilibrium,” which were largely inspired by the physical sciences, and were perhaps motivated by a desire on the part of some economists to establish their field as a science on par with physics.

Mises remarked that human beings distinguish themselves from other natural things by making intentional (and usually rational) choices when they act, which is not the case for stones falling to the ground or animals acting on instinct. The sciences of human affairs therefore deserve their own methods and should not be tempted to apply the tools of the physical sciences willy-nilly. In that respect, Mises agreed with Aristotle’s famous dictum that ” It is the mark of an educated man to look for precision in each class of things just so far as the nature of the subject admits.”

I find myself agreeing and disagreeing with this at the same time. Human behavior is far from being as predictable as gravity and I agree with this for exactly the reason I disagree (at least in part) with the second paragraph. It is a mistake to characterize human action as intentional and rational. That’s not to say that all our choices are irrational and reactionary, but that there is a blend. Not only will different people respond in different ways to the same circumstance for different reasons, but the same person may react differently with different motivations on another occasion. Human nature isn’t rigidly deterministic and we consider it so at our peril.

Tom Graves post “Control, complex, chaotic” makes the same observation:

Attempting to ‘control’ complexity just doesn’t work: we need to treat the complex as complex, not as a ‘controllable problem for which we don’t quite know all the rules (but will know them all Real Soon Now, honest…)’.

Yet I’m also noticing another deeper problem: misguided attempts to apply complexity-theory to things that are neither rule-bound control nor pattern-based complexity, but are inherently ‘chaotic’ – a ‘market-of-one‘. Although we can identify definite patterns in health and health-care – that’s the whole basis of epidemiology, for example – neither rules nor statistics can help us deal with the blunt fact the everyone is different. The kind of patterns that we’d use in a complexity-model – probabilities, Bell-curve distributions, outliers, all that kind of thing – can all too easily mask the real underlying fact of uniqueness, from which that supposed ‘pattern’ will actually arise: somewhat like the barely-visible deep-randomness that underlies the visible patterns of Brownian-motion.

Trying to force something into a mold which it doesn’t fit is unlikely to work well.

Abstraction can be useful in understanding the contexts that influence the architecture of the problem. Designing an effective solution, however, will involve not just integrating the concerns of those contexts, but also dealing with any emergent challenges. The variability of human nature (in other words, sometimes the members of those contexts will not all think and act alike) can be one such emergent challenge.

Tom Grave’s again, this time from his “On mass-uniqueness”:

In practice, the scope of every system will comprise a mix of sameness and uniqueness – of predictable and unpredictable, certain and uncertain. If we design only on an assumption of sameness – as IT-systems often are – we set ourselves up for guaranteed failure. The same applies if – as is all too common – we say that our IT-system will handle all of the ‘sameness’ part of the context, and that the ‘not-sameness’ will Somebody Else’s Problem – without giving any means for that supposed ‘somebody else’ to be able to address the rest of the problem, or to link it up with the parts of the context that our system does handle.

The first requirement to make something that works in the real-world is to design for uniqueness, not against it.

In other words, a solution based on a poorly understood problem is unlikely to be a good fit. Abstraction is one tool to understand the problem, but doesn’t provide the whole picture. Shades of gray (black and white) is more likely than black or white.

Innovation – What’s Old can be New Again

Roman Road Ruins

There’s an old rhyme about what a bride should wear for luck on her wedding day: “Something old, something new, something borrowed, something blue…”. While reading an article on the origins of the US highway system, I thought about this rhyme in relation to the concept of innovation. Part of that article related the US Army’s interest in highways as a means of moving troops, etc.:

When the war ended in 1919, the Army sent an expedition from Camp Meade, Maryland, to San Francisco to study the feasibility of moving troops and equipment by truck, and it was a disaster. At an average speed of seven miles per hour, the trip took two months, and many of the vehicles broke down along the way. The rough journey convinced the officer in charge—a young Dwight D. Eisenhower—that impassable roads were a risk to national security and that building good roads should be the highest priority for the nation.

During World War II, Eisenhower’s views were confirmed by the Allies’ use of the autobahns in the invasion of Germany (ironically, the German military had been much less enthusiastic about their military potential, preferring the older, more established railroad system). Eisenhower would go on to spearhead the construction of the Interstate Highway System when elected President after the war.

While the construction and use of high-quality roads for military purposes was an innovation, it certainly wasn’t a new development. The Romans had “been there, done that” long before. It became innovative again due to the fact that the social and technological context had shifted, making it more effective than the previous transport innovation, railroads.

There’s an old saying that “history does not repeat itself, but it rhymes”. Recognizing when something old has regained its relevance can be a path to innovation. In my post “Innovation on Tap”, I talked about Amazon’s plan to open physical bookstores and embrace the concept of “showrooming”, something that traditional retailers have been struggling with for years. Other companies are jumping aboard. What I find interesting is that this concept was the business model of a company headquartered in my home town. They operated from 1957 to 1997, when they went bankrupt. Now, less than twenty years later, that model is seen as innovative. Once again, it’s the shift in social and technological contexts that has changed it into an effective solution. It’s the value that makes it innovative.

This is part 17 of an ongoing conversation with Greger Wikstrand on the topic of innovation.

[Roman Road image by Phr61 via Wikimedia Commons.]