Architecture Corner: Good at innovation – Seven Deadly Sins of IT

The latest season of Architecture Corner is a series of episodes on the Seven Deadly Sins of IT. I had the pleasure of appearing on “Good at innovation” with Greger Wikstrand, Casimir Artmann, and many others. In this, the first episode of the series, we deal with the sin of pride.

What happens when the CEO thinks the company is more innovative than they really are?

This is the latest entry in the on-going conversation Greger and I have been having on the topic of innovation.

Form Follows Function on SPaMCast 442


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!

This is not a project

Gantt Chart

My apologies to René Magritte, as I appropriate his point, if not his iconic painting.

After I posted “Storming on Design”, it sparked a discussion with theslowdiyer around context and change. In that discussion, theslowdiyer commented:

‘you don’t adhere to a plan for any longer than it makes sense to.’
Heh, agree. I wonder if the “plan as a tool” vs. “plan as a goal in itself” discussion isn’t deserving of a post of its own 🙂

Indeed it is, even if it did take me nearly four months to get to it.

The key concept to understand, is that the plan is not the goal, merely a stated intention of how to achieve the goal (if this causes you to suspect that the words “plan” and “design” could be substituted for each other without changing the point, move to the head of the class). Magritte’s painting stated that the picture is not the thing. The map is not the territory (and if that concept seems a bit self-evident, consider the fact that Wikipedia considers it significant enough to devote over 1700 words, not counting footnotes and links, to the topic).

Conflating plan and goal is a common problem. To illustrate the difference, consider undergoing an operation. Is it your desire that the surgeon perform the procedure as planned or that your problem gets fixed? In the former scenario, your survival is optional.

This is not, however, to say that planning (or design) is useless. The output of an effective planning/design process is critical. As Joanna Young noted in her “Four Signs of Readiness – Or Not”:

I’m all for consigning the traditional 50+ pages of adminis-trivia on scope, schedule, budget, risks that requires signing in blood to the dustbin. However no organization should forego the thoughtful and hard work on determining what needs to be done, why, how, by whom, for how much – and how this will all be governed and measured as it is proceeds through sprints and/or waterfalls to delivery.

The information derived from the process (not the form, not the presentation, but the information) is critical tool for moving forward intelligently. If you have no idea of what to do, how to do it, who can do it when and for how much, you are adrift. You’re starting a trip with no idea of whether the gas tank has anything in it. Conversely, attempting to achieve 100% certainty from the outset is a fool’s errand. For any endeavor, more will be known nearer the destination. Plans without “wiggle room” are of limited usefulness as you will drift outside the cone of uncertainty from the start and never get back inside.

Having a reasonable idea of what’s acceptable variance helps determine when it’s time to abandon the current plan and go with a revised one. Planning and design are processes, not events or even phases. It’s a matter of continually monitoring context and whether our intentions are still in accordance with reality. Where the differ, reality wins. Always.

Execution isn’t blindly marching forward according to plan. It’s surfing the wave of context.

Innovation in Inner Space

KGL dragoons at the Battle of Garcia Hernandez


Long-time readers know that I have a rather varied set of interests and that I’ve got a “thing” for history, particularly military history. Knowing that, it shouldn’t come as a surprise that I was recently reading an article titled “Cyber is the fourth dimension of war” (ground, sea and air being the first three dimensions). It’s not a bad article, but it is mistaken. Cyberwar is the fifth dimension of war. The first dimension, today and for all of time past, is the human mind. Contests are won or lost, not on some field of battle, virtual or physical, but in the minds of the combatants. For example, if you believe you’ve lost, then you have.

The painting shown above illustrates this nicely. During the Napoleonic period, infantry that was charged by cavalry would form a square, presenting a hedge of bayonets to all sides. Horses, being intelligent creatures, will not impale themselves on pointy things, thus the formation provides protection to the infantry who were free to fire at the encircling cavalry. Charging disciplined, unbroken infantry was a losing proposition for the cavalry under almost all circumstances. Note the use of “almost”.

At the Battle of García Hernández, July 1812, something unusual happened. One French formation was late in firing, and a wounded horse ran blindly into the square, breaking it up. The attacking British (Hannoverian, to be precise) cavalry rode into the gap and forced the surrender of the French infantry that comprised it. This, of course, was simply a matter of physics. However, two further squares broke up when charged due to the effect of what happened to the first one on their morale. Believing they were beaten, they failed to maintain cohesion and their anticipated defeat became a reality.

So, what’s the point?

Greger Wikstrand and I have been trading posts on the topic of innovation since late 2015. Greger’s latest, “Spring clean your mind”, deals with the concepts of infowar and propaganda (aka “fake news”). This is another example of what Greger’s written about in the past, a concept he dubbed black hat innovation: “Whenever there is innovation or invention there is also misuse”.

Whether you call it black hat innovation or abuse cases (my term), it’s a concept we need to be aware of. It is a concept that affect us, not just as technologists, but as ordinary human beings. We need to be aware of the potential for active abuse. We also need to be aware of the potential for problems that caused by things that make our life more convenient or more pleasant:

