There have been some questions raised that I am aware of (and probably many more that I am not aware of) about what I actually do as the CTO. The Chief Technical Officer of a company is the person with overall responsibility for corporate technical strategy. In a non-technical business, like insurance, this person would focus on the technical infrastructure of the IT organization and create an Enterprise Architecture that could meet the business needs and fulfill the business strategies in a cost effective manner. I did some of that at my company because I managed the IT organization for a while. But, because we are a software company, I have a more significant role.

I am responsible for the technical strategy of our products. In this capacity, I am the Chief Architect. To a significant extent, one of my jobs is to predict the future. I have had a long and successful career in no small part due to the fact that I am able to do just that with pretty consistent results. Predicting the future of software is a lot like predicting an earthquake. It is much easier to tell what an earthquake will be like in a particular area than it is to tell when it might occur. I am confident that I know what the future looks like. But I don’t really know when it will get here. But, because I have a vision for the future, I know which road to take every time a major decision is needed for one or more of our products.

My vision is also more than just a description of some future state of being. Because I have a vision for how businesses will operate in the future, I know how software needs to be structured to support it. Because I know how the software needs to be structured, I can create a prototype of how systems should be created if they are to fit into this future vision. My prototype has a name. I call it “The Reference Architecture”. It is very much like the concept cars that you see coming out of Detroit and Italy and other automotive design centers. No one really expects to see a concept car on the road in 10 or 15 years. But we do expect to see pieces of it, certain features or aspects of these cars, in new cars in the next year or two. The Reference Architecture is like that. We may never create a software product that contains everything that exists in the Reference Architecture. But pieces of it should appear in releases every so often for every product.

For example, the Reference Architecture is based on a Service Oriented Architecture. This means that the client software does not contain business logic. This logic should be placed on the server. In addition, it should be accessible by external systems other than the client software. It should perform important business functions that have value no matter how they are accessed.

The Reference Architecture is not a secret. It is an important concept that has been developed in conjunction with and communicated to the senior Architects and Engineers of the organization. It is their job to determine, on a product by product basis, when and where we are able to implement portions of it to gradually move products toward the future state. Sometimes the changes are big like the time we rewrote a product and adopted a major portion of the Reference Architecture. Sometimes the changes are small, like the time we adopted a new UI which was one step closer to the UI defined in the Reference Architecture. But the Architects in both cases were well aware of the direction I felt we needed to move in and were responsible for making the decisions to adopt to a greater or lesser degree, the elements of this architectural strategy.

An Architect is a significantly different role from an Engineer. An Engineer has a clear problem and a set of coding tools he or she uses to solve that problem. An Architect is in a different situation. They have a reality in front of them along with a vision. The only tool they have at their disposal to move from the current reality to a reality closer to the vision is their imagination and their ability to gain the cooperation of their development team. Their only means of communication is through design elements – strategies, components, frameworks, and detail designs. But no one on any engineering team should ever believe that an Architect is just someone who is authorized to decide how a new problem gets solved. An Architect’s job is always to solve a problem in a way that moves a code base from where it is today to where it is going tomorrow. Without a vision for the future, no Architect can function. As CTO, my job is to clearly set that vision. An Architect’s job is to implement that vision for me. To paraphrase Peter Drucker, my job is to specify the right thing to do. The Architect’s job is to specify the right way to do it.