Solution Skill Quadrants–Part II, Solution Architecture

In the last blog post I introduced my own patented Solution Skill model:


I won’t repeat the content of the last blog post, that’s what hyperlinks are for.  The goal of this post is to address this simple question:  as a Solution Architect, how can you help the situation?

Well, your main goal should be to avoid creating solutions generating a lot of fourth-quadrant jobs.  What are those jobs anyway?  I use to work at a place filled with those jobs.  Fortunately, mine was closer to the third quadrant, but most people I managed or interacted with were in the fourth quadrant spewing against their faith.  This is where I created that model in my head!

Basically, a fourth quadrant job is something super complicated and super boring to do.  Examples:

Recognised a pattern?  Boring job requiring a degree to perform.  But more specifically:

Basically, complexity surfaced at the wrong level.

Your job as a Solution Architect, in order to address maintainability, is to ensure that what doesn’t need to be complex isn’t, even if it means not using 3 new techs and 5 patterns at the same time.  It also is to ensure that what needs to be complex, because it express something complex in the business logic / process, is positioned at the right level in your architecture, mostly, buried somewhere you do not need to touch everyday, so you can send your 3rd quadrant ninja dude look it up every blue moon.

There isn’t any recipe, but what helps me is to think about how the solution is going to be maintained.  Nowadays, we more often than not replace an existing system, so it’s easy to ask around in order to know what type of change requests the old system got and what type of staff handled those tasks.  Imagine them and figure out how many technologies they have to be comfortable with in order to do perform those tasks and optimize.

Leave a comment