The duties of an IT Architect

In defining what an IT architects duties there are a number of considerations.

• Resource availability. An IT Architect could be (I believe should be) a senior experienced IT professional who could develop code, set-up infrastructure, analyse business requirements, project manage, train users and man a help desk. All these are full jobs in their own right. In a small company you might have an IT department of one person and he would rightly argue that his duties included all those on my list plus some � and that he was also the IT Architect. But one man is not going to deliver significant IT capability. As soon as you needs grow then your IT team must grow and people specialise. So in defining what an IT Architects duties are you must also exclude duties otherwise you just gave a person who does everything which is unlikely to be optimal.
• The analysis done in the "Metaphors" section exploring the role of IT Architecture different to physical-world architecture. In short that IT Architecture is about producing an IT which will be useful for a long time meeting the client's current requirements and changes to those requirements and technology changes.
• The way IT skills are generally organised (software development, project management, infrastructure, data etc.). Using the role metaphor of IT Architects being similar to physical-world architects; IT Architects have a responsibility of bringing these areas together to provide solutions.

I believe that responsibilities of IT Architects can be defined as:

1. Producing an overall framework design that shows how different IT components (physical, software etc.) and skills are used to provide end-to-end solutions.
   • The framework should facilitate future change of requirements and technology. I.e. the cost to deal with this change should be minimised or contained.
   • The framework should include details of the business aims and model being supported (and how) so that the impact of business change can be managed.
   • The framework should include details about technology assumptions being made so that technology developments (which change these assumptions) can be managed.
   • The framework should include details about the way systems are used deployed and supported.
   • The architect should enforce and therefore take personal responsibility as to the frameworks adequacy.
2. Defining design details where required especially between boundaries (e.g. interface definitions, project (i.e. within a programme) scope descriptions, software component / host mappings etc) to enable implementation to scale.
3. To provide end-to-end solutions (within the context of the framework) to meet specific client requests. This should include technical details about development, infrastructure and the use of COTS products.
4. To produce (or have produced) adequate documentation of what was implemented to enable ongoing maintenance.
5. Not to get bogged down in implementation details that could be [better] done by point resources. Again this is to enable implementation to scale.

Implicit in this are the required responsibilities of any senior members of a team, including accountability, communication and persuasion.