Categories
Software Architect

Dwarves, Elves, Wizards, and Kings

In Cryptonomicon, Randy Waterhouse explains his classification system for the different types of people he meets. Dwarves are hard workers, steadily producing beautiful artifacts in the dark loneliness of their caves. They exert tremendous forces moving mountains and shaping earth, and are renowned for their craftsmanship. Elves are elegant, cultured, and spend their days creating new and beautiful magical things. They are so gifted they don’t even realize that other races view these things as otherworldly almost. The wizards are immensely powerful beings almost completely unlike all others, but unlike the Elves, they do know about magic, and its power and nature, and wield it with supreme effect. But there is a fourth type of character that Waterhouse alludes to but does not mention specifically. The Kings are the visionaries who know what must be done with all of these different characters.

An Architect is a King of sorts. The Architect must be familiar with all of these characters, and ensure that the architecture has roles for all of these characters. An architecture designed only for one will only attract that one character to the project, and even with the best dwarves, or elves, or wizards, the team will be severely limited in its reach if it can only approach problems in one way.

A good king will lead all types through a quest, and help them work together to complete it. Without the quest, there is no vision for the team, and it ultimately becomes a partisan mess. Without all characters, the team can only solve one class of problem, and is stopped at the first barrier impassable to that solution.

The architect creates the quest with all the characters in mind. The architecture then becomes a guide for finding tasks for the different characters to perform while learning about each other. When a project encounters difficulty, the team will already know how to approach solving it because the architecture gave them the opportunities to grow into a team.

'Coz sharing is caring
Categories
Software Architect

Heterogeneity Wins

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

'Coz sharing is caring