However, technology has important trends as new approaches become established and adopted. These forces are out there, to a large extent independently of your own business. So, you need to anticipate the ones that are most relevant to your customers and integrate them into your product strategy. Otherwise, your product and services will become obsolete. So, in this sense technology can also drive the product and business strategies.
Examples of these are the use of “container” technology to deploy applications, the trend to move functionality to the “cloud” and manage it as a “service”, and the evolution of computers towards large numbers of CPU-cores in the same processor board.
We have initiatives to incorporate these technical trends into our platform so we can help customers leverage these technologies in their applications.
What makes an effective tech strategy? Like any strategy it must be driven by clear goals that are aligned with the business and the customer problems the technology will help solve.
You need a good understanding of the challenges and deployment scenarios. What is important to the customers? What do they hope to accomplish by using your product/platform? Why are they choosing you versus the competition? What is the main value they will or expect to get?
Based on this understanding establish the essential trade-offs, down select the technical approach, and key actions to implement it.
Bake in the need for iteration, evolution and feedback. Rome was not built in a day!
A successful product or platform will have to evolve over time to keep up with changing needs and technologies. It will also require bigger teams to maintain and extend it. Building upon a solid foundation is critical.
Employ good, documented, modular designs, design principles, coding practices, interfaces, documentation, testing, training for new engineers. There are many elements to this.
Remain vigilant and true to the principles of the design so that there is architectural integrity, consistency and continuity as the platform evolves.
What predictions do you have for the role of the CTO in the future? In my view, the CTO role is to develop the technology strategy, anticipate the technical trends and needs, and inspire and enable the technical teams to build the right technologies. At this high-level I don’t expect this to change much.
However, given the increasing pace of technical change the CTO of the future will need to be more collaborative and rely on architects that can place a “CTO” role within specific scopes. This will eventually become the only way to scale and keep abreast of various technologies that impact the business.
Therefore, the soft skills, ability to identify, inspire the right values and develop new talent will become a more important aspect of the job.
What has been your greatest career achievement? Inspiring and helping build a high-performance team of architects and senior engineers and leading the creation of the RTI software platform that runs some of the world’s most critical systems…
Additionally, leading the definition and formalisation of Data-Centric Publish Subscribe architecture (DDS), now supported by a broad ecosystem of companies, and considered the leading foundation for modern distributed real-time autonomous systems.
Looking back with 20:20 hindsight, what would you have done differently? There are certainly a lot of point decisions that in hindsight I would not make. To some extent it is to be expected given the need to experiment and take risk. But it is painful, nonetheless.
For example, in the early days we had a component-based software development system that was ahead of its time. People doing software were not familiar and there was pressure to align it with more known approaches (e.g., UML). We tried that and it compromised the architecture and may have been one of the reasons why it was not a long-term success. I learned that mixing paradigms and blurring the architectural basis of a product are not conducive to success.
Another example, we are now in the 6th generation of our platforms. Most generations were natural evolutions of the previous ones. Most of the software was reused, the fundamental architectural elements retained, on top of which new features and components were added. However, we walked ourselves into a corner with the 3rd generation. We lost control of the design and code quality. The code became so brittle, and the threading posture so compromised that it was impossible to debug and maintain. Eventually we had to throw all the code away and start over from scratch. We kept the concepts, algorithms and protocols, but retained none of the code. I learned that it is very important to maintain constant control of the architecture, design and code quality. If this is lost it becomes next to impossible to recover it.
We also made some technology selections that in hindsight I would do differently, like the use of Java for certain elements. This technology served us well at the time, but the subsequent evolution after Oracle took it over makes it questionable for the long term. So, in hindsight it would have been better to use cloud-native components for some of the UIs. We are doing that now, but it would be nice if we had more of an early start.
There were also many “products” we developed and did not have the success we expected. The market need was just not there. In hindsight it would have been better to save that time and cost.
|
What are you reading now? Experimentation Works: The Surprising Power of Business Experiments, by Stefan H. Thomke. I believe experiments beats theory and would like to leverage them more into our business. Most people don't know that I… Was offered a promising banking career and turned it down to become a Ph.D. student. In my spare time, I like to…Enjoy outdoor activities. I really like to hike, backpack and “get lost” in the mountains for a few days. Better yet if it can be in a remote destination. Ask me to do anything but… Don’t make me sing. You will be sorry. I really have no talent in this! |