Aggregated enterprise architecture wisdom
This model is part of my toolbox for working with business architectures. The Inventory Model The important thing to remember is to be agile minded in use of tools like this. So, when I say extendable I mean that this is definitely not all things that could or should be in the inventory. Reconfigure it in […]
This model is part of my toolbox for working with business architectures. The Inventory Model The important thing to remember is to be agile minded in use of tools like this. So, when I say extendable I mean that this is definitely not all things that could or should be in the inventory. Reconfigure it in […]
This model is part of my toolbox for working with strategic architectures. The Strategy Model Note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link […]
This model is part of my toolbox for working with strategic architectures. The Strategy Model Note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link […]
This little canvas is part of my toolbox for detailing and documenting scenarios. The Scenario Canvas Note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll […]
@ruthmalan challenges @swardley on #Agile
Asked what is agile? It’s a method of reducing the cost of change when developing an uncertain act.
— swardley (@swardley) April 21, 2015
@swardley have you seen John Seddon’s quip: “Waterfall: doing the wrong thing righter. Agile: doing the wrong thing faster.”?
— ruth malan (@ruthmalan) April 21, 2015
@swardley in theory 🙂 What we’re paying attention to shapes what we perceive and pay attention to. etc.
— ruth malan (@ruthmalan) April 21, 2015
@swardley I was making a sophisticated/nuanced point. We canalize — we think we’re open to finding misdirection but it’s hard
— ruth malan (@ruthmalan) April 21, 2015
Some things are easier to change than others. The architect Frank Duffy proposed a theory of Shearing Layers, which was further developed and popularized by Stuart Brand. In this theory, the site and structure of a building are the most difficult to change, while skin and services are easier.
Let’s suppose Agile developers know how to optimize some of the aspects of a system, perhaps including skin and services. So it doesn’t matter if they get the skin and services wrong, because these can be changed later. This is the basic for @swardley’s point that you don’t need to know beforehand exactly what you are building.
But if they get the fundamentals wrong, such as site and structure, these are more difficult to change later. This is the basis for John Seddon’s point that Agile may simply build the wrong things faster.
And this is where @ruthmalan takes the argument to the next level. Because Agile developers are paying attention to the things they know how to change (skin, services), they may fail to pay attention to the things they don’t know how to change (site, structure). So they can throw themselves into refining and improving a system until it looks satisfactory (in their eyes), without ever seeing that it’s the wrong system in the wrong place.
One important function of architecture is to pay attention to the things that other people (such as developers) may miss – perhaps as a result of different scope or perspective or time horizon. In particular, architecture needs to pay attention to the things that are going to be most difficult or expensive to change, or that may affect the lifetime cost of some system. In other words, strategic risk. See my earlier post A Cautionary Tale (October 2012).
Wikipedia: Shearing Layers
@ruthmalan challenges @swardley on #Agile
Asked what is agile? It’s a method of reducing the cost of change when developing an uncertain act.
— swardley (@swardley) April 21, 2015
@swardley have you seen John Seddon’s quip: “Waterfall: doing the wrong thing righter. Agile: doing the wrong thing faster.”?
— ruth malan (@ruthmalan) April 21, 2015
@swardley in theory 🙂 What we’re paying attention to shapes what we perceive and pay attention to. etc.
— ruth malan (@ruthmalan) April 21, 2015
@swardley I was making a sophisticated/nuanced point. We canalize — we think we’re open to finding misdirection but it’s hard
— ruth malan (@ruthmalan) April 21, 2015
Some things are easier to change than others. The architect Frank Duffy proposed a theory of Shearing Layers, which was further developed and popularized by Stuart Brand. In this theory, the site and structure of a building are the most difficult to change, while skin and services are easier.
Let’s suppose Agile developers know how to optimize some of the aspects of a system, perhaps including skin and services. So it doesn’t matter if they get the skin and services wrong, because these can be changed later. This is the basic for @swardley’s point that you don’t need to know beforehand exactly what you are building.
But if they get the fundamentals wrong, such as site and structure, these are more difficult to change later. This is the basis for John Seddon’s point that Agile may simply build the wrong things faster.
And this is where @ruthmalan takes the argument to the next level. Because Agile developers are paying attention to the things they know how to change (skin, services), they may fail to pay attention to the things they don’t know how to change (site, structure). So they can throw themselves into refining and improving a system until it looks satisfactory (in their eyes), without ever seeing that it’s the wrong system in the wrong place.
One important function of architecture is to pay attention to the things that other people (such as developers) may miss – perhaps as a result of different scope or perspective or time horizon. In particular, architecture needs to pay attention to the things that are going to be most difficult or expensive to change, or that may affect the lifetime cost of some system. In other words, strategic risk. See my earlier post A Cautionary Tale (October 2012).
Wikipedia: Shearing Layers
Here’s some thoughts on what a strategy is, and what it isn’t:
Addendum:
I recommend reading Roger Martin’s wise words on the subject of Stategy. A few quotes from his post:
“The problem with a lot of strategies is that they are full of non-choices. Probably most of us have read more than a few so-called strategies that say something like, “Our strategy is to be customer centric.” But is that really a choice?”
“I would argue that 90 percent of the strategic plans I’ve seen in my life are really more accurately described as budgets with prose”.
“If you’re into destroying innovation, two words—”prove” and “it”—will do the trick”.
Here’s some thoughts on what a strategy is, and what it isn’t:
Addendum:
I recommend reading Roger Martin’s wise words on the subject of Stategy. A few quotes from his post:
“The problem with a lot of strategies is that they are full of non-choices. Probably most of us have read more than a few so-called strategies that say something like, “Our strategy is to be customer centric.” But is that really a choice?”
“I would argue that 90 percent of the strategic plans I’ve seen in my life are really more accurately described as budgets with prose”.
“If you’re into destroying innovation, two words—”prove” and “it”—will do the trick”.
Back on the ‘no more arguments‘ theme, there were a couple of responses I received that, although nominally private, were so apposite and to-the-point that I really do need to reprise them here. (Because the messages were private, I’ll paraphrase them…