Wednesday, June 29, 2011

IT Architecture – some of the basics

Simplicity, Efficiency and Consistency

Early on in my career I was lucky to work with some very brilliant minds. I learned a lot from these people, both good and bad, but the two main things I always remembered from working with them were:
  1. Simplicity and efficiency of the production of design, development and method are the two things that must be strived for; and
  2. It doesn’t matter if you make mistakes, just be consistent. A consistently made mistake is easy to correct, inconsistent ones can become impossible.
What I have always taken from those pieces of wisdom is that IT architecture is not so much about the constant pursuit of perfection, but more to do with maintaining the balance between solving the problem the client has described in the best way, with the time, budget and capabilities of both their organisation and yours. Get too carried away with trying to create a solution that is plated in gold and you’ll most likely watch it die a death from a thousand cuts. Overcommit and you’ll be working 7 days a week, under-commit and you’ll more than likely deliver a piece of crap that will get an underwhelmed response and you’ll be shown the door when the next piece of work is up for tender. Keep simplicity, efficiency and consistency at the forefront of your mind and you’ll be closer than you think to deliver a robust, scalable and high-value solution that will make your clients happy and give you a stepping stone to hang your career hat on.

You don’t need to be a genius

It doesn’t take a powerful brain to be able to architect 90% of business software solutions, you just need to know what the client wants, what problem it is trying to solve, what methods and processes to deliver it you need to follow/implement to get it to work, how to make it all work effectively to stay on-time/budget and how to lead those within your teams to implement it correctly. You do need to know the technology, unless of course your role is very high-level and you’re just drawing boxes on a board, because you do need to know what works and how to assist/advise the people you work with.

You don’t need to feel like you must do everything yourself.

Don’t make the mistake of trying to do it all yourself. I have, several times, but late nights and missed time with family stopped becoming fun after having a couple of kids and I started to really need my weekends to get my mind into another space. Identify and know the skills and abilities of those in your team to ensure that they can be relied on, and driven, to get the job done. Always get yourself a good technical architect(s) to diagnose those difficult technical issues, assist with hardware and infrastructure planning, performance testing, platform configuration and the production of all important proof-of-concept applications to confirm technical and design directions. You also need competent technical team leads, people who can delegate work, lead development teams, ensure software is produced in-line with established standards and ensure as much automated QA tools are integrated into the build and development environments as possible. Remember that all good architects have to be good leaders; they have to drive teams, direct people and keep them on the right path. In other words you need good social and communication skills and yes, you do need to be across everything so being well-organised is a must.

If you’re micro-managing everything then you are either not delegating work properly or, communicating what and how things need to be done effectively. Worse of course could well be that you’re working with a team of idiots, it happens to us all at one point or another, and in such cases you need to be on top of the issues and raise/escalate them as they arrive.

You must manage the architectural risks and issues – to ignore them is fatal

As an architect one of the most important things I always look to do first on any project is to identify and mitigate against architectural risk because without doing this exercise your entire solution could be flawed from the outset and it’s likely that you’ll miss something critical which will only rear its head at a later date. Changing from 32 to 64 bit over the last few years has been one that has caught a lot out; a good one in future will be data migration to relational database engines in the cloud, when you’ll find that that your love for using certain system functions will no longer exist. Remember that as the architect you’re accountable for the solution so always err on the side of caution. Don’t commit to changes in technology platforms, business requirements etc… without doing impact assessments first, if you see a risk, raise it, puy it in a log that is visible to all relevant parties (Project Managers, your own managers, project stakeholders etc…) and ALWAYS suggest a resolution or course of action to mitigate against it. Don’t just raise issues without offering a way out, it always looks more credible when you’re the one taking the lead, after all that is your job. And finally always follow issues up.

So why have I bothered


I contemplated long and hard about doing this blog thing. But after a number of years in the job I forget things and I don’t want to be able to rely on just a collection of learned experiences to see out the next 10 to 20 years. Therefore what better place to put them than online, because out here it ain’t going anywhere – well at least not for a while, and if it helps others and doesn’t raise too many peoples bullshit flags well then that’s a plus as well. Also I like having my beliefs and ideas challenged.