I have been working a web-base membership administration portal for a while now, and I have not got the architecture right yet. This has been causing me some concern. By architecture, I mean the:
- common software components of the application
- common patterns of the application
- common idioms and programming techniques of the application
By concern I mean sleepless nights, nail biting, hair loss... Well, not quite that bad.
Sacred Architecture
I have always struggled with software architecture as a concept. Every project I have ever worked on has suffered from uncertainty at the beginning as to the correct architecture for the software. Frequently this has led to the creation of a sacred architecture for the application. This is usually the work of one key architect who invests ego and credibility into the design.
These sacred architectures have usually been large, complex and inflexible as the designer tries to anticipate every possible requirement of the software and build a universal architecture to solve all problems. There are several problems with this approach:
- There are too many compromises in the design
- It is difficult to change the design to meet the needs of programmers
- It frequently leads to the constructions of frameworks
The architect makes compromises between different elements of the software as he tries to anticipate every possible requirement from the Product Owner or the programmers. This leads to strange design choices which constrain the programmers in future and require them to write complex code to work around the limitations of the architecture.
Changes are difficult to make to the architecture for many reasons. First of all, the architect may be over-invested in his design. Since his ego is on the line, he may not be receptive to suggestions for changes.
The architecture is likely to be complex in order to meet imagined future needs. I also find that designers overuse the technique that they are personally most interested in at the time (e.g. overuse of a particular design pattern).
Hand-in-hand with complexity goes over-generalisation. This is where the designers is so uncertain of the future needs of the software, he generalises all meaning and business logic out of the design. For example, an architect may create generic Data pods that can be configured to contain any data rather than simply constructing the data classes specific to the domain.
I have also seen over-configurability built in to systems where the architect has tried to anticipate unknown needs. This leads to lengthy and incomprehensible configuration files that add no value to the software because only one set of configuration values ever gets used.
All these factors make the architecture sacred holy-writ. That is to say the architecture becomes something that is never questioned and never changed. Rather than support the process of rapidly developing great quality software, the architecture becomes a barrier that the programmers spend their time working around!
Frameworks
I wanted to have a brief aside on frameworks at this point. A framework is a set of software components and APIs that are designed to provide support facilities to programmers. I think that technical frameworks such as ASP.Net, NHibernate, the Win32 API etc are great. I do not think that business applications should have a framework however. For me, frameworks embody and reinforce everything that this wrong with software architecture.
If they are designed at the start of the project then they almost certainly will not meet the fluid needs of the programmers. As noted above, frameworks also have a nasty habit of become sacred holy writ! Projects and teams get forced into using the corporate framework because "that's how we do things" regardless of how appropriate the framework might be for the project. This has happened to me on a few occasions over the last ten years! As frameworks get used on more and more projects, the impact of changing the framework code grows and the probability of being able to make a change to the existing behemoth code to suit a new project falls...
How I Learned To Stop Worrying
I have stopped worrying about the architecture of my portal project. My Agile training tells me that I cannot anticipate the future requirements of users and programmers. Rather than leading me to create a generalised framework, I am using "just enough" architecture to solve the problem at hand.
This means that I started with an ASP.Net web application, a Data assembly containing NHibernate classes and a Business assembly containing the business logic. That is about as simple as architecture gets! Yesterday I noticed that my Data classes are getting a little bloated. For example, I have a ShortText class that has reached a massive 354 lines of code. The ShortText class has been becoming a little unwieldy for a while, so I had a detailed look at it.
My architecture has meant that the ShortText class had developed the following responsibilities:
- Data access properties
- Add new ShortText to the database (also Delete)
- Load a ShortText cache from the database
- Get a page of ShortText data for display in a grid
Rather than agonise about the "bad" architectural choice I made, this morning I have been laying out plans for refactoring the Data and Business layers slightly differently. By "laying out plans" I mean scribbling some pseudo-UML on scrap paper (I don't smoke) and thinking it through for no more than ten minutes.
Clearly data access properties belong in the Data Layer, but everything else can be refactored in smaller, more testable and reliable units. My refactored / re-architected solution is:
- Data access properties -> Mcl.Data.Text.ShortText
- Add new short text -> Mcl.Business.Text.TextManager
- Load a short text cache from the database -> Mcl.Business.Text. TextCache
- Get a page of ShortText data for display in a grid -> Mcl.Data.Text.ShortTextPagedView
I am still not 100% happy with this. My split between Data and Business still looks a bit arbitrary, but for now, this is my new architecture. I am fairly sure that in three weeks time things will have changed again as I realise that some new functionality cannot be implemented easily using my new approach! As soon as that happens I will refactor and re-architect once again. This is
Architect-As-You-Go.
Benefits
This flexible approach to Architect-As-You-Go has several key advantages:
- You are writing production software for your customers almost immediately - there is no need to have an architecture iteration / sprint
- I will never get to the stage where something cannot be done with the existing architecture
- I feel good because I am never fighting the code - it always flows and morphs to meet my current needs
- The impact of change is limited to this project alone, although I retain the ability to re-use small, tested classes in other projects
- For performance sensitive software you can continually "tune-up" the architecture for maximum efficiency
Challenges
There are also a few problem areas:
- Time spent re-architecting adds no direct value to the customers
- I have to keep refactoring the tests and web application whenever I make architectural changes
- I am refactoring so much now that I am going to need to buy some tools to help me out!
Automated Testing
I think that there is a definite need to have automated tests when you Architect-As-You-Go. You will not be able to maintain reliability of your code base in the face of frequent of wide-ranging changes without these tests.
Conclusion
My recommendation is to avoid sacred architectures and frameworks and do "just enough" architecture working to support your current iteration / sprint. Do not be afraid to change your fundamental architecture and make sure that you have built the necessary automated tests to ensure that your software survives the Architect-As-You-Go process!