Architecture: It's about balance

After my talk for NETDA, someone come up to me with a question about architecture. I emphasize during my talks the importance of simplifying your product’s architecture when you plan to add concurrency. I think a simple architecture is required regardless of the application but is absolutely vital with concurrent applications. The questioner wanted to know to how to convince management that an architectural change is needed. The answer....

Money

An architect straddles the line between business and technology. An architect isn’t out selling the product but she absolutely must understand the impact each technology decision has on potential business. Architectural decisions rarely adhere to technical purity but are a balance between technical purity and business opportunity. There must be a compelling business reason to change an architecture. If there is no business reason, then it is usually more cost effective to leave things alone.

Here are some monetary reasons to change an architecture:

1. To increase architectural flexibility. Increasing architectural flexibility enables engineering to respond faster to new market requirements and even...new markets. Architectural flexibility is vital for startups and small companies because the target market is often moving. It is common for a startup to create a great product idea way before the market is ready for it and as a result have to quickly adjust to a new market. The more flexible the product architecture the faster (and as a result cheaper) the engineering organization will be able to adjust to the new requirements.

Example: Company A (circa 1997) came up with the idea of using user defined patterns to extract data from 3rd party websites. Structuring the unstructured data found on the web. Some people know this as web scraping and this was used early on to do pricing comparisons between vendors. The problem was that Company A was ahead of the game, so they had to branch out into other technology areas. The focus shifted from the web to collecting ANY unstructured data and making it structured. This had a serious impact on the architectural integrity of the product. The company ended up with a tightly coupled architecture (spaghetti code) which made the code prone to bugs, hard to maintain, slow to respond. All of which added up to missed business opportunities because the architecture was not flexible. When I talk about missed business opportunities I’m not saying that they were unable to go after different markets with the product they had. I’m saying that they could have packaged the same code in different ways to create the perception that the products were specifically designed for a given market. Building focused product and marketing efforts that appealed specifically to the target market WITHOUT impacting any of the core product line. This could have been done if the main product line had had a flexible architecture.

2. Improve product quality. There are a lot of good things that come from a good architecture and that includes product quality. I’ll define "quality product" as a software product that works as expected, is stable, easy to enhance, and easy to maintain. At the root of any product is the product’s architecture and poor architectural decisions will result in poor product quality.

Example: Company B (circa 1996) had decided several years prior to my arrival, that they needed to build a new casino video game system. It was a market that they were already in, so they knew what the system had to do. They choose an embedded system; built the operating system, payout system, configuration system, and games. Everything done in-house. The problem was that they were two years late with no end in sight because the system was so buggy. Part of the problem was that the system was built by hardware guys with a lot of hardware experience and very little software experience. Fortunately they knew they were in trouble and hired a software gal...me. Their problems were all fixed by a simple change to the architecture. Seven months after I started working with them, they were good to go. The product was approved by the Gaming Commission and the company was successfully sold. Architects who are inexperienced or technical purists will often try to redesign an entire architecture. That is rarely cost effective. A good architect balances the business needs with the technology needs to create a compromise that lets both sides win.

3. Improve productivity. As I said it’s about money. So if by making an architectural change you can help your company either save money or make money by increasing productivity you can usually sell that to management. This is usually the type of thing that happens for internal projects. But productivity gains can also occur by enabling unit testing, increasing the ability to add enhancements, speeding up maintenance, automating help file generation, etc...

I’m sure that there are other reasons to change architectures. Changing tools, enabling other OSs, etc... but at the end of the day; if you don’t have a compelling business reason to make the change (which is usually directly tied to some revenue opportunities) leave the architecture alone.