My Amazon author page!!!!

I’ve spent considerable time on my blog in the past four months talking about the concepts of innovation. I pulled all of them together into what I call Andersen’s Law of innovation. I talked about the trends and realities of innovation in our ever expanding technology market.

Software Architects are people who consider what is coming when they design what will be there. In those considerations where does innovation play? Are software architects looking far enough forward to see what may be on the horizon?

Or even should they? Should software architects be looking at the very edge of what is possible?

It’s a balancing act that many software architects struggle with. How far over the horizon should I peak in building my solution. Based on the concepts I’ve been talking about in my innovation blogs I think I have some pretty simple guidelines.

Software Architects Should Innovate…

  • Look far enough ahead that your solution is still viable when fully deployed. That is fully deployed not fully architected. Sometimes we as software architects forget ours is not an intellectual profession our is a profession of action. IE we work to deploy solutions.
  • What is isn’t hard to find. What could be is a little riskier so you have to create a balance in your design. If modular is an option by all means go modular. Your opportunity to make changes to the design once it is deploying can be project saving.
  • Try to avoid missing the big trends. 1996 and the explosion that was the Internet. 2999 was the birth of cloud computing (and the shared infrastructure models). There are trends yet developing around us now – including 3d printing, virtual reality and others. Watch the trends and make sure in the end you don’t miss one.

Watch the big trends and design for inclusion. Its not as hard as it sounds. Modularity is the concept and design for inclusion is the ultimately the pattern to consider here. Modularity means that your solution can be presented, designed and built with core easily removed or modified components. This leads to the pattern I would like to propose. I will flesh this out more in later blogs but for now let’s start with the concepts of the pattern.

Inclusion – to include

The inclusion pattern starts with the concept of evaluation. Making sure we look around at what is possible now, and what is projected to be possible in the timeline of our project. We need to modify the timeline of the project to include the full deployment of the solution + 4-6 months. For larger projects this could represent a 3 year window. 3 years is about as far ahead as we can look. If your project is longer than 3 years then the pattern adapts by creating a mid-point architectural review and evaluation.

More to come!


IASA Fellow