Architecture As Requirements

AntiPattern Name: ArchitectureAsRequirements

Type: Design

Problem: Designing and specifying the architecture of a system

Context: Architecture design; especially for a new system with a "clean slate."

Forces:

A new system is being designed. Designers want to use the BestPractices and BestTechnology? available. There often is a new-fangled technology/product/process in the marketplace; and/or the design team/architect has a "pet" favorite technology. There is no compelling customer reason to use any particular technology.

Supposed Solution:

Use of such technology/product is written as a requirement into the product definition, as if articulated by a customer. Alternately, supposedly neutral requirements (of minimal or no importance to the customer) are written added to the product definition, when in fact these "neutral" requirements force the design team to consider only the intended technology/product, and reject all other solutions. (In other words, a LockoutRequirement is added.)

Note that this is only an AntiPattern if there is no bona fide customer requirement to use the product/technology. If the customer specifies Oracle be the RDBMS or Windows be the OS, then it's his dime and his problem if things go wrong. Many times interfacing to an existing system constrains the architecture.

There may be other external forces, outside the team's control, dictating a particular architecture as well. In some cases, this may still be an AntiPattern (i.e. a PointyHairedBoss who insists that everything will be done in Windows, come hell or high water); or legitimate (i.e. requiring a networked embedded system supports SNMP, because that's what is used on the manufacturing floor for manufacturing test purposes).

Unsubstantiated appeals to quality (i.e. "We have to use YYY, not XXX. Code written in XXX is all crap") or speed ("We can't use CommonSmallJavaSharp?, it's too slow!") don't count as creating a bona-fide requirement. A good rule of thumb is to ask "does the customer really care?" If not, it doesn't belong in the requirements.

Resulting Context:

Often times, good things -- if the solution chosen is in fact a good one. In many cases, though; the new technology is unfamiliar to much of the design team, and may result in poor quality code (from using an unfamiliar tool in an inappropriate way), slipped schedules (due to steeper learning curve), or outright neglect of true customer requirements (which might not be as easily implemented in new technology).

In extreme cases, design team falls in love with the new technology, and it and not the customer becomes the design team's primary focus.

In very extreme cases, folks who disagree with the use/application of the new technology are called Luddites and similar things.

Design Rationale:

Use of best practices and new technology is often seen as a good thing. (And when the practices/technology is mature, it often is a good thing).

Related AntiPatterns:

GoldenHammer, TheCustomersAreIdiots. Often, this is the result of a BlowhardJamboree.

Applicable Positive Patterns:

Ensure that only true customer needs are listed in the requirements, than give the design team the freedom to specify any architecture capable of meeting those requirements (and other constraints, such as schedule and cost). If cool technology X still meets the requirements, great. If not, then you've likely saved yourself a lot of money. But giving the design team the freedom to discuss alternatives is the right way to go.

Another positive patter would be the PlanningGame. Usually, the requirements document is written and owned by the development team and it is up to the users to determine if the written requirements are sufficient and necessary for their needs. It is better to turn things around and allow the users to define what is sufficient and necessary and leave it up to the development team to determine what is feasible and reasonable. [This won't prevent development teams from bickering over technical issues, but these issues won't be given the appearance of customer mandates or implications.]

AntiPatternCategory: [classify it]

Also Known As: [other names]

Examples in the Literature:

Examples in Practice:

Some given above.

Some folks fall in love with a particular technology, and then profess that any system implemented in it is inherently superior than a system implemented in a "lesser" technology. Many (not all!) criticisms against Unix (LanguageIsAnOs, TheUnixHatersHandbook) seem to be of this variety, i.e. it's written in C, so it must suck.

Guys, we're doing it again. This mistake of equating the bad practice of architecture with architecture itself being a Bad Thing. Stop that! Bad doggie! Down! Down! No!

As with any professional endeavor, architecture can be misused or performed poorly. Let's please stop blaming architecture and architects in general for the bad behavior of a few spoiled apples, shall we? Hmm?

CategoryAntiPattern, CategoryArchitectureAntiPattern