I think I should have been an architect.

I even thought about it at one stage. Architects got to draw cool diagrams. Research cool and interesting technology.

They got to look at ‘design’ problems. And then try to solve them.

Problem solving. It’s everywhere.

But I like building stuff.

That’s not say that Architects don’t build. I’ve known a few to build quite a lot of stuff. But it’s usually superfluos to their actual job role. That is, it’s not required and isn’t the metric of their delivery.

But like how I build models to help understand and solve problems, so too do Architects.

What’s so cool about diagrams?

architect diagrams I like mapping where everything is.

What better way to show what’s happening in a system than an architectural diagram? It shows how things are connected. What’s sitting where and how they’re connected. You can see what’s in the ‘landscape’ so to speak.

Really its a map. A big overview map of the terrain. What lies in what corner. What it should (or shouldn’t) be doing.

I like knowing what’s happening in every corner of the system. I like how things flow. Figuring out if we’re flowing the right way. The best way.

But what’s the definition of best?

Least is best

minimalism I used to frequent a site called code.box.sk back in my “script kiddie” days.

The part of the site I’d check in with all the time was the coding competition (I know, another discipline altogether). The competitions would be to see if you could complete some task, but with the least lines of code.

And the codes that came in blew my mind. There was one I remember which was to print the entire ASCII table out in the fewest lines, and the winner managed it using only 9 characters. 9. characters.

Now why do I find this memory relevant? Because I believe that part of the role of being an Architect* is to design things in a way that achieves our objective. And using the least amount of resources consumed and/or wasted in the process.

And not just as a cost-savings exercise (although the company’s bottom line definitely benefits from it).

Building good design

good design There’s a certain satisfaction that comes when you’re building “good” design.

And I know ‘good’ is subjective. But in my experience when a design comes along that

  • understands the platforms its working with (e.g. weblogic, aws, vmware etc)
  • in the current state that it’s working with (e.g. out of support, legacy, licence issues)
  • has considered the stakeholders of the system its designing for (e.g. the internal staff users, the ops teams, the customer)
  • does it’s best to use best practice

It is actually a pleasure to build/implement. Why?

Well, for a couple of reasons.

Good feels good

good feels First, I guess you could compare it to when you get a good recipe from someone (side note: I’m winging this recipe analogy because this has never been my experience, I’m taking a stab in the dark that it’s like this).

You’ve tasted the goods, you know what the possibilities are that lay before you. And you have the blueprint to the goodness. The recipe.

I feel the same way about building a good design. You know something great is going to be accomplished by the end of it. And I enjoy building good things and then playing with them afterwards and marvelling at how great technology is and how doing it “right” makes me happy (I know, proper geek).

Do it for the team…

team work But secondly, and possibly more importantly-

When someone (in this case the Architect) has taken that much care to deliver a design that does good things, I feel responsible in my role to build and support these good things and make sure it see’s it all the way through to production and to the users who will benefit from it.

I think of myself as a team player. And when those in your team pass you good things to help the rest of the team (internal staff, ops, clients), I want to play my part and not let a team who shows they care about their work, down.

Anyway, I was musing today over some great AWS infrastructure design and how much I love diagrams.

Over in my documentation section I’ll get a bit more technical.

For this blog, I like musing over the more intangible aspects of my I.T. career experience.

Thanks for reading!

*Disclaimer: I will comment a lot on what I think a role should do, be, or fulfill. I’m no authority on job descriptions or definitions, I just say what I think that role should accomplish purely from my point of view and experience in IT.

Leave a Comment