Becoming more architecturally aware - part 1

Application frameworks should be understood on more than a surface level

In my Mind the gap essay and Why Software Projects Fail presentation, I talk about how we as developers should be more architecturally aware if we are to bridge the gap between the code and the overall design. I include myself in this statement because recently I've started adding functionality to an existing ASP.NET website and I've found it essential that I become as architecturally aware as possible in a short amount of time. Let me provide a couple of real world examples.

Although I'm adding behaviour that is in effect isolated from the rest of the application, my code is still a constituent part of the overall architecture. In addition, I'm using some of the utilities and frameworks that the development team have already produced. Clearly I need to understand the usage patterns in order that I can be productive as a developer on the team but, furthermore, I need to understand something about the inner workings in order that the code I write is architecturally compliant with the rest of the system. I'm sure you've seen this yourself, but give a few people the same framework and you'll see usage patterns that you hadn't even dreamed of. Some will be what you expected, some may be better than what you expected and some may break your framework in horrible ways.

If somebody on the team is taking responsibility for the architecture and undertaking reviews, it's possible to catch those instances where application framework code isn't being used as anticipated. Sometimes, it's even possible to automate these architectural conflicts with a set of automated unit tests. If, however, nobody is taking on this architectural guardian role and everybody is simply using what they've been provided with, then this is where problems start to creep in. Sometimes they creep in from people adopting a copy-paste approach to development (i.e. copying another class because it "works") and sometimes they creep in because people just aren't aware of the hidden side effects of their framework usage pattern. Either way, problems introduced because of a lack of architectural awareness might not show up during local single-user testing, but could prove critical when the system is rolled out to a wider user base.

The only way to get really productive with existing application code is to dive into it and understand how it works at both a conceptual and implementation level. Only then can you ensure that the code being written is compliant with the rest of the architecture, which is crucial for the quality and integrity of the solution. This is one way in which developers should become more architecturally aware and next time I'll discuss another.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Re: Becoming more architecturally aware - part 1

Doing .NET?! We'll convert you yet ;-)

Re: Becoming more architecturally aware - part 1

Yup ... deep into VS2008, C# and ASP.NET at the moment!

Add a comment Send a TrackBack