Wandering back to an old topic–the concept of difference architectures and the complexity of IT solutions…

I talked about scalable infrastructures yesterday. It reminded me of another infrastructure architecture discussion I had now nine years ago. That discussion is here.  The complexity of a solution can sometimes determine how quickly it gets replaced.

Over my now 20+ years in IT I would like to say that in fact complexity leaches out of most companies. A few complex solutions are built and over time they erode, leach and eventually disappear.

Sadly complex systems tend to be the ones that aren’t replaced, often because it is hard to replace complexity. First off because the complex solution probably solved a business problem originally and now that problem isn’t a business problem anymore. The old adage “if it isn’t broke don’t fix it” applies. In the end it is broken.

Cloud offers some interesting ways to solve the complexity problem. Of course you have to allay the security and migration fears. Migrations make people nervous. They are as much about the people involved as they are about the data. In fact migrations and transitions are a huge barrier to removing complexity from the environment.

IoT and the reality of the new Internet begins to offer a new way of doing things. While the IoT reality is problematic in that there are still issues, the one thing that the Internet of things brings us is smaller deployed solutions. Many smaller sensors resulting in the end in a better simple way to do things. Just as simply as a weather sensor you can place security sensors and cameras that share information. You can quickly reduce the overall impact of security by pushing it out in the IoT form. You still have to monitor what is happening but in the end you can distribute the load and complexity to many smaller autonomous systems.

That falls well within the range of the concept I published in the MSDN article link above. The concept was Difference Architectures. Where we don’t publish huge massive architectures rather the difference of the deployed solution from the reference architecture.

Difference architectures are a great way to remove complexity from an organization. What component of the documented solution is actually also documented by a COTs (commercial off the shelf vendor) or FOSS (Free and Open source solution community) already? How much of that is embedded in the non-moving seldom updated architecture we have on the shelf there in someone’s office? If we take out the COTs/FOSS pieces how complex is our solution now? How large in the end are the documents we are creating?

John Boyd taught us that we need to orient observation and provide good information for good decisions. IF we remove the COTS/FOSS documentation from a solution do we in effect orient our ability to create a better decision?

The beauty of cloud computing was that in time you didn’t have to go to the really smart guy to get an answer. You could quickly and rapidly solve the problem of having an infrastructure. You no longer designed from the data center floor up. You simply designed the technology solution (software) that your organization would use to solve its business problems. You outsourced the physical infrastructure to your cloud service provider.

Truly having a CSP allows you to now only document the difference from what they CSP provides you to what it is that you have deployed. This allows you to now consider what is the complexity of your solution. Maybe that business problem you solved with a complex solution is begging for a simple answer.

.doc

Scott Andersen

IASA Fellow.