Aggregated enterprise architecture wisdom
This model is part of my toolbox for working with capability architectures. The Capability Inventory I know that there is certain ways of naming a capability and also that there are other principles that people and I promote that you should adhere to when designing your capability map. Here I’ve taken some liberties in regards to those […]
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 […]
By Priya Patra, Sr. Manager at IGATE Global Solutions I have been an Agile Practitioner for years now, have been in many successful Agile executed projects. But as an Enterprise Architect I am somewhat skeptical about the fact how the … Continue reading →
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 […]
Agile and Architecture seemed to be, rightly or wrongly, often discussed together today. Should Enterprise Architecture be Agile? This is the question we all ask in fact.
Let’s go back to basics.
Agile is the developer’s way to do more work with…
@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
Working with architecture as a way of designing and cataloging the relationships between business and IT has always been a challenge. I recently attended an IASA meeting where we discussed the challenges of designing and maintaining a business architecture. At the meeting I talked about capabilities, what I think they are and how to actually go […]
Designing businesses is not a trivial activity. Having a simple structure that one can use to design and / or understand a capability makes designing business architecture so much easier. More to come on this topic during 2015. The Capability Canvas License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.