An Attempt at Pictures for Implement by Feature vs. Architecture

Joshua asked me to clarify what I meant by implementing by architecture. Here's my picture-story.

Architecture by layer
Architecture by layer


When a team implements by architecture, they tend to be functionally-based teams implementing across the architecture.

When a team implements by feature, they are cross-functional teams.


Feature slices by teams
Feature slices by teams

When teams implement by feature, they do what's needed in whatever part of the architecture is needed. To the outsider, it looks a little messy—sometimes incomplete. But to the team, the architecture is cohesive. And, most importantly, the team is not writing code they won't use.

When teams implement by architecture, they are too likely to implement more than they need—ever.

4 Replies to “An Attempt at Pictures for Implement by Feature vs. Architecture”

  1. Of course, you can also implement by feature even if your teams are laid out in terms of technical specialities. It just means that some people from each team are collaborating on a feature for a while. They will all be expected to show that the feature works, is complete, etc.
    Cross-functional teams aren’t a pre-requisite for implmementing by feature. To indulge briefly in a straw-man argument, if you define cross-functional teams to be teams without technology specialisations, you have an organisation that won’t scale in some directions.
    So, of course, we don’t define them like that. Some religiously-agilist people might attempt it, but presumably such people are already working on projects that don’t need to scale across technologies.

  2. We are in the interesting situation where we are re-evaluating some core architecture choices for a new module (that could be seen as an application by itself). So far our main product has been based on our own home-grown framework.
    We are now looking at ‘community’ frameworks for web based applications (Zope, Rails, Seaside,…).
    If we implement by feature this new module, I am not sure when the architectural R&D work will take place. Right now I am thinking of ‘burning’ one or maybe two iterations to explore our architectural alternatives; but this means not working on the features. Or maybe we could identify a small feature that we would implement with the different alternatives and then compare. This could be expensive!
    What do you think?

  3. This reference to set-based design may be helpful. Having several ‘spikes’ may be cheaper than choosing an inadequate approach too early.
    Credit to Bill Wake.

  4. Pingback: Managing Product Development – Johanna Rothman: You Need Feature Teams to Produce Features | Project Management Buzz

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.