So what does this mean? I believe this is closely related with the definition of IT Architecture and how we architects are performing this art. When building a solution why do we need complex patterns? Why are those block diagrams so complex and big? Do we really need these boxes here and there? If you look from an artistic viewpoint painting a very simple drawing is risky for the artist. If you draw a 15m x 15m drawing on the wall of a building then people seeing it will appreciate the amount of labor and the difficulties on painting such a big thing.
However there are artists who draws couple of lines on the canvas and yet be much more famous. To me this is what differentiates an artist from a painter. There are so many painters around who can reproduce a Picasso or Rembrandt exactly however this doesn’t make them an artist.
I think now it should be clear to everyone where I’m coming from.
Any IT architect could take any patterns and apply them to the solution without thinking how and why it fits to the specific problem, which doesn’t make them an IT architect. If we take it one step further, building a very complex architecture and writing hundreds of pages of documentation explaining it also doesn’t make one a true architect. However it gives a good reason and justifies the paychecks given by the customer who sees the labor put into the solution.
I’m a great fan of minimalist architecture which is sort of an extension to the agile paradigm for the software development.
Why would a business owner in any customer want a complex solution which takes years to build and hard and expensive to operate? So there should be a good justification for complexity, otherwise it would have been done for the sake of giving something “with meat” to the customer and get a good payment.
Think of this scenario, as an architect you’ve been hired to build a solution and you go ahead and do technology validations and prototypes and find a specific solution to the customers problem which decreases the development time of the project from 2 years to 1 month. However you’ve spent 2 months for the idea and the only deliverable you give to this customer is a presentation explaining solution and a simple solution with a few lines of code.
What is the value to the customer? Enormous reduction in the time to market, simple application with reduced operational costs, productivity boosts in the development team. Who wouldn’t want this? I call this a minimalist architecture and to do this you have to be smart and innovative. You always have to ask yourself why does the customer this complex piece, what has the support team done to you to deserve this continuous torture.
Unfortunately as the architects, we don’t want. We are afraid that it will devalue our work. Show off with the simples projects you’ve done, brag about how simple the architecture you’ve put together for project X is how did it simplify the lives of the customer’s IT team. How did it solve specific business problem and how did it enable organization Y to gain market share against the competition.
In the following weeks I’ll try to give solid samples on how complex an architecture could be and how can it be refactored to a minimalist architecture. I’m still putting together the framework however what I have in mind is sort of a unit testing framework, we may call it ArchUnit, for ensuring that the proposed architecture delivers the requires functional and non-functional requirements and incrementally simplifying points of complexities to come up with a minimalist architecture.
I do keep in mind that certain things could not be simplified. If you’re sending a space shuttle to the moon, it can’t be simple, but still it can be “minimalized”. As a good example I want to finish with the famous US space pen project that cost millions of USD vs Russian’s using a simple pencil at the space. The original “business” requirement was the ability to take notes at the space however the techies turned it into “We have to use a pen” and and the problem became “how can we build a complex space pen which has pressurized air in it so that it can write in gravityless conditions”. A mouthful hah, go for the real need and try to solve it instead of building a solution architecture based on well known patterns and try to make it work your specific case.
Did you see the antipattern here? Deciding on an architectural pattern up front, then look for the requirements and tweaking the pre-selected architecture to fit the needs. It would be easier to listen to the requirements and select the architecture. In our case the selected architecture is “use a pen” and then work on the requirements of using it in space.
I’ve written this article before reading Roger Sessions book “Simple Architectures for Complex Enterprises”. This book is fantastic in putting a framework around complexity and how to avoid it. Please read the book for a more scientific approach from a guru in the field. I’m really enjoying every single sentence in the book.
I will continue providing examples from my experience in the field as how we can think out of the box and provide minimalist architectures to simple need.
Stay tuned.
