Design Agile Bridges to the Future
In 1960, Geoffrey Anthony Jellicoe unveiled his plans for Motopia: a city of the future in which cars drove on the tops of buildings, and pedestrians were transported by moving walkways at street level. Freed from the need to dedicate land to roads, Motopia would be a city of parks and trees. Unsurprisingly, Motopia was never built, and it’s possible that it was never intended to be built.
Technology architects in large enterprises sometimes look like Jellicoe presenting his grand ideas, and often feel like Jellicoe when those grand ideas are never realised. We paint pictures of the future based on exciting new technology, while others wonder whether that future is possible, and whether it is somewhere they would actually want to live (or whether cars would fall on their heads).
In an earlier blog post I said that if people don’t understand architects, then it is our fault, not theirs. This is just as true of strategic visions as it is of day to day design decisions: no-one is obliged to understand us or back us if we can’t explain ourselves, and if we can’t make it clear how we get from here to there.
Defining strategic visions is hard, but figuring out how to achieve them is even harder. How do we solve this most difficult of architectural problems? How do we bridge the gap from strategy to execution, and get the future built?
There are very familiar ways that we can try to bridge this gap. We can define elaborate future state architectures, we can define multiple transition states, we can define complicated portfolios of programmes and map the dependencies between them. We’ve all tried this: I know that I have.
There is only one problem with this approach: it almost never works. There is a reason that documents labelled ‘future state architecture’ are still labelled ‘future state architecture’ years after they were written: because they describe a state which is still in the future.
I think that a better answer may lie in the ways of working we call DevOps and Agile.
This may sound counter-intuitive to some architects. Surely DevOps and Agile are all about the short term, about delivering value today and tomorrow, not about delivering strategic outcomes over several years. (And don’t many architects suspect that all these Devops and Agile enthusiasts are cowboys who will compromise their architecture at the first opportunity?)
The reason that I believe that DevOps and Agile can help us realise our strategic dreams is that they have a very different relationship to their software products from traditional waterfall projects.
For traditional waterfall projects, the software product is a final outcome. It is a thing we strive towards over months or years, deliver, and then move onto something else. We only have one shot to get this right, so all design decisions are highly charged. This means that, as architects, we steadily see our vision eroded under a succession of tactical choices required to meet the deadline. We might get a chance to put it right in phase two, but we all know that that’s never happening. Once the thing is done, it is done. Any major changes belong to another project in another investment cycle.
For Agile projects, delivered by DevOps teams, the software product is never finished. It is always a provisional thing, which delivers value right now, and is always capable of being improved. And improving it is what we’re going to do next. And next. And next.
In a waterfall project, a tactical choice is often a major, regretted compromise. In an Agile project, it is simply the thing we are going to do now: the stigma we attach to ’tactical’ choices starts to fade.
Of course, there is still a role for a strategy. There is still a reason we are making all these changes, and there is still a goal we are heading towards. And it is still hard to stick to our strategy with faith and energy: we still need the Zang Jing Ge qualities of technical excellence, communication mastery and leadership power to keep us headed in the right direction. But, when we proceed in small steps, with room for adjustment, we have room to take the occasional sideways step without compromising the whole journey: there is always a chance to put it right, and that chance may come as soon as tomorrow.
It’s been clear for a long while that architects needs to master Agile and DevOps as means to deliver immediate change; it also seems that they need to master Agile and DevOps to deliver strategic outcomes.
Technology Leadership | Systems Thinking | Situational Leadership
5 年Resonates very well with what Peter Senge was referring to in his masterpiece The Fifth Discipline about the discipline of personal mastery (which is about personal vision). What specifically resonates with the article is the crucial complementing part to personal vision, which is seeing reality objectively. He was explaining what he calls the creative tension, which the (non-emotional) tension that exists the minute we objectively recognize reality, while holding to a personal vision (something that we truly want and genuinely believe in). Such creative tension gives the energy required to pursue the non-easy process of bringing reality closer to the future state we envision (as opposed to giving in, and lowering our vision closer to reality so that the tension becomes something we can live with). He goes on explaining another discipline of shared vision or group vision. In which (among many other points), he said exactly what you refer to in the article, that there's no destination. It's about the journey of defining how we will get there as a group. How we can bring the current reality closer to the shared vision we truly committed to. And that it's an ongoing process of practice, reflect, adjust and practice again.
Definitely a thought provoking reading. One observation - every methodology was designed to be used for certain tasks. And the history of mankind tells us that when we use something outside of its designed purpose if will fail. There is a place for Waterfall, and there is a place for DevOps/Agile. There will be certainly areas where either would work, and absolutely certainly too if we stretch either outside of its design purpose - well, we know what will happened, do not we? Eager to learn your view!?
Senior Lead Architect at HSBC
5 年Well said, small steps with Agile and devops will bring effective transitional state and path to stratigic vision of any enterprise.. Thanks all your support
Senior Cloud security architect at Société Générale
5 年Excellent article. The biggest difficulty for architects who embrace devOps and Agile is that they do not have a visible, ready-made role that fits nicely into the process. They have to carve it all by themselves, thanks to the qualities you mention. They have to invite themselves into scrum meetings, get an (active) account into various wekans, win the respect of the feature team members without being members (most of the time) of the team themselves. This transformation is not without casualties, though. But it is an efficient filter to spot true talents.
Enterprise Architect at HSBC
5 年I think enterprise architects need to keep in mind that the target architecture - the end goal - is a moving target and realistically will never be delivered. But delivering the “end state” isn’t the point. We need to be guiding individual projects so that each increment of delivery gets us collectively closer to the *current* end goal. Think of it as guiding a fleet of ships. The course may change but we need to make sure every delivery is *closer* to the vision. At the same time we do need these bridging principles embedded. Too many times a project will declare they can’t build “strategically” so they are going off to deliver something else. But why? If we know sensible “next best” solutions and can build them out in an agile way - we all build part of the vision and know which components are “furthest” from the vision. And if we all work that way maybe we actually would achieve a target vision organically ??