Monthly Archives: January 2016

The Business of IT – Customers, Clients, and Fit for Purpose

Posted on by

Nesting Doll

Over the past few months, I have touched on a variety of what might seem to be disparate topics: the need for architects (or at least architectural design), estimates, organizations as systems/enterprise architecture, customer-centricity, and IT management and governance. I suspect the trend will continue for a while, so it’s time for a post to explicitly tie things together.

The concept of “organizations as systems” is the cornerstone. Software systems do not exist in isolation, but within a fractal set of contexts, each of which are systems themselves. These systems serve as the ecosystem for those they contain and will ultimately end in one or more social systems. Understanding the ecosystem is critical to ensuring that its component systems are fit for purpose, otherwise we risk trying to introduce fish into a desert.

The social system context is, in my opinion, key. Information technology delivery can take place in a wide variety of ways, but a useful high-level differentiation is that between delivery of an off-the-shelf product versus delivery of a service. Is the customer a client?

These two sentences, left alone, could be a source of confusion. Precision isn’t one of the English language’s strong points. Not all products are off-the-shelf, sometimes the service we deliver is the creation of a bespoke product (ultimately, the end user is concerned with the product that they will use, not the project by which we created it). Likewise, in my opinion, clients are customers, just not all customers are clients. In my career, I’ve exclusively dealt with client customers, so I tend to use the two terms interchangeably. That becomes a problem when we have a client that isn’t being treated like a client. Seth Godin’s recent post explained the difference nicely:

The customer buys (or doesn’t buy) what you make.

The client asks you to make something.

The customer has the power to choose, but the client has the power to define, insist and spec.

There is a large number of potential customers, and you make for them before you know precisely who they are.

There are just a relative handful of clients, though, and your work happens after you find them.

If a customer doesn’t like what’s on offer, she can come back tomorrow. If the client doesn’t like what you deliver, she might leave forever.

When a vendor fails to treat its customers as clients, they risk losing the client. When an in-house IT organization treats fails to treat its captive customers as clients, the result is “Shadow IT”. When that result is complained about, it betrays a shocking lack of awareness on the part of the complainer.

A client will have a hierarchy of concerns in relation to IT. The client’s main interest is the job that they’re doing (or will be doing) with a product. Their concern with the product will be shaped by that, as will their concern with the process by which the product is delivered. We shouldn’t be surprised when things that don’t promote the client’s welfare (or, at least, aren’t presented in that manner) are met with a lack of interest. We definitely shouldn’t be surprised when things that are seen as a net negative to the customer are met with hostility. Understanding and respecting the client’s point of view is required to avoid damaging our credibility and relationship with them.

Meeting the needs of my clients is my objection to #NoEstimates. Clients may have questions that require estimates to answer. In “Estimates – Uses, Abuses, and that Credibility Thing Again”, I listed several that were taken from a post by a prominent #NoEstimates advocate. In my opinion, those questions become my concern by virtue of being my client’s concern. Suggesting, as that advocate does, that they need different questions, is not serving their needs.

Just as the infrastructure environment can influence design decisions, so can the social environment. While it is certainly possible to deliver IT in an environment where the clients’ needs are largely ignored, doing so is detrimental to the clients, to the providers, and to the organization(s) to which they belong. We wouldn’t try to force a square peg in a round hole and we shouldn’t try to force ill-fitting solutions on those who depend on our work. Products generally work best when they’re designed to be used in the way they’re used. The same holds true for services.

[Recursive Matrena 01 image by Vahram_Mekhitarian via Wikimedia Commons]

Updated 4/8/2016 to fix a broken link.

Advertisement

OODA vs PDCA – What’s the Difference?

Posted on by

PDCA Loop

In my post “Architecture and OODA Loops – Fast is not Enough”, I stated that sense-making and decision-making were critical skills for the practice of software architecture. I further stated that I found the theories of John Boyd, particularly his OODA loop, useful in understanding and describing effective sense-making and decision-making. My conclusion was that in order to decide and act in the most effective manner possible, one must observe the context as effectively as possible and orient, or make sense of those observations, as effectively as possible. In other words, the quality of decision depended on the quality of the cognition.

One of the many things that I enjoy about blogging and engaging on media like Twitter and LinkedIn is the feedback. The questions and comments I get in response to one post ensure that I don’t have to worry about writer’s block getting in the way of my next one. In this instance, Greger Wikstrand obliged, providing the topic for this post:

