Since Lord Nelson destroyed the French and Spanish fleet at Trafalgar in 1805, “divide an conquer” has been the mantra for dealing with complex and difficult problems. A more familiar term with the same intent is separation of concern. From separation of concern we get encapsulation, and from encapsulation we get boundaries and interfaces.

From an architect’s point of view, the hard part is to find the natural places to locate boundaries and define the appropriate interfaces needed to build a working system. This is especially difficult in large enterprise systems, often characterized by few natural boundaries and inter-tangled domains. In this situation old wisdom such as: Minimize coupling, maximize cohesion, and Do not slice through regions where high rates of information exchange are required provide some guidance, but they say nothing about how to communicate the problems and potential solutions to stakeholders in a easy way.

Here the concept of bounded-contexts and context mapping, as described by Eric Evans in his book Domain-Driven Design,comes to the rescue. A bounded context is an area where a model or concept is uniquely defined, and we represent it as a cloud or bubble with a descriptive name that define its role and responsibility in the domain at hand. As an example, a shipping system might include contexts such as: Cargo Operation, Cargo Scheduling and Harbor Movement. In other domains other names will be appropriate.

With the bounded contexts identified and drawn up on the white-board, it’s time to start to draw the relationships between the contexts. These relationships might address organizational, functional or technical dependencies. The result from this exercise is a context map, a collection of bounded-contexts and the interfaces between them.

Such a context map provides architects with a powerful tool that allows them to focus on what belongs together and what should be kept apart, enabling them to divide and conquer wisely in a communicative way. The technique can easily be used to document and analyze the as-is situation, and from there guide re-design toward a better system characterized by low coupling, high cohesion and well defined interfaces.

In the Roman world, Janus was the God of beginnings and endings; doors and passageways. Janus is usually depicted with two heads facing in different directions, a symbol you may have seen on coins or from the movies. Janus represents transitions and changes in life from past to future, young to old, marriage, births and coming of age.

For any architect software or structural, Janus ability to see forward and backward or past to future is a highly regarded skill. An architect strives to merge realities with vision; past success with future direction; business and management expectations with development constraints. Creating these bridges is a major part of being an architect. Often an architect may feel they are trying to span chasms while bringing a project to completion because of different forces acting on a project. For example, ease of access vs. security or satisfying present business processes while designing for management‘s future vision. A good architect must have those two heads capable of carrying two different ideas or thoughts, different goals or visions to create a product that will satisfy the various project stakeholders.

You should notice that Janus has two heads not simply two faces. This allows Janus to have the extra ears and eyes needed for awareness. An excellent IT architect will be a superior listener and evaluator. Understanding the reason for a capital expenditure is crucial to determining the goals and vision a management team has for the future of their organization. Being able to evaluate the technical skills of your staff with the design and technology to be used within the project will aid in creating the proper training and programming pairs to ensure a successful project. Knowing what open source solutions to use in combination with common off-the-shelf software can greatly streamline a project‘s timelines and budgets. An excellent architect will be aware of many of these disparate pieces of the development process and use them to be successful in the project lifecycle.

There are managers who demand and expect God like qualities from their architects but that is not the purpose of this comparison. A good architect is open to new ideas, tools and designs that progress the project, team or profession; she doesn‘t want to spend most of her time in management meetings or doing all the coding; he should concede to good ideas and cultivate an atmosphere for ideas to grow. It is an open mind that will succeed as an architect; a mind that can balance the many conflicting forces at work on projects. All architects strive to complete their projects and ensure the success of their development teams. The best architects create systems that stand the test of time because these systems are able to be maintained and expanded into the future as the organization grows and technology changes. These architects have listened, evaluated and refactored their processes, designs and methods to ensure the success of their work and projects; they have endeavored to ensure their products will withstand the transitions and changes that are sure to come.

This is the mindset we should strive for as architects. It is simple yet difficult to perform. Like Janus, a software architect needs to be a keeper of doors and passageways, spanning the old and
the new, incorporating creativity with sound engineering to fulfill todays requirements while planning to meet tomorrow’s expectations.