Architectural Patterns vs. System Metaphors

“Good architecture is like a good therapy session – it provides clarity and insight to the problem at hand.” — Anonymous

What’s the difference between an architectural pattern and a system metaphor?

An architectural pattern describes a coarse-grained solution at the level of subsystems or modules and their relationships.

A system metaphor is more conceptual and it relates more to a real-world concept over a software engineering concept.

Software development can be a complex process, and understanding the different architectural patterns and system metaphors is crucial for creating effective and efficient software systems.

By breaking down the various elements and considerations involved in each approach, you can create better metaphors to help guide your architectural patterns.

In A Practical Guide to Enterprise Architecture, James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about the difference between architectural patterns vs. system metaphors.

Key Takeaways

Here are my key takeaways:

• Metaphors are understandable by both software people and customers.
• A metaphor is more conceptual than a pattern.
• One system can have multiple metaphors.

Architectural Patterns vs. System Metaphors

McGovern, Ambler, Stevens, Linn, Sharan, and Jo write the following:

“Architectural patterns are meant for software people to use and understand.  One must study the pattern and understand the concept. 

MVC or pipes and filters have little or no basis in real life. 

The difference between an architectural pattern and a system metaphor is that a system metaphor is understandable by software people and customers alike.”

Example Metaphors

McGovern, Ambler, Stevens, Linn, Sharan, and Jo provide example metaphors:

• Library
• Stack
• Queue
• Desktop
• Account
• Directory
• Window
• Scheduler
• Dispatcher

One System, Many Metaphors

In simple language, this passage is saying that a system or a product can have different metaphors to help people understand it, but these metaphors should make sense and not confuse the users.

For example, the desktop on a computer is a metaphor for a physical desk, but it doesn’t mean the computer screen is an actual desk.

Over time, the system or product can become its own metaphor, and people no longer think about it in terms of the original metaphor.

McGovern, Ambler, Stevens, Linn, Sharan, and Jo write the following:

“A system can have many metaphors, but the metaphors have to make sense within the system to maintain its conceptual integrity.  For example, Microsoft Windows has a desktop that contains windows. 

Would it have been better for windows to be placed on a wall?  Are windows meant to move around the wall? 

By combining multiple metaphors some aspects of the metaphors must be forgotten and other must be emphasized. 

With time, the system itself can become a metaphor. 

We no longer think about the Windows desktop relating to a physical desktop or a window relating to an actual window. 

Products can become metaphors in themselves.  For example, a new system could say that the user interface is like the Windows desktop.”

Additional Resources

• Architectural Patterns (Wikipedia)
• Examples of Architectural Styles/Patterns (WIkipedia)

You Might Also Like

Architectural Styles in Software Engineering
Architectural Styles, Patterns, and Metaphors