software_architecture

---

---

Software Architecture

The term software architecture intuitively denotes the high level structures of a software system. It can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations.
The term software architecture also denotes the set of practices used to select, define or design a software architecture.
Finally, the term often denotes the documentation of a system's "software architecture". Documenting software architecture facilitates communication between stakeholders, captures early decisions about the high-level design, and allows reuse of design components between projects.

Software architecture is a term used to describe the organization and design of the components and relationships between objects both within a program and external to the program. The term can be applied at the lowest level to a single object such as a table, procedure, or view, or to the highest level of an application such a linked server, web service, or extract/transform/load(ETL) process. Software architecture includes descriptions of the interfaces both between internal and external objects and input/output(io) to include the specification of a design pattern. The term typically does not encompass requirements internal to objects such as naming and code formatting standards.

The term software architecture does not imply a level of quality; a software architecture may be either good (sound, solid, reliable) or bad (not sound, fragile, unreliable). My intention here is to define what makes up a software architecture than can be described as either good or bad, so that you may know both what to do and what to avoid. A software architecture should be evaluated on the same basis as the architecture for a building or the design of a machine.

"Therefore whosoever heareth these sayings of mine, and doeth them, I will liken him unto a wise man, which built his house upon a rock: And the rain descended, and the floods came, and the winds blew, and beat upon that house; and it fell not: for it was founded upon a rock. And every one that heareth these sayings of mine, and doeth them not, shall be likened unto a foolish man, which built his house upon the sand: And the rain descended, and the floods came, and the winds blew, and beat upon that house; and it fell: and great was the fall of it." - Matthew 7:24-27 KJV

---

Consider the attached chart. The blue line represents an efficiency of 90%, a cost of 100 per cycle, and a reusability of 30%. The red line represents an efficiency of 70%, a cost of 25 per cycle, and a reusability of 5%. It is easily seen that the more efficient process that costs more per cycle and has better reusability rapidly catches up to the less costly process in terms of overall cost. It will continue to cost less going forward. The basic formula I've used here is:

set [total_cost] = 
     [cost] - (sum([existing work]) * [reusability]) + 
     ([maintenance cost] * sum([existing work])));

Please note that I'm not working towards a degree in Production Engineering, Economics, Physics, or any esoteric science so I'm not putting this formula out there as something that is anything other than a guide. This is something that anyone with a spreadsheet can do. Seriously. Be critical of my formula. Build your own. Plug in your own numbers. Unless you are completely oblivious to simple facts, it becomes rapidly obvious that a more efficient process producing a product requiring less maintenance and with better reusability of components is almost always the better choice.

"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." - Albert Einstein

Consultants love this chart! They are well aware that hammering in lots of code cheap in the short term ends up in a huge payoff down the road due to maintenance costs. They also know that that the smaller the up front effort required the happier the client will be, regardless the long term cost.

---

---

Measures of a Sound Architecture and Means to Achieve Them;

---

• Reusability

  Reusabilityis the likelihood that a segment of source code can be used again to add new functionality with slight or no modification. Reusable modules and classes reduce implementation time, increase the likelihood that prior testing and use has eliminated bugs and localizes code modifications when a change in implementation is required. Subroutines or functions are the simplest form of reuse. The ability to reuse relies in an essential way on the ability to build larger things from smaller parts, and being able to identify commonalities among those parts.

Software reuse is an often overlooked but incredibly important facet of software architecture and design. As the chart above shows, reuse can dramatically reduce the cost of software over only a few cycles.

---

• Robust

  *robustness is the ability of a computer system to cope with errors during execution or the ability of an algorithm to continue to operate despite abnormalities in input, calculations, etc. The harder it is to create an error of any type or form that the computer cannot handle safely the more robust the software is. Formal techniques, such as fuzz testing, are essential to showing robustness since this type of testing involves invalid or unexpected inputs. *

---

