The Arc-E-Tect's Predictions for 2017 - Application Architectures and Application Models [3/10]

The Arc-E-Tect's Prediction on Application Architecture

It's 2017, meaning 2016 is a done deal, and most of my predictions for 2016 I made about a year ago and never got around documenting in any form have proven to be absolutely bogus. Which leads me to come up with my predictions for 2017 and properly document them. So continue your effort reading this post and hopefully you'll enjoy reading them. Unfortunately we'll have to wait for about a year to find out to what extent I got it all right, but for now, ...Application Architectures

Why Application Architecture? Because that's what matters. In a world where agility, quality and security matter more and more. Where business and IT are moving ever closer together and performance is measured in value instead of function points. Architecture is what saves the day, so don't even think about ditching your architect.

Application Architecture in, Application Model out

Yes, in 2016 I've been confronted with application models. Again and again I have been slapped with models of applications and yes, I've been on the other end of the slapin' stick as well. Shoving application models into other people's faces. Stuffing it down their throats, making them, no forcing them to understand.

There're some good models out there, they're the ones that we call 'Reference Architectures'. They're good because they suck slightly less than the other models.

Models suck

What's so bad about models? Well, that's just it, they're models. We think of models because they simplify our lives. Models are an abstraction of reality, such that only those aspects of the real world that matter within a specific context, are left. That's the sole reason why we have models, because we find reality too complex to work with to solve particular problems.

Mind, models are never showing the whole picture, so they can never be used to solve the whole problem. There's always something else left to look at. Unless you are very consciously thinking about models in this way, you're in for a real treat when working with models while solving problems.

Case in point; just think about all the contradicting models that we find in all kinds of science.

Models are great for thinking. Don't get me wrong, in communicating complex concepts, it helps to discuss models because it reduces the chance for discussions on irrelevant details that are on familiar ground. Just like using analogies to explain a controversial concept. I love to use the story about preparing an egg for breakfast to explain the importance of understanding (business) processes.

Architectures rule

Architectures are representations of something to come, but unlike models, architectures have relevance because they are explainable. You can discuss a model, but not why it's a good or wrong model. When the model turns out to be wrong, you just choose another model. You can debate which model to use, but that's it.

Architectures can be explained because with architectures come principles. Principles are common truths, are more or less decisions taken by one or more persons that understand the problem at hand and are working on the solution. In addition, and that's really important, there's for each principle a rationalisation of the principle and a concrete impact on applying the principle.

Solving your problem by devising a structure, while putting the flesh on that structural skeleton using the described impact of all applicable principles gives you the architecture.

So architecture are different from models because they can be discussed objectively. One can discuss the rationale between the principles underpinning the architecture, and analyse the impacts of these principles. In addition, an architecture never leaves out any form of complexity in order to address a problem and therefore leave out the ugly pieces of the picture. Instead, architectures show the complete picture.

Why architecture in and models out

It should be clear. We need to be faster in solving problems, delivering higher quality while doing so, and include security (in all of its forms) as an integral part of the solution, while staying adequate. Not doing too much or too little, but just right. This requires that in 2017 we always need to look at the full picture, address all aspects and cover all our bases.

Models by their very nature don't do any of this, and architectures explicitly do.

The reference architecture trap

Don't fall for the reference architecture, the model pretending to be an architecture. Reference architectures are models of how we want solutions to look like. They're not architectures, because they don't represent a solution to a real problem based on rationale with known impact.

So Forrester's 4-tier architecture, which is actually a model, is out in 2017. So is the multi-architecture, the client/server architecture and the Service Oriented Architecture.

These are all models, so don't waste too much time on them. Be aware of them, understand them, put them in your toolbox when you're an architect. But whenever you work on a solution to a business problem. When you're asked to generate value, stay as far away from models and work on architectures. Don't do the big scary architecture, but the lean to-the-point-and-no-more architecture. Take note of the product backlog to understand the direction in which the Project Owner is heading to stay facilitating, but try not to disclose more than 3 sprints worth of architecture to the Product Team. 

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link to my blog to all your Whatsapp friends and everybody in your contactlist.But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect