Aggregated enterprise architecture wisdom
Throughout this blog series we talked about using ArchiMate, and approaches for setting up ArchiMate models. We first discussed a top-down, and then a bottom-up approach, and presented examples from our consulting practice for both. Now here i…
This one came through from a colleague on the Twitterstream a couple days back, presumably somewhat channeling John Lennon: Imagine no possessions, we’d all love to see the plan And yeah, it’s a concern (complaint?) I get a lot about…
As soon as you, as an enterprise architect, want to address the problem of the complex Business-IT landscape, and you actually acknowledge in a discussion that Enterprise Architecture has come into existence because of the complexity of modern IT-laden landscapes, … Continue reading →
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 →
TOGAF certification has become a de-facto baseline for endorsing the skills of an enterprise architect. But how does it really help you? This article looks at 5 things you can do, in addition to becoming TOGAF Certified, that will help you develop as an Enterprise Architect. Read the full article: https://www.goodelearning.com/downloads/enterprise-architecture/what-does-togaf-certification-really-mean-to-you?
Often business cases of architects will contain the rule of reuse, especially if those architects are engineers. However there are two inherit problems in this area. the first is that of a business case. The assumption behind a business case is that we can predict the future and break down all complexities into a simple … Continue reading The lie of reuse →
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…
This #eavoices post is the first in a series of n posts about enterprise architecture today and tomorrow. In this first post, I will dig into the EA Voices database and look for some trends. With 3.2 million words in over 5400 posts, written by 135 authors over the past 5 years, EA Voices is …
Sometimes, Enterprise Architecture efforts fail. This is no surprise to folks in the EA business. This failure occurred slowly, back in 2007 and 2008. But it did occur. It took me a while to realize it. I had developed a method useful for Application Portfolio Management as well as for Service Oriented Architecture called “Solution…
@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
@sheldrake via @cybersal challenges Peter Drucker on the purpose of business.”Peter Drucker asserted that the purpose of business is to create and keep a customer. He was right at the time in offering previously inward-looking firms a more appropriat…