ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Why your Service Orientated Architecture (SOA) needs to be like a VW Beetle

Updated on February 16, 2015

While driving to work one morning, I was behind an old Volkswagen (VW) Beetle, one of those originals form the 60’s, proudly emblazoned on the back was the bumper sticker “Old beetles never die”.

This of course this got me thinking, why don’t old Beetles die, most modern cars end up in a scrap heap within 20 years of production, OK, in Africa we tend to squeeze a bit more life out of them, but here was an oldie, and one of many you can still see still driving around as reliable as it was 35 years ago when it rolled off the production line.

So why has the VW Beetle proved so resilient? I think it solved a definite need at the time, a cheap car that was reliable and functional, it was constructed out of simple components that were easy to manufacture, copy and maintain. Along with this, its design was based on sound mechanical principles and concepts.

The Beetle by virtue of its design is easy to maintain, the owner being able to perform most basic functions without the need of a specialist mechanic.

So, how does any of this relate to software design?

I believe that the currently popular Agile processes for the design and construction of software have been very good at addressing the quality aspect of software construction, but have quite often been misinterpreted by practitioners when it comes to addressing design issues.

All other engineering disciplines place a strong focus on the design and modeling aspects of the construction process especially in the initial stages; perhaps software designers are becoming too separated from the other engineering disciplines as a reaction to the explosion in complexity within our domain of knowledge. We as developers and designers need to remember that design and upfront system decomposition will pay dividends; the tricky part is finding the right balance.

In the engineering around the Beetle each component has a clear purpose to the whole and its relationship to the other pieces is well defined by the way it connects to them via a set of common connections i.e. nuts, bolts, hydraulic fluid, oil etc. Pieces that perform similar functionality live together in a single component that can be replaced as a unit without replacing other dependent pieces in the process. The testing of the components can be done in a black box fashion.

The bigger the problem, the bigger the hammer
The bigger the problem, the bigger the hammer

But what has this to do with building good software architectures?

Well nothing is ever clear cut, I believe a good architecture would benefit from clear units of packaging these are akin to the big components of the Beetle like the fuel pump, oil filter; they should have a clear responsibility within the architecture and help to reduce complexity within the whole.

By providing the ability to work at these varying levels of abstraction one can really get to the essence of a problem without the need to get bogged down in the detail at every level. The detail comes later, as part of the implementation.

If internal components of these units of packaging and deployment are designed in a self-contained process centric manner every piece can be easily exchangeable with other components that have the same interface.

In the design of software components the interface is the unit of reuse, not the object (Lowy), reuse is achieved via the delegation of functionality not via reuse of code. This is a common misconception that many in the object orientated world have, it's the interface to the object and never the object itself that is inherently reusable.

Thus in modern software design the use of interfaces and interface driven design becomes really important, but we see the same thing in the Beetle, non VW oil filters fit and work just fine as they have the same interface as the original, even if they perform the filtering of oil in a completely different way.

The interface forms part of the common connection, the other being the use of a Service Bus pattern to reduce the need for internal point to point connections. The Service Bus is like the oil or hydraulic fluid in the Beetle, it handles the connections between the internal components.

SOA Composition
SOA Composition

Bus, what Bus?

The use of a Service Bus pattern helps to decouple the pieces from each other, messages are passed between the components in the form of asynchronous event topics in a publish/subscribe pattern, that allows every part to be decoupled from the other part and we do not need to span transactions or hold connections between the internal components that would ultimately cause a degradation in the performance of the system.

The Service Bus should also perform the routing of messages between the components so no components would have to be dependent on the knowledge of the location of another component.

Connections between the user interface, in the Beetle think speedometer and oil gauge, will and should be point to point as this is required for the component to perform its duty within the constraints that are imposed upon it, the same holds true for software architectures.

The reduction of dependency on other parts should be driven as far down into the architecture as is reasonable, as this will lead one down the path of flexibility and testability.

The mechanical concepts that went into the design and construction of the Beetle allowed its designers to focus on the important things like meeting the needs of the public and all the requirements in the design brief.

They did not need to reinvent things like hydraulics again, a thing we seem to like doing in software design, we have a set of evolving patterns that are designed to solve certain problems, learn them, keep up to date with them and use them.

Vendors are providing some great off the self plumbing for our applications, security, synchronization, transactions, instrumentation, instancing are common requirements of all our projects we should not be recreating these solutions every time.

Good ole Clippy... So remember
Good ole Clippy... So remember

In Summary

So this is what your architecture can learn from a VW Beetle;

  • Simply defined working parts with common connections.
  • Pieces that can snap in and out.
  • No dependency on a particular brand of part by using interfaces and a clear separation of concerns within the design as a whole.
  • Speed of production and predictability achieved by the application of custom plumbing.
  • Inherent maintainability built into the lowest level component.
  • Ease of testing.


    0 of 8192 characters used
    Post Comment
    • profile image

      Qing Yang Tan 

      5 years ago

      Still doesn't really explain

      "Connections between the user interface, in the Beetle think speedometer and oil gauge, will and should be point to point as this is required for the component to perform its duty within the constraints that are imposed upon it, the same holds true for software architectures."

      Can you give an example how point to point is acceptable in software development?

    • MetalLemon profile imageAUTHOR

      Allan Rees 

      5 years ago from Brisbane, Australia

      Hi Karl

      In many systems the client portion is not in the control of the service provider. Thus from the clients viewpoint there is a one to one link between the service endpoint and the client proxy. The requirement is not a mandatory one, just how it is commonly perceived, you could implement it in numerous ways. An event driven UI to service interface is a fantastic option if that is what the problem you need to solve dictates.



    • profile image


      5 years ago

      Can you please elaborate a bit more on the following:

      Connections between the user interface, in the Beetle think speedometer and oil gauge, will and should be point to point as this is required for the component to perform its duty within the constraints that are imposed upon it, the same holds true for software architectures.

      How does this related to Service Bus? I'm having a bit of trouble understanding this contrasting statement about need for being point-to-point (vs. your opening statement on Service Bus pattern promoting a non-point-to-point design).



    • Angelllite profile image


      10 years ago from United States

      Wow! Interesting! Looks like you gave this a lot of thought!


    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

    Show Details
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
    ClickscoThis is a data management platform studying reader behavior (Privacy Policy)