Category: Software Architect

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.

Today’s systems are distributed and loosely coupled. Building loosely coupled systems is a bit of a drag, so why do we bother? Because we want our systems to be flexible, so they do not break apart at the slightest change. This is a critical property in today’s environments where we may only control a small portion of our application, the remainder living in distributed services or third party packages, controlled by other departments or external vendors.

So it looks like the effort to build a system that is flexible and can evolve over time is a good idea. But that also means our system will change over time. As in “today’s system is not what it was yesterday.” Unfortunately, this makes documenting the system challenging. It’s commonly known that documentation is out of date the moment it is printed, but in a system that changes all the time, things can only be worse. Moreover, building a system that is flexible generally means the architecture is more complex and it’s more difficult to get the proverbial “big picture.” For example, if all system components communicate with each other over logical, configurable channels, one better have a look at the channel configuration to have any idea what is going on. Sending messages into the logical la-la-land is unlikely to trigger a compiler error, but it is sure to disappoint the user whose action was encapsulated in that message.

Being a control freak architect is so yesteryear, leading to tightly coupled and brittle solutions. But letting the software run wild is sure to spawn chaos. You have to supplement the lack of control with other mechanisms to avoid doing an instrument flight without the instruments. But what kind of instruments do we have? Plenty, actually. Today’s programming languages support reflection, and almost all run-time platforms provide run-time metrics. As your system becomes more configurable, the current system configuration is another great source of information. Because so much raw data is difficult to understand, extract a model from it. For example, once you figure out which components send messages to which logical channels, and which components listen to these channels, you can create a graph model of the actual communication between components. You can do this every few minutes or hours, providing an accurate and up-to-date image of the system as it evolves. Think of it as “Reverse MDA” (Model Driven Architecture). Instead of a model driving the architecture, you build a flexible architecture, and extract the model from the actual system state.

In many cases, it’s easy to visualize this model, creating the literal big picture. However, resist the temptation to plot the 3 by 5 meter billboard of boxes and lines, which contains every class in your system. That picture may pass as contemporary art, but it’s not a useful software model. Instead, use a 1000 ft view as described by Erik Doernenburg, a level of abstraction that actually tells you something. On top of that, you can make sure your model passes basic validation rules, such as the absence of circular dependencies in a dependency graph, or no messages being sent to a logical channel no one listens to.

Letting go of control is a scary thing, even when it comes to system architecture. But supplemented by observation, model extraction, and validation, it is probably the way only to architect for the 21st century.