This isn’t to say that Facebook is some evil empire, but that we need to bear some responsibility for not allowing ourselves to become trapped in an echo chamber:

It’s something we need to take responsibility for. We can’t hope for a technological deus ex machina to bail us out. As Tim Bass recently noted on his Cyberspace Event Processing Blog:

The big “AI” processing “pie in the sky” plan for cyber defense we all read about is not going to work “as advertised” because we cannot program machines to solve problems that we cannot solve ourselves. There is no substitute for the advancement and development of the human mind to solve complex problems. Delegating the task of “thinking” to machines is doomed to fail, and fail “big time”. It seems like humanity has, in a manner of speaking, “given up” on humans developing the intelligence to manage and defend cyberspace, so they have decided to turn it all over to machines.

Wrong approach!

The right approach, in my opinion, is to be intentional and active in learning. Consuming information should not be a matter of sitting back and shoveling it in, but one of filtering, testing, and appraising. How much time do you spend reading viewpoints you absolutely disagree with? How much time do you spend exploring information?

In 1645, as he was looking back at his long and successful career as a samurai, where a single loss often meant death, Miyamoto Musashi concluded that although rigorous sword practice was essential, it wasn’t enough. At the end of the first chapter of A Book of Five Rings, he also admonishes aspiring warriors to “Cultivate a wide variety of interests in the arts” and “Be knowledgable in a wide variety of occupations.”

Similarly, Boyd, who was was a keen student of Musashi, described his method as looking across a wide variety of fields — “domains” he called them — searching for underlying principles, “invariants.” He would then experiment with syntheses involving these principles until he evolved a solution to the problem he was working on. Because they involved bits and pieces from a variety of domains, he called these syntheses “snowmobiles” (skis, handlebar from a bicycle, etc.)


Perception is critical. We are made or unmade, less by our circumstances and more by our perception of them. Companies that have suffered disruptions have done so not because they were unable to respond, but because they either believed themselves invulnerable or believed themselves incapable. Likewise, as individuals, we have control over what information we expose ourselves to and how we manage that exposure.

Sense-making is a critical skill that requires active involvement. The passive get passed by.

[Painting of the battle of Garcia Hernandez by Adolf Northen, housed in the Landesmuseum Hannover. Photo by Michael Ritter via Wikimedia Commons]

Stopping Accidental Technical Debt

Buster Keaton looking at a poorly constructed house

In one of my earlier posts about technical debt, I differentiated between intentional debt (that taken on deliberately and purposefully) and accidental debt (that which just accrues over time without rhyme or reason or record). Dealing with (in the sense of evaluating, tracking, and resolving it) technical debt is obviously a consideration for someone in an application architect role. While someone in that role absolutely should be aware of the intentional debt, is there a way to be more attuned to the accidental debt as well?

Last summer, I published a post titled “Distance…is the one true enemy…”. The post started with a group of tweets from Gregory Brown talking about the corrosive effects of distance on software development (distance between compile and run, between failure and correction, between development and feedback, etc.). I then extended the concept to management, talking about how distance between sense-maker and decision-maker could negatively affect the quality of the decisions being made.

There’s also a distance that neither Greg nor I covered at the time, design distance. Design distance is the distance between the design and the outcome. Reducing design distance makes it easier to keep a handle on the accidental debt as well as the intentional.

Distance between the architectural decisions and the implementation can introduce technical debt. This distance can come from remote decision-makers, architecture pigeons who swoop in, deposit their “wisdom”, and then fly away home. It can come from failing to communicate the design considerations effectively across the entire team. It can also come from failing to monitor the system as it evolves. The design and the implementation need to be in alignment. Even more so, the design and the implementation need to align with particular problems to be solved/jobs to be done. Otherwise, the result may look like this:

Distance between development of the system and keeping the system running can introduce technical debt as well. The platform a system runs on is a vital part of the system, as critical as the code it supports. As with the code, the design, implementation, and context all need to be kept in alignment.

Alignment of design, implementation, and context can only be maintained by on-going architectural assessment. Stefan Dreverman’s “Using Philosophy in IT architecture” identified four questions to be asked as part of an assessment:

  1. “What is my purpose?”
  2. “What am I composed of?”
  3. “What’s in my environment?”
  4. “What do I communicate?”

These questions are applicable not only to the beginning of a system, but throughout its life-cycle. Failing to re-evaluate the architecture as a whole as the system evolves can lead to inconsistencies as design distance grows. We can get so busy dealing with the present that we create a future of pain:

At first glance, this approach might seem to be expensive, but rewriting legacy systems is expensive as well (assuming the rewrite would be successful, which is a tenuous assumption). Building applications with a one-and-done mindset is effectively building a legacy system.

The Seventy Million Dollar Question



Just when I thought I was done posting for the week, they suck me back in.

Juicero started lighting up my Twitter feed a little while ago. For those, like me, who have no earthly idea what Juicero is, it’s a startup that makes an “Internet-connected kitchen appliance”:

Juicero’s flagship product is a $699 countertop device that cold presses juice out of “packs” of already prepped fruit and veggies. The packs — reminiscent of the cups and pouches used in single-cup coffee brewers from Keurig, Flavia or Nespresso — cost $4 to $10 each and are available through a Juicero subscription, but not in groceries.

