By Scott Andersen
To Be Simple.
- Step 1: Reduce Complexity.
- Step 2: Document reality.
- Step 3: If in doubt refer to rule one.
I have for most of the past 20 years worried about the complexity of software architectures. I can remember visiting customers that had 200, 300 and even 500 or more pages printed and stored in an office that represented their enterprise architecture. It is in the end what inspired the first article I published on this topic nearly 10 years ago. So I thought, why not bring them all together.
Article one: Difference Architectures
Article two: The Simple Architecture Movement
Article three: The document framework of a simple architecture
Article four: The internet of IT IoIT
The concept is a reduction in software architects killing trees. Effectively as a consultant I would visit customers and would receive their architecture documents. Some were literally a single slide or a single Visio diagram. One were hundreds of pages. In both those cases the information was either useless (not enough), out of date (not updated in more than 4 years) or worse referred to things that no longer existed.
I created a set of rules to be simple above, where Step 2 is getting to real. It doesn’t do a company or agency any good to have a perfect world architecture. A perfect world architect is one that exists only on paper. In order to get from the created architecture to the deployed architecture there are effectively many things that are changed. Those need to be documented. The value of an architecture is not determining what could have been deployed. The value is in the full documentation of what really is deployed.
Many companies, and frankly everyone probably should, start with a reference architecture. Be it the reference architectures published by leading groups or the specific technology architectures created by vendors that should always be the starting point. Why? First off a reference architecture gets you known good and known performance. Sadly people sometimes do a ctrl-a, a ctrl-c and then create new document and ctrl-v and you have an architecture. Well you have a pasted copy of a reference architecture that you will then add 20 pages to. In my article Difference Architectures published in 2006 I bemoaned the Thud Factor architectures. Instead I argued then and I continue to argue that in fact all architectures need to only show the variance between reference architecture and the actually deployed solution.
Or you could also create a shared and a difference architecture guide. Where the shared architecture document would show the integration between two reference architectures and then each deployed reference solution would have a difference architecture guide as to what of that reference architecture was actually deployed and what additional components were there. This is the purpose of my publishing the framework of documents in Step 3.
This brings us to the fourth step or the Internet of IT. In my book The Syncverse I documented a concept called the Myverse. A place where all your data could be stored so that you could interact with relevant information regardless of device. It expanded on an old smart phone commercial from Microsoft about having your data in the cloud rather than on the device. It built on more than that by creating a single location where all things were stored. You could then grant access to other people so that they could share information with you or view information that you had shared. I wondered recently if I should expand that to include an ITVerse as well. I had included a concept I called the EDUverse in the original concept where teachers could build and share ideas, concepts and lesson plans (along with a lot more than that). The ITVerse would be similar in that IT professionals could share their architectures (that weren’t security) amongst other IT professionals. Seeing how 20 different versions of a deployed reference architecture looked would help people get to the value of difference architectures. The other side of the Internet of IT would be a new way to monitor and manage the IT enterprise by having interconnected sensors that reported back to a central store on all aspects of the Enterprise. Resulting in an expansion of the IoT geared towards IT (the IoIT). Imagine instead of building unique difference architectures you could see how other companies had generically installed a similar solution. So much more simple than everyone is unique.
Easy to say of course. In the end the reason why difference architectures aren’t shouted from the rooftops is the expert system. I talk about how to build more effective expert systems in my book Transitional Services. For the most part today expert systems are rental systems. You don’t tend to have high end people on your staff because you only need them once or twice a year. You rent them from Consultancy’s. Experts need to produce value for the organization and value sadly is often seen as a thud factor document. A document dropped on a desk that results in a loud noise being produced. That is why after nearly 10 years of the original publication Difference Architectures still aren’t preferred. That is why I’ve started the Simple Architecture movement. Let’s not kill trees to build software solutions. Let’s document only what needs to be documented. In the end it is much easier to update a 10 page Difference Architecture than a 300 page Architecture.