My Architecture Principles

16-Jul-2013 Like this? Dislike this? Let me know

Here are The Five Principles I employ in designing and evaluating software and systems:

  1. How do you turn it off?
    Show me a system where a rational, risk-mitigated cutover/shutdown plan can be described and I'll show you a system that has excellent technical integration capabilities and a well-designed and externalizable state and data model. Also: the reality is that systems can (and should!) have lifetimes. In general, senior managers accept system lifecycle and enthusiastic, progressive developers welcome it. Those who do not have a different motivation/incentivization profile.

  2. Focus on the data, not the database
    When building a system, start on "the inside" and work hard to define what kinds of objects, data, and other entities you need. Don't start with a set of table definitions and work backward into the code layer. This approach applies to the GUI as well, and in fact all other architecturally peripheral components.

  3. Strongly separate GUIs from everything and assume they are throwaway
    GUIs are seductive because it's what most of the users touch. It's what the user thinks the app and/or system is all about. It's how people get paid. But the GUI is not the system, and there's no such thing as a single GUI to a system. There's the "big desktop" web version, the iPhone and iPad versions, the Flash-free HTML5 version, etc, etc. There are as many GUIs as you need/want. Power users, admins, small real estate plug-ins to other apps, etc. They are all views on exactly the same underlying layer of data and functions. Furthermore, GUI technology changes rapidly or has technical deployment limitations. When the noise around Flash vs. HTML5 subsides a bit, it will be replaced with noise around HTML5 vs. HTML6. There will always be noise in the GUI space; accept it and move on. And most importantly, don't let the GUI drive the design of the underlying system (see #2 above).

  4. Assume all data designs are wrong day 1 and have to change
    Whether you take 1 day or 1 year to capture requirements for a system, the chances are very high that something will be missed. Leaving aside the process required and appropriate for truly mission-critical systems (space and submersibles, medical, etc.), for most systems the tradeoff between time to market and risk of underspecification favors the former. Therefore, you need to simply embrace this fact and keep your implementations semisoft especially in the early stages of development. If adding an extra string or double to an entity causes days (or more) of follow on work (excluding time needed to actually prep, announce, coordinate, and push a tested release), there's something wrong with the design. Some things to watch out for:

  5. Don't be distracted by standards
    This is obviously worded so as to be provocative, but it has proven useful in raising the eyebrows (and sometimes blood pressure) in a mixed room of developers and managers. The idea is to design your system first, then reach into the bag of standards to see what can be used for an implementation. All too often, a design session starts with "we will use Java 1.6 and Oracle 11g and XML and ..." There are two critical issues with this approach:
    1. The spectrum of technologies that could be used to well-implement (including support) a solution is likely artificially narrowed.
    2. Declaring components and versions is misinterpreted as "design" and the real work of crafting information architecture and software to manipulate it gets sidelined.

Like this? Dislike this? Let me know

Site copyright © 2013-2017 Buzz Moschetti. All rights reserved