Technical Constraints- Software Architectures

TECHNICAL CONSTRAINTS

In software architecture design, constraints come in two basic flavors - technical and business. On most projects there are only a handful of constraints, but these constraints are a highly influential architectural driver. Constraints, as the dictionary definition above indicates, are a limiting factor and severely restrict options for making design decisions. They are also fixed design decisions that cannot be changed and must be satisfied. You could think of constraints as the ultimate non-negotiable, "must have" requirement. It is for this reason that architecture design constraints must be created and accepted with care.

Anthony Lattanze of Carnegie Mellon University, author of the Architecture Centric Design Methodology and one of the ATAM creators, likens design constraints in software architecture to "load bearing walls" employed in traditional building architecture. Load bearing walls of a building are extremely strategic and strongly influence the shape and form of the building. What's more, once these essential walls are placed and bearing weight it becomes cost prohibitive to move them.

Technical and business constraints are similarly load bearing. Many design decisions will hang on fixed constraints, further cementing them into your system's design. Adding a component or even refactoring architectural styles might be costly but it can still be done. Deciding to jump from .Net to the JVM requires demolition and rebuilding.

As architecture design constraints are so important it's worth taking some time to understand them in greater detail so you can properly deal with them when they arise.

Technical Constraints in Software Architecture

Technical constraints are fixed technical design decisions that absolutely cannot be changed. Most often technical constraints are provided by stakeholders (perhaps after some digging) at the outset of the project. Sometimes a team may choose to create a constraint, perhaps to simplify the world in which they are working. Regardless of the origin, these architecture drivers are technical in nature and are considered unchangeable and indeed very soon become so.

There are many common examples of technical constraints that you've likely seen.

·                    Programming language - often times a specific programming language will be required for various reasons. For example, the customer may be a Java or Ruby or Microsoft shop. You might simply prefer a certain language over another, or have specific expertise that dictates using a particular programming language. Nearly always, once you've picked a language you are stuck with that choice for the remainder of the project,

·                    Operating system or platforms supported - It must work on Windows, or Linux, or iOS, or Qt on Solaris, or IE 6 on Windows XP, or ... building software that does not satisfy the platform constraint means you have failed to design a software system that satisfies stakeholders' key concerns.

Use of a specific library or framework - Sometimes a specific library might be required to be used. The specific origin might come from the business but the influence is very technical. A common example at many companies is the use of specific open source libraries. Some companies might require that open source always be used. Other companies, might have an approved list indicating which open source software may be used. An interesting example at IBM is that we are required to target the "Blue" JVM, IBM's JDK for all JVM-based projects.