As I replied to Greger, I was familiar with the PDCA cycle and it has some similarities to Boyd’s OODA loop, but I preferred OODA for a variety of reasons. Before I get into those reasons, however, it would be useful to lay out what distinguishes the two methods. In a guest post on the blog Slightly East of New, “PDCA vs. OODA — Why not take both?”, Deane Lenane does just this:

Some people who are familiar with the canon of both of these men’s work, often fall into the error of seeing the O-O-D-A loop as a function of the P-D-C-A loop or vice versa. I think this is a mistake.

The P-D-C-A cycle or loop is primarily an analytical approach that can be used with great success in a completely internal manner. One does not need to consult the external environment or adjust to unfolding circumstances to make the P-D-C-A loop work. P-D-C-A can be used with great success on the shop floor with the data that is available. Analysis which involves the use of a more or less complete data set to reach a conclusion. We use the data to make a decision about how to proceed, we than check and act to confirm or reject the hypothesis that our analysis has led us to.

O-O-D-A is more concerned with synthesizing an action out of an incomplete data set. Since we can never recognize all of the variables that we are forced to deal with in any environment, we must be able to make a decision that we believe will give us the highest probability for success. The synthesis of an action from the observation and orientation of a complex and mysterious environment, subject to frequent and unpredictable change, is the essence of the O-O-D-A loop.

My conclusion is that P-D-C-A is primarily involved with analysis perhaps using some synthesis and that O-O-D-A is primarily involved with synthesis using all of the analytical data points possible but considering that the data set will always be largely incomplete.

Three aspects of Lenane’s differentiation point me toward OODA: “environment” (i.e. the evaluation of the external context we must deal with rather than the more inward looking PDCA), “synthesizing an action”, and “incomplete data set”. Systems exist in an environment, an ecosystem with a back-story. Failing to account for those ensures problems if not outright failure. Likewise, our aim is to make a decision to the best of our ability under uncertainty. These concepts mesh nicely with the practice of architecture in my opinion.

Another aspect relates back to the PCA acronym in Greger’s tweet. That took some research for us to find a good resource, because:

However, Greger did find one (slide 3 of this deck). Essentially, it states that Perception of the world leads to Cognition which leads to Action that changes the world. Perception being the key word here. How we perceive reality is arguably more important than reality itself, because that perception will color our thinking that drives our action. The Orient portion of the OODA explicitly recognizes that our observations are filtered through our experience, education, biases, etc. Understanding and adjusting for this (to the extent we can) is important. As Tom Graves observed in “Enterprise-architect – applied-scientist, or alchemist?”:

Perhaps the most important thing here is to notice things that don’t fit our expectations – they’re often very easy to miss, especially given Gooch’s Paradox, that “things not only have to be seen to believed, but also have to be believed to be seen”.

Software architecture involves making decisions in the presence of uncertainty. In order to make the best decisions possible, we need to have the best possible grasp of our context (n.b. remembering that we are part of that context). We also need to remember that the context is not static. Each action (or inaction, for that matter) can lead to the emergence of some new issue. We can’t operate with a “one and done” philosophy.

[PDCA Loop diagram by Tagimaguiter via Wikimedia Commons]

Form Follows Function on SPaMCast 377

Posted on by

SPaMCAST logo

This week’s episode of Tom Cagley’s Software Process and Measurement (SPaMCast) podcast, number 377, features Tom’s essay on empathy, Kim Pries talking about the application of David Allen’s concepts for Getting Things Done, and the first Form Follows Function installment for 2016 on organizations and innovation.

Tom and I discuss my post “Changing Organizations Without Changing People”, talking about the need to work with, not against, human nature in the design and operation of organizations.

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

Architecture and OODA Loops – Fast is not Enough

Posted on by

OODA Loop Diagram

Sense-making and decision-making are critical skills for the practice of software architecture. Creating effective solutions (i.e. the collection of design decisions that make up the product) is dependent on understanding the architecture of the problem. In other words, the quality of our decisions depends on the quality of our understanding of the context those decisions were intended to address. As Paul Homer recently observed in his post “Thinking Problems”:

Thinking well is a prerequisite for handling complex problems, with or without technology. If people can’t clearly understand the issues, then any attempt to solve them is as equally likely to just make them worse. If they break down the problem into a convoluted mess of ill fitting parts, then any solutions comprised of these is unlikely to work effectively, and is more likely to make things worse. Software, as it is applied to sophisticated problems, is inordinately complex and as such can not be constructed without first arriving at a strong understanding of the underlying context. This comes from observations, but it doesn’t come together until enough thinking has been applied to it to get it into a usable state.

Systems, both automated and social (particularly social), tend to display complex, emergent behavior. The ecosystem for automated systems is a social system that may comprise other social systems. The development and operation of automated systems is, in itself, a social system. Agility in sense-making, decision-making, and execution is critical to effective operation in this environment.

This need for agility is why, when it comes to thinking about thinking, one of the theorists whose ideas I pay particular attention to is John Boyd. Boyd, a US Air Force fighter pilot, gained fame for his theories of cognition. Although initially developed in relation to the tactics of aerial combat, they were found to have a wider application (applying to strategy as well and not being limited to military domains). At its core, the theory was that to defeat an opponent, one must get inside their OODA (Observe, Orient, Decide, and Act) loop. In other words, the person that could observe circumstances, make sense of them (orient), decide on a response and then act on that decision quickest would have the advantage.

Simple explanations of Boyd’s theories are problematic. As Tom Graves points out in his post “Seven sins, sensemaking and OODA”:

…the OODA ‘loop’ isn’t a linear loop – it’s fractal, recursive, re-entrant, looping through itself at multiple levels all at the same time. There’s sensemaking within action, action within sensemaking, decisions affecting how we sense and observe. It’s fractal.

My use of the word “quickest” earlier in the post regarding acting on a decision poses a problem. As I noted in the title, fast is not enough. One could gain speed by just acting without any observation, orientation, or decision. In my opinion, however, the result would most likely be flailing blindly. Too little analysis is detrimental.

Likewise, though, trying to deal with too much information poses a problem. From a conversation with Greger Wikstrand:

Greger rightly observes that the information available is out of our control, but our decision to filter or process it is under our control. By intentionally and intelligently filtering, we can traverse the loop quicker and more effectively.

Whether engaged in application architecture, solution architecture, or enterprise architecture, sense-making and decision-making are crucial components of the practice. That sense-making and decision-making is a continual process throughout the lifetime of the system, not just an initial or occasional phase. Constant understanding of the context the system exists within is vital because:

[OODA Loop diagram by Patrick Edwin Moran via Wikimedia Commons]

Technology in 2016 on SPaMCast 376

Posted on by

SPaMCAST logo

This week’s episode of Tom Cagley’s Software Process and Measurement (SPaMCast) podcast, number 376, is something new. Tom hosts a discussion of what to expect re: technology in 2016 with the full cast of his regulars: Jeremy Berriault (The QA Corner), Steve Tendon (The TameFlow Approach), Kim Pries (The Software Sensei), and me (Form Follows Function). We take on subjects like women in technology, microservice architectures, capabilities, business/IT integration, and more. It was a great discussion, well worth the listen!

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

Is 2016 the Year for Customer-Focused IT?

Posted on by

Woman with Crystal Ball

Maybe it’s a sign.

Although I haven’t made New Year’s predictions in the past, this year I took part in a panel discussion with Jeremy Berriault, Steve Tendon, Kim Pries, hosted by Tom Cagley for his SPaMCast podcast (it should be posted this weekend, I’ll link to it when it does). As Tom described it in the show notes for Sunday’s episode, we “…prognosticated a bit on the topics that will motivate software development and process improvement in 2016”. One of the things I mentioned, more as a wish than a prediction, was for more customer-centricity in IT.

Then, one of the first tweets I read this morning is:

The gist of the article Christian referenced was that IT needs to apply the same principles to enterprise and software as a service (SaaS) applications that DevOps brings to custom-developed applications. The aim being to “…become faster, more nimble, and more flexible and responsive to the demands of business managers”.

The Customer-centricity tag has been applied to a lot of posts on this blog, going back to the earliest days. In my opinion, removing the divide between IT and the organization it serves is the most critical issue for IT today. Without bridging this gap, it’s unlikely that progress will be made on other issues that might come to mind first, such as information security and shadow IT. A siloed IT organization that fails to focus on meeting the needs of its customers is unlikely to be seen as a source for innovation. It’s more likely to be seen as an obstacle to be worked around.

If 2016 isn’t the year for customer-focused IT, I wonder just what kind of year it will be for IT?