10 May 2015

Architecture Reboot – Bring out your Devs



One of our Developers is Missing
CTO: Where are your developers?
Chief Architect: Not sure what you mean… We’re an architecture and strategy function.
CTO: I know that, but where are your developers?
CA: They’re in the delivery function.
CTO: No. Where are YOUR developers?
CA: Ah! I see what you mean. Yes, some of our architects come from a development background.
CTO: I would hope so! Where are YOUR developers?
CA: Oh! I’m not being clear. They don’t just come from a development background. I make sure they are all still keeping their skills up to date and many of them still develop code at home.
CTO: I WOULD HOPE SO! WHERE ARE YOUR DEVELOPERS?
CA: You’re not getting this are you; we’re an architecture function. WE DON’T DO DEVELOPMENT!

And therein lies the problem…

A Little Recent History
When I took over as CTO at the Department for Work and Pensions I changed the shape of architecture function and created three pillars. The first consisted of solution architects dedicated to specific lines of business creating solutions for projects that met the user need and exploited or improved the capability they already had. This was primarily what the CTO office did. I also created a domain architecture team to look at how we would strategically transform the user landscape to make use of the latest technology across the DWP.

It was in the third pillar that the model really changed. I also created the experiment team; a team of agile developers and technology leads responsible for building stuff. You might think of this as an innovation team creating prototypes and trying out new technologies to investigate the art of the possible, but you would be wrong. You might also think of this as a team dedicated to helping the solution architects test out their solutions and make the architectures real, but you would also be wrong.

The point of this team is to act as an incubator for new ideas. To take those ideas from loosely formed concept through alpha to a working “beta” in as short a time as possible. I use the term “beta” here in its true sense; real code providing real functionality to real users performing real work.

But doesn’t that just sound like an agile delivery team? Well in a sense yes, it is, but there is a difference. This team does not work separately from architecture and strategy, nor does it work on behalf of architecture and strategy; it is strategy and architecture.

Strategy Through Doing
Tom Loosemore of GDS made this point very clearly when he demonstrated some work he and his team had been doing. What he had produced was very much working code, developed using a rapid product design approach focusing on user needs. It explored an idea to turn a highly complex set of activities into an incredibly simple and helpful service by simply looking at how the user interacted with that service…

Out of this work emerged not just a working prototype, but also strategy, understanding and architecture. It also generated belief in the strategy in the audience to which he demonstrated his work (well it did in me and those I spoke to so I’m assuming it did in the rest). At this point you might want to read my previous blog post “The Art of Persuasion – Touch it,Live it, Believe it” about exactly this approach.

This was very much an affirmation for me. It confirmed that I was not alone in my belief that real strategy emerged not out of thinking but out of doing, and architecture was simply an articulation of this strategy – a formal record of the doing if you like. Much of architecture as we know it today is a detailed explanation of what we are going to do, or what we want others to do. If you’ve already done it, the architecture can be much shorter and much simpler; perhaps just a single annotated diagram.

What is more, you don’t need to create communication material and presentations to convey your strategy and architecture and your architecture function no longer needs to spend 80% or more of its time “communicating”. It can convert that time into doing the thing and showing the thing.

Developers are Architects
This does not mean all your developers sit in your architecture function. Not at all. If you are into technology then you should have developers in every part of your technology department. In fact, everyone in your technology department should be in one way or another a developer, be it a developer of code, a developer of user experience or a developer of great service to the customer. You should have developers who create stuff, developers who scale stuff, developers who improve stuff and developers who fix stuff. You should even have developers who get rid of stuff.

In conclusion, I believe we have forgotten one very important thing. Development is not just building code; it is not a production line activity that follows strategy, architecture and design. Development IS Strategy, Architecture and Design and developers are designers, architects and strategists (not the other way around).

So, when you look at your Architecture and Strategy function ask yourself just one question.

Where are my developers? 

Regards
The Enterprising Architect

No comments:

Post a Comment