Category: Software Architect

The natural evolution of computer technology has brought about important changes with respect to the tools that architects can use to build software systems. These changes have brought about a resurgence of interest in polyglot programming, which refers to the use of more than one core language in the provision of a software system.

Polyglot programming is not a new concept: one prominent example from the past is front-end Visual Basic clients supported by COM objects authored in C++ on the back-end. Fundamentally speaking, this architecture leveraged what those languages were good at in their heyday.

So what changes took place to fuel this renewed interest in polyglot programming?

The change is that technical standards together with ever-increasing bandwidth and computing resources conspired to make text-based protocols viable: gone are the days of arcane binary protocols as a pre-requisite to efficient distributed systems. Text-based remote interoperability largely began with XML/SOAP-based web services and continues to evolve with RESTful architectural styles and other supporting (but no less important) protocols such as Atom and XMPP.

This new breed of technologies creates far broader opportunities for heterogeneous development than ever before, simply because the payloadis formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible.

Architects can now combine specific, powerful tools that move the yardstick from previously being able to employ the right language to now being able to employ the right paradigm. Programming languages support different paradigms, in that some are object-oriented, while others are functional or excel at concurrent programming. Some of these paradigms are a perfect match for particular problems or domains, while others are a poor fit. Today, however, it is possible to ‘mash-up’ some rather unconventional and seemingly dissonant tools into elegant solutions rather more easily than in the past.

The effects of this change has begun, and manifests itself as a combinatorial increase in the architectural topology of modern software systems. This is not just a reflection of their inherent diversity, but a testament to new possibilities.

While choice is not always a good thing, it is ‘less worse’ than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].

Your job as architect has become even more challenging, because technology silos are crumbling in the face of new possibilities: embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.

[1] – The impending multicore era may well prove to be the most significant problem yet faced by the software development community.
[2] – The Free Lunch is Over – Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm

As with any profession, jargon is used so that individuals within that profession can effectively communicate with one another. Lawyers talk to one another about habeas corpus, voir dire, and venire; Carpenters talk to one another about butt joints, lap joints, and flux; Software Architects talk to one another about ROA, Two Step View, and Layer Supertype. Wait, what was that?

It is imperative that software architects, regardless of the platform they are working in, have an effective means of communication between one another. One of those means of communication is through architecture and design patterns. To be an effective software architect you must understand the basic architecture and design patterns, recognize when those patterns are being used, know when to apply the patterns, and be able to communicate to other architects and developers using them.

Architecture and design patterns can be classified into four basic categories: Enterprise Architecture Patterns, Application Architecture Patterns, Integration Patterns, and Design Patterns. These categories are generally based on the level of scope within the overall architecture. Enterprise architecture patterns deal with the high-level architecture, whereas design patterns deal with how individual components within the architecture are structured and behave.

Enterprise Architecture Patterns define the framework for the high-level architecture. Some of the more common architecture patterns include Event Driven Architecture (EDA), Service Oriented Architecture (SOA), Resource Oriented Architecture (ROA), and Pipeline Architecture.

Application Architecture Patterns specify how applications or subsystems within the scope of a larger enterprise architecture should be designed. Some common pattern catalogs in this category include the well-known J2EE design patterns (e.g., Session Façade and Transfer Object) and the application architecture patterns described in Martin Fowler‘s book ?Patterns of Enterprise Application Architecture?.

Integration Patterns are important for designing and communicating concepts surrounding the sharing of information and functionality between components, applications, and subsystems. Some examples of Integration Patterns include file sharing, remote procedure calls, and numerous messaging patterns. You can find these patterns at http://www.enterpriseintegrationpatterns.com/eaipatterns.html.

Knowing the basic design patterns as described by the Gang of Four book ?Design Patterns: Elements of Reusable Object-Oriented Software? is a must for any software architect. Although these patterns may appear to be too low-level for a software architect, they are part of a standard vocabulary that makes for effective communication between architects and developers.

It is also important to be aware of and understand the various anti-patterns as well. Anti-patterns, a term coined by Andrew Koenig, are repeatable processes that produce ineffective results. Some of the more well-known anti-patterns include Analysis Paralysis, Design By Committee, Mushroom Management, and Death March. Knowing these patterns will help you avoid the many pitfalls you will most likely experience. You can find a list of the common anti-patterns at http://en.wikipedia.org/wiki/Anti-patterns.

Software architects need the ability to effectively communicate with one another in a clear, concise, and effective way. The patterns are there; it is up to us as software architects to learn and understand these patterns so we can “walk the walk and talk the talk”.