Software Architecture

Here are a few personal tales of software architectures good & bad.

Good: Years ago a former boss of mine was raving about what a great software architecture the Nortel Norstar product had. I asked why? He said because of the programming model, he was able to implement similar features in a fraction of the time it took developers in the Nortel DMS product. He said that he implemented multiple-appearance directory numbers in 3 weeks, while it took designers in the other product over a year. That product constantly had a short "time-to-market" for new features and profitably dominated the market. That product had a good architecture because it was easy to add new features cheaply.

Good: Years ago I implemented a bit-error testing system for a T1 hardware module. I separated the testing state machine and workflow from the details of the chip interfaces used to drive the tests. I delivered on time and got a good review. The next feature was to implement the same software for a different chip. Because I had isolated the details of the chip interfaces, I was able to reuse the state machines and extend the code. I delivered much earlier than expected and got a great review. That code had a good architecture because it was easy to extend.

Bad: Years ago I was told to listen to a "software architect" and follow his architecture on system initialization. I asked why and I was told because he was an experienced architect. I asked why his design was the right way to design it, and I was told that it was the way it was done with a lot of successful products. (Those products were generally single-controller products while ours was a larged distributed processing product). Nobody, including the architect, could explain why that method of initialization was the best architecture or design. The architecture was not provably good because there were no tests to say so. I had one test that showed that for a distributed system, it would take a very long time to initialize.

Bad: Years ago I had to implement a SNMP subagent for the Entity MIB of a complicated system (thousands of rows). I got it working with a simple table and some code to access the table. My architecture was to write a translation function that mapped the real keys of the entities in the table to indices back and forth. Different entities had different keys. Over time, this proved to be a horrible model because I ended up writing thousands of lines of code to cover the corner cases not addressed by my very basic data structure. Adding new entities and traversing the table became progressively more difficult, hard to implement, hard to debug, and messy. Somebody suggested that I use a lookup table to translate back and forth, and I decided against it. My "simple table/complex translation" architecture was bad because it was hard to extend, debug, and code and got worse over time.

Bad...to Good: More recently, my team and I built a system which enabled client software from other companies' products to talk to our servers. Because of the way we designed the system and the workflows, we had to provide lots of integration support to those companies. Furthermore, we needed a test server to allow them to test our our system, and we needed to then rebuild their software to talk to our servers when they were ready. Adding more client software would have cost a lot of money because of the integration support we had to provide. Our system didn't scale beyond a few clients. We then implemented software that tightened up the interface data flows, and automated the client's communication transfer from the test server to the production server. The new architecture was better because it allowed us to scale up the number of clients.

Software architecture is about doing new things with existing systems.

Software architecture is tough to judge. What is a "good" architecture? Why is layering good architecture? Why does normalized data have a good architecture, or why not?

Software architecture talks about the non-functional requirements of the software; i.e. the "-ilities". For example scalability, reliability, evolvability, maintainability, etc. Not all systems need all of the "-ilities" at all times.

Rick Kazman came up with a method in the mid-1990s to help analyze a software architecture. The method is fairly simple.

1) Chop up your software system into "components" and "connectors". A component is typically a large-ish object, or a data schema that is decoupled from the rest of the system, or a chunk of code. A connector is a way to get components to interact, such as an API, or a protocol, or a software virtual machine. Most systems have this intent.

2) For each "-ility" in your requirements, come up with a software development scenario to support the "ilities". For example, you may want to scale your system from the current maximum of 10 users to 100000 users (scalability).

3) For each software development scenario, mark which component and which connector have to change. At the end of the exercise, you will see which components will churn as a result of evolving the software to support the various "-ilities" and new features.

4) An architecture is considered "good" if the number of components and connectors that must be changed is minimal per scenario.

5) An architecture is considered "bad" if every scenario touches a large number of components and connectors.

This method gives tangible evidence to the stakeholders that a software architecture is good. This method also gives a quick picture of which components are sensitive to change. The software architect can then refactor the most sensitive component into a sub-architecture that is less sensitive to change, or put tight processes around the sensitive component.Tangible evidence lets software architects plan appropriate action.