Aggregated enterprise architecture wisdom
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.
The most common concern our customers voiced in 2014 was the unexpected outcomes of Agile projects. They don’t talk about failure as such. But they do talk about loss of consistency; inability to govern; lack of coordination AND THE INCREASING TIME TO MARKET caused by these precise issues.
I was struck by the results of the Agile Adoption Experiences Survey 2014 published by Scott Ambler. The really significant result to me is that 40% of respondents rates their organizations adoption of Agile as neither a success or a failure. Add to this the categories of Failure, Great Failure and Too early to tell and you have 58% that are not successful! This synchs with my customer feedback referred to above.
The advice my colleagues and I give when customers approach us looking for answers to these questions, is to look at how architecture is integrated into Agile projects. And there are some key areas that we look for in our assessments:
1. Is there a good reference architecture and associated contextual patterns?
2. Are there clear policies attached to work products together with the rationale?
3. Are developers and architects working as a community of interest to evolve the reference architecture, patterns and policies?
4. Are the reference architecture, patterns and policies integrated into the tooling and the architecture runway?
5. Is the architecture runway model based – allowing it to provide a reusable design time platform to be evolved by projects?
Agile projects can be successful in an enterprise situation. But architecture and governance need to be coordinated for consistency and mechanisms (automation) enforced to ensure consistency.
I wonder why the Agile Adoption survey didn’t ask any questions along these lines?
The most common concern our customers voiced in 2014 was the unexpected outcomes of Agile projects. They don’t talk about failure as such. But they do talk about loss of consistency; inability to govern; lack of coordination AND THE INCREASING TIME TO MARKET caused by these precise issues.
I was struck by the results of the Agile Adoption Experiences Survey 2014 published by Scott Ambler. The really significant result to me is that 40% of respondents rates their organizations adoption of Agile as neither a success or a failure. Add to this the categories of Failure, Great Failure and Too early to tell and you have 58% that are not successful! This synchs with my customer feedback referred to above.
The advice my colleagues and I give when customers approach us looking for answers to these questions, is to look at how architecture is integrated into Agile projects. And there are some key areas that we look for in our assessments:
1. Is there a good reference architecture and associated contextual patterns?
2. Are there clear policies attached to work products together with the rationale?
3. Are developers and architects working as a community of interest to evolve the reference architecture, patterns and policies?
4. Are the reference architecture, patterns and policies integrated into the tooling and the architecture runway?
5. Is the architecture runway model based – allowing it to provide a reusable design time platform to be evolved by projects?
Agile projects can be successful in an enterprise situation. But architecture and governance need to be coordinated for consistency and mechanisms (automation) enforced to ensure consistency.
I wonder why the Agile Adoption survey didn’t ask any questions along these lines?
Designing and understanding brands and how the behave as figments of their own is hard enough. Having a simple structure that one can use to design and / or understand a brand makes designing businesses so much easier. More details to come on this topic… The Brand Canvas License This work is licensed under a Creative […]
As a teaser for the new year I thought I’d release The Change Canvas (TCC). Much more to come on this and related topics during 2015. The Change Canvas License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.