Coder/Developer to Architect; Your experiences, realisations, Myths broken.

Question

A lot of us in IT begin as coders/developers and some as coder/developer/business developer depending on whether you work for someone else or your self. While there is the list of what ideally the Architect should be doing and should know, I've found from asking around that it is not always so. It probably depends on the location at which the project is executed. If it is offshored to say India, probably the Architect ends up doing more of project management than proposing an architecture. Again this is not a rule.

So, I'd like to ask a global audience here, who are currently practicing software/technical architects to share their experiences on how they got to being an Architect, what they thought an architect was supposed to do while they were working as coders, senior developers or any other role and if there was any change from that when they actually went on to be a software/technical architect. Those who have or are working closely with one also please let me know your thoughts. Also, what are the breadth and depth of technical skills such an architect should possess?

Thanks.

Answer 1

IMHO code architecture is just part of the skill set every professional developer should learn. In an Agile model the architecture is everyone's responsibility, and code ownership is devolved to the developers working on it.

Obviously some developers are much stronger architects than others, and their skills should be adequately used, but dedicated architects can be counter productive. Having them takes the code ownership away from the guys actually writing it.

In teams that I've managed architects' role have been to be part of the actual team, equal members in the scrum and as likely to be mentoring as drawing UML diagrams.

In the vast majority of cases the title Architect has been bestowed to provide a senior developer with at least the appearance of progression. Essentially a good one is really just a really senior developer with a wealth of experience and code understanding.

The worst architects are those that are precious about their designs, even if those designs are really good they end up devaluing everyone else's input.

Answer 2

The definition of an Architect differs from company to company I'd guess. The type of work and requirements (in terms of skillset and deliverables) of an Architect also depends on the maturity of the company. There are a lot of variables here - are we talking about a Software Architect or Enterprise Architect? Is ICT the core focus of the company?

What it's like

If the company you're working for does not see technology as its core product or service, and is large (multinational, listed, tons of employees, more than 4 business units) then an architect essentially does the following:

• Because your ICT functions are outsourced, you're not going to be developing software, you may not even be allowed to touch dev, qa or production boxes (Unless you're certified and there's no expertise available). You will validate business requirements, outline principles that the ICT provider will have to follow and do the relevant paperwork. Lots of paperwork. Tons of paperwork.

• You will be very concerned with business processes, mapping them, optimising them and eventually (if needed) automating them.

• You will be dealing (alot) with compliance issues.

• Because the infrastructure is fairly defined, unless its niche applications you will probably be restricted to implementing solutions based on a big brand like MS, Oracle or SAP. You will be told things like "not approved because it can be done in SAP" or "we shall leverage our 'strategic partnership' with SAP for this solution"

• Enterprise Application Integration and SOA concepts will be the area that is least developed, and will allow you to really exercise some creativity. You can do some really good work here.

What you need to know.

• Know Everything- Having a good understanding of a variety of technologies is key - you will be reviewing network topologies, application proposals, DRP plans, etc. You can't know enough - developers will be biased to their technology and experience, business won't know any better you need to be able to balance all of that

• Communication - You will be working with developers and third-party contractors for custom developed and off-the-shelf packages. You also need to communicate to business effectively.This basically means get some awesome photoshopped (or Office 2007ed) presentations for business and stun them and write explicit documentation for your contractors and hammer them.

• Best practices and guiding principles - hopefully there'll be a community within your organisation where you can learn and contribute to the development of best practices.

• People skills - the idiot factor ( and I include myself in this as well :) ) is high. You need to be able to manage expectations, work in teams, stand your ground and essentially be everything that you didn't learn in varsity :)

• Consultants - Too often I see people who depend on vendors and consultants to define their architectures for the organisation. Consultants are there as a resource, not the other way around.

• Grind - be prepared to read, review and write documentation from specifications to governance documents to requirements statements. Paperwork is the only thing that will keep you sane in projects dominated by engineers (who usually hate 'IT' guys :D ).

Smaller or more technology focused companies are less formal and constraining in my opinion. I think I expected too much for my experience and expertise - that I wouldn't be handling operational issues and be working in an advisory role. The heirarchies, paperwork, lack of creative freedom and restricted access to actually working with technology disappointed me. But I also realised that my experience was insufficient - being in this type of role requires more than just a degree and being able to read and understand - I needed real operational experience. Don't become an architect too quickly. Rather move around and learn as much as you can and build up the confidence by getting onto a variety of business and IT projects. Having a solid foundation,confidence and technology/vendor agnostic expertise and understanding of concepts in the landscape is important.

Answer 3

The kernel of the answer is - the Architect is keeper of the vision.

This is also a very useful analogy to use for business people asking why do we need an architect? Like buildings, you can build at a certain scale using standard templates and following examples, although someone will probably still be playing minor architectural role.

So, to live up to that role, what do you need to know about the business, its domain, the technology and the implementation?

You need to work out these answers and they will vary hugely according to team and product size, degree to which the product is established and the personalities within the company. I just like that simple focal point as a reminder for why you need to answer certain questions.

To answer the specifics of your question:

I've not formally been named as an architect much in my career but I've been named as such by the people working with me. I hadn't thought much about what an architect would do before that, or even about their existence (maybe this being over fifteen years ago made a difference). Back then, an Analyst was the person you went to for decisions about architecture. Even so, I had a conception of someone you could go to for big-picture answers, who could decide based on the implications of how your work affected other systems.

Interestingly, my new employer (Gemcom) has a very clearly-defined career path and the two top levels on a technical track are well-justified Architect roles. I don't think I can copy and paste their list of aspects but one important one is the degree of understanding of the products and all the libraries and technologies used within.

So, no, I don't think there's been any change in what I thought the role would be or what it would require.