Feature Centric Development and architectural decay

My previous post was about the difference between a component based organizational architecture, and a feature based one. In this post, I’ll raise a concern that is increasingly being heard in the software development business, about FCD and agility – unless special attention is given – increasing the risk for architectural decay and future technical debt.

In the previous world of component based organization, architecture was in focus almost “by nature”: basically, you can’t split up a system into components, and allocate components to teams, unless you have some idea of the overall architecture of the system containing those components, and of the interfaces between the components. In the previous world, the typical pattern was for the system architects to decompose the system into subsystems and components, and then allocate the system requirements to these various components. So, the notion of architecture was very visible, and implicit in the process and the organization. The #1 area of focus for anyone in the organization with the “architect” tag on his or her job description was architecture, and no wonder then that architecture and the architecture workflows received significant attention.

Now, in the world of agility and FCD, the #1 item of focus is no longer architecture, but the feature. As described in my previous post, a cross functional team now takes a feature, typically spanning many layers of the architecture, and many components, and realizes that feature end-to-end.  With many feature teams working in parallel, many changes per day are made to the system, in many corners of the system.  Although this new way of working brings with it a potential for much higher speed in development, and a much better probability for building the right product, it also brings with it the risk of architectural decay over time, and thereby an increasing technical debt. As each feature team is focusing on implementing their feature, making any and all changes necessary to the system, there’s a clear risk that these changes, while perhaps efficient in short term, will cause architectural decay and result in a need for major restructuring and refactoring later on.

Thus, organizations doing FCD should pay attention to this problem, putting measures in place to continuously verify architectural integrity, and also allocating time and resources, e.g at end of each iteration, for refactoring.

So, while there in today’s agile and FCD world seems to be lot less focus and “buzz” about architecture, I’d argue that focus on the architecture discipline is more important now than ever before. With agility and FCD we have got rid of the old “ivory tower” architecture practices, where system and software architects were sitting in perfect isolation building “the perfect architecture”, with little F2F contact with those responsible for implementing the system. The architects of today, now sitting in the cross functional teams,  are as important as ever before, and since they are now part of the teams, sharing the end-to-end responsibility for realizing the features, we can hope for increased development velocity combined with better overall quality of the systems we develop. However, someone in the organization must still have the overall responsibility for the integrity of the system architecture.  There are some interesting technologies in the works, such as IBM Research’ System Grokking, that might become essential tools for continuously monitoring and ensuring the integrity of future system architectures.

As an interesting coincidence, Garter Group will do a webinar on the theme of agility and  technical debt, on Thursday April 19th.  While I’m generally skeptical to most of what industry analysts (not to mention financial analysts! 🙂 say – those guys are rarely real users of any of the technology they have opinions on – in this case it might be interesting to hear what kind of experiences on agility and technical debt they have gathered, and what conclusions they have drawn.

Oh, and a final note: I find Conway’s law very much to the point:  if your organizational architecture is silo based (functional/product) , then the system you produce will also be  silo based.  As a corollary to Conway’s law, if you want to produce a system that is holistic, then you’ll need to restructure your organization to be holistic. Cross functional / feature teams is a major step in that direction.

About swdevperestroika

High tech industry veteran, avid hacker reluctantly transformed to mgmt consultant.
This entry was posted in development, Management, Organization, software, Systems and tagged , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s