• Extensibility

  Extensibility is a system design principle where the implementation takes into consideration future growth. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The central theme is to provide for change – typically enhancements – while minimizing impact to existing system functions. An extensible system is one that can be upgraded to fully handle new data. In systems architecture, extensibility means the system is designed to include hooks and mechanisms for expanding/enhancing the system with anticipated capabilities without having to make major changes to the system infrastructure. A good architecture provides the design principles to ensure this—a road map for that portion of the road yet to be built. Extensibility can also mean that a software system's behavior is modifiable at run time, without recompiling or changing the original source code. For example, a software system may have a public Application Programming Interface that allows its behavior to be extended or modified by people who don't have access to the original source code. The extra functionality can be provided through either internally or externally coded extensions.

---

• Maintainable

  maintainability is the ease with which a product can be maintained in order to: isolate defects or their cause, correct defects or their cause, repair or replace faulty or worn-out components without having to replace still-working parts, prevent unexpected breakdowns, maximize a product's useful life,
  maximize efficiency, reliability, and safety, meet new requirements, make future maintenance easier, or
  cope with a changed environment.

---

---

To facilitate the above methods, software should be designed with the following considerations:

Self documenting - Software that is easy to read and understand will be extended, upgraded, and reused. Software that is difficult to comprehend will be ignored.
Encapsulated - Software that is encapsulated well is easier to reuse as the interfaces and components are easier to find. Software that is poorly encapsulated is difficult to reuse as it is often so embedded within the functionality of the whole system that is difficult or impossible to use it elsewhere.
Simple
Design Patterns - A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise.
Adaptable
Testable - uUit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use.
Cohesive
Loosely Coupled
Modular
Encapsulated
Asynchronous
ACID compliant
Self documenting - Software that is easy to read is also easy to maintain.
Normalized - Database normalization is the process of organizing the fields and tables of a relational database to minimize redundancy and dependency.
Loosely Coupled

---

---

*An example of poor design done intentionally

During my twenties I worked for a year at Martin Marietta just outside Baltimore, Maryland. My primary responsibility was to work on five automated welders that the Cecil C. Peck company had built for the VLS program that built canisters in our facility. Two of the welders were in intermittent use but required constant maintenance. One of the welders have never run. Two of the welders worked at one point but worked no longer. The primary cause for failure on the welders was on the ball bearing slides and stepper motors that drove the welding heads and carriages.

Good slide design is to limit the travel of the carriage to within the length of the bed, never "over hanging" at any time. These slides were built to over travel as much as 70%. Due to the extreme torque loads inherent in this kind of operation these slides failed at an alarming rate. On each machine there were perhaps as many as several hundred slides, most of which were unique. Martin Marietta had to buy and stock spares of all of them to keep the machine running. Since these slides were custom built by Peck and intentionally did not follow best practices, Peck was the only supplier. We did rebuild a lot of slides internally, a process that kept a mechanic working almost full time every day.

Good stepper motor design limits the speeds and torques to within the duty rating of the motor. The motors on these machines were over driven to the point where they were failing within a few weeks of being put into service. Steve was the primary mechanic for these machines (and I DO regret forgetting his name! I learned a lot from him!) and I once evaluated the motors in service and found that, for most sizes, there were three different shaft sizes and both rotations as the leads had been changed internally. In other words, Peck was taking one motor, ordering it in three separate shaft sizes (where one would have done), then changing the leads internally to provide six different configurations of motor that we had to stock for what have been a single application. The manufacturers identifications had been stripped from these to prevent us from bypassing Peck in the purchasing process.

This is a case where an unscrupulous vendor intentionally built a design that was fragile, tightly coupled, poorly documented, and fragile. Take a look at the "wooden ships and iron men" story in [what_management_does]. Sometimes bad designs are built out of ignorance, stupidity, or incompetence. Too often they are built out of arrogance and maliciousness. The result to the user is the same.

---

---

copyright Katherine Elizabeth Lightsey 1959-2013 (aka; my life)

"A doctor can bury his mistakes, but an architect can only advise his clients to plant vines." - Frank Lloyd Wright