Architect

A friend of mine asked me to provide some advice to an IT architect that had just got into the 'business'.  I wrote an email to the guy and my friend suggested it was quite good and I should publish it.  So here it is.

I am not sure I can talk much about what it is to be an architect as I have never really architected anything at any point in my career.  I have spent most of my career being a bridge between business and technology.   The ability to be able to interpret from both sides to the other is key.   Get that skill down and you will be successful.  Many projects fail because business and technology are like oil and water.

I have had a number of good architects work for me over the years and I give them the same advice each time.  Get out!  Architecture is largely technology dependant and changes year after year.  So your knowledge of any given architecture and approaches (TOGAF etc) can only be as long as the longevity of the architecture or approach itself.  This means that architects have a difficult career.  They have to learn and relearn all the time.  The trouble is that new architects leave university every day and they know their stuff and the latest tech well, are twice as energetic and work for half the money.

So there are very few old architects out there and I could probably pick only a handful who have gone on to be head of their profession in a company.  You are speaking to two (Wayne and Jerry) and I could pick two or three more in IBM and Cap Gem etc.  But they are few and far between.

So what to do?

1) Learn how to best use technology to solve business problems.  Less worry about what the tech is (in detail).  Leave that to suppliers.

2) Know enough to spot bul***t from suppliers.  Knowing enough to spot problems early.

3) Leadership.  Business needs to be led.  Understand the difference between management and leadership and you will do well.

4) Structure.  The key word for me was 'enough'.  Each situation and client is different.  Taking methodologies and blindly applying them causes huge issues.  The ability to gauge a client and understand the level of structure and formality needed is vital.  To much (applying TOGAF to an SME) or to little (free for all in a corporation) will mean failure.

5) Understand business cases and TCO.  So few architects do.  It leads to massive overspend and wastage.  There is always a tendency to try and save money only to find that you end up adding to cost as old stuff is never switched off. SOA can be one of those traps.  Integration layers another.

6) Cost of change.  As per 5.  Everyone underestimates the cost of change. Its not the costs of the licenses that gets you, its the overheads of change such as test etc.  It is never calculated well and drives huge cost into the org.

7) Test costs.  Look at initial test costs and then the incremental ones.   Regression testing is a huge burden and costs a lot.  The more features one adds to systems after initial build means that regression burden just grows and grows.  Get whole life testing costs sorted (automation).

IT outsourcing is hard.  You cannot expect to just throw the IT needs over the wall to a supplier and expect it to work.  Most of the challenges come from poor contracts.  A useful skill is to learn contracts.  So many times they are left to people who have no clue about what they are buying.  

Learn to read them and ensure that the supplier delivers what they are contractually required to do.  So often the answers are in the contract to solve the issues.  

Suppliers are £ led.  Only £ led and any other motivation is just sales nonsense.  They are there to deliver but not at the expense of the profit. So you need to work with them to ensure that they make their £ and deliver. That’s the hard one as they regularly under bid and try to cut back on quality to meet the £ and the delivery.

Thats about it.  If you can do that intuitively then you will go far.