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:
- Doing a lot of file copies with some complicated patterns (e.g. those 2 files goes in here, those other 3 goes in there, but you must rename them with a timestamp, etc.) . A typical example is manual deployment.
- Every time you want to support a new customer, you need to create an XSLT to transform a neutral XML into a branded HTML. XSLT is complicated. Evil complicated. It should only be used to power rocket ships, not as a standard part of a business process.
- You have a B2B solution relying on some duct taped integration where a file is dropped into an FTP site, caught by a BizTalk Server, some messages are sent to MSMQ, un-queued by a Windows Service with funky credential settings and pushed to an internal web service. That was super cool on paper, except that in operation, that sucks because the FTP site goes down, the MSMQ gets poisoned, the Windows Services is unable to start once in a while, your Web Service is flaky and there is this SQL job running once in a while that causes delay that breaks other parts. So… you have a poor dude somewhere who needs to understand all this technological task and probe around to find the problem of the day when customers or accounting start screaming at him.
- The solution has a superbly layered design. I mean it has a lot of layers! Each layer has a small responsibility. So there are 8 layers forwarding each other some piece of information in different form. The problem is that every time you want to add some capability to that solution, you need to create 8 interfaces, 8 implementation classes, 7 custom constructors, override 6 methods, etc. . Same thing when you want to change a bit your data representation. The girl doing that needs to understand the subtlety of each layer, class, factory, strategy, etc. so she can copy files around and rename classes / variables for 2 hours.
Recognised a pattern? Boring job requiring a degree to perform. But more specifically:
- Non-automated repetitive work (manual deployment)
- A complicated technology used to do what a simpler technology could do (XSLT vs HTML)
- Too many sub-systems interacting in a brittle way (duct taped integration)
- Abstraction and decoupling thrown at the end-consumer’s face instead of buried in the foundation of an application (e.g. too many layers, ceremony to create something)
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.