Juicero just picked up $70 million in Series B funding. ‘Cause digital.

There is just one hitch – you don’t actually need the high-dollar hardware to make the juice:

But after the product hit the market, some investors were surprised to discover a much cheaper alternative: You can squeeze the Juicero bags with your bare hands. Two backers said the final device was bulkier than what was originally pitched and that they were puzzled to find that customers could achieve similar results without it. Bloomberg performed its own press test, pitting a Juicero machine against a reporter’s grip. The experiment found that squeezing the bag yields nearly the same amount of juice just as quickly—and in some cases, faster—than using the device.

Fortunately (ahem), Juicero only sells the bags, at anywhere from $5 to $8 apiece, to owners of the hardware. Performance between the device and non-standard hardware (your bare hands) is mixed:

In Bloomberg’s squeeze tests, hands did the job quicker, but the device was slightly more thorough. Reporters were able to wring 7.5 ounces of juice in a minute and a half. The machine yielded 8 ounces in about two minutes.

Almost 5 years ago, I wrote a post titled “The Most Important Question”. In it I stated the following:

The most important question in architecture is “why”. When questioned about any aspect of the design, if you cannot justify the decision, you should revisit it. Being able to list outcomes, both good and bad, and explain the reasoning behind your choices will garner trust from both customers and colleagues. Most importantly, it should boost your own confidence in the design.

With a little editing:

The most important question in architecture innovation is “why”. When questioned about any aspect of the design product, if you cannot justify the decision, you should revisit it. Being able to list outcomes, both good and bad, and explain the reasoning behind your choices will garner trust from both customers and colleagues. Most importantly, it should boost your own confidence in the design product.

Asking “why” could have probably saved some people a lot of money, just sayin’.

Pride, Prejudice, and Professionalism in the Business of IT

interior of a 1958 Plymouth Savoy

Twenty-plus years in IT have led me to believe that there are very few absolutes when it comes to software systems. Two that do seem to hold true are these:

  1. Creating systems is esteemed far more highly than maintaining systems.
  2. Systems that are not maintained, will decay.

There are a variety of reasons for this situation, many of which are baked into the architecture of the enterprise. Regardless of the why, however, the two facts remain. Without a response to those issues, entropy is inevitable.

Over the past few days, I’ve seen several blog posts by two different authors dealing with this situation in two different ways:

Jason complains about the non-technical “leadership class” in his first post:

And hence we get someone making the big decisions about healthcare who knows nothing about medicine or about running hospitals or ambulance services. And we get someone in charge of all the schools who knows nothing about teaching or running a school. And we get someone in charge of a major software company whose last job was being in charge of a soft drinks company. And so on.

Again, this is fine, if they leave the technical decisions to the technical experts. And that’s where it all falls down, of course. They don’t.

The guy in charge of the NHS insists on telling doctors and nurses how they should do their jobs. The woman in charge of UK schools insists on overriding the expertise of teachers. The guy in charge of a major software company refuses to listen to the engineers about the need for automated testing. And so on.

This is the Dunning-Kruger effect writ large. CEOs and government ministers are brimming with the overconfidence of someone who doesn’t know that they don’t know.

In his second post he follows up with how to respond:

My pithy – but entirely serious – advice in that situation is Do It AnywayTM.

There are, of course, obligations implied when we Do It AnywayTM. What we’re doing must be in the best interests of stakeholders. Do It AnywayTM is not a Get Out Jail Free card for any decision you might want to justify. We are making informed decisions on their behalf. And then doing what needs to be done. Y’know. Like professionals.

I disagree. Strenuously.

If you go to the doctor and they tells you that you will need surgery at some point for some condition, would you expect to be forcibly admitted and operated on immediately?

If you were charged with a crime, would you expect your attorney to accept a plea bargain on your behalf without consultation or prior permission?

If neither of those professionals would usurp the right of their client/patient to make their own informed decision, why should we? Both of those examples would be considered malpractice and the first would be criminal assault in addition. Therefore, I disagree that acting on someone’s behalf without their knowledge or consent is a viable option.

John’s approach, rejecting helplessness and confronting the issues by communicating the costs (with justifications/evidence) is, in my opinion, the truly professional approach. We have a responsibility to make the problem visible and continue making it visible. We also have a responsibility to operate within the limits we’re given. We know far more about our area than someone higher up the management chain, but, that does not equate to knowing more in general than those higher up the management chain. Ignorance is relative. Micro-managing, getting deeper in the weeds than you need to is ineffective. If, however, you’re in the weeds, do you have the information necessary to say that the issue being “interfered with” is one without higher-level consequences? Dunning-Kruger can cut a wide swathe. Trust needs to cut both ways.

Imagine riding as a passenger in a car. You see the car drifting closer and closer to the shoulder. Do you point it out to the driver or do you just grab the wheel? You might prevent an accident or you just might cause one by steering into a vehicle coming up from behind that you didn’t see from your vantage point.

[Plymouth Savoy photo by Christopher Ziemnowicz via Wikimedia Commons]