Who is this Architect person and why do I need them?

The term Architect within the scope of IT has many definitions:

Data Architect - Responsible for design and management of the data that supports the organizations applications including database technologies, storage technologies, and Business Intelligence tools.

Software Architect - Responsible for the design and management of the software applications that support the organizations business processes.

Infrastructure Architect - Responsible for the infrastructure ( network, equipment, desktop applications, etc) that supports the organization.

Security Specialist - Responsible for security of systems with in an IT ecosystem. I have not yet heard them referred to as Security Architects but they are filling that role.

Solutions Architect - Responsible for the technology and implementation of a solution. This role requires the most experience and breadth of knowledge. This person must assimilate the information from all four disciplines (applications, data, security and infrastructure) and ensure that the best combination is being used for a complete solution.

In addition to Architect roles in these disciplines there are also people referred to as Cisco Architects, Oracle Architects, Microsoft Architects, etc. I don't want to downplay the knowledge these individuals have but I don't feel you are an Architect if you only know or work with one vendor or product. We'll get to that a little bit more later.

The responsibility of the Architect role is to utilize technological solutions to fulfill business functionality needs. The Architect needs to have both the high level vision of the solution and at the same time be involved with smallest technical detail.

This individual interacts with the end users and stake holders to understand the business processes that are being implemented. They assist the business in making solution decisions utilizing their knowledge of existing technology and also new or related technologies that are available. An architecture role is one of constant learning. In order to provide value in making short and long term technology decisions they need to be current on what is available in the marketplace in addition to what is already implemented within the current environment.

An Architectural role is not a managerial role and does not have direct reports unless your organization is large enough that you have multiple architects. (Generally organizations are lucky if they have one let alone multiple). One of the key skills of an Architect is that they are a facilitator and not a dictator. They must have the people skills that allow them to design and implement the architecture based on a collaborative effort with other implementers on a team and in the organization.

The "Ivory Tower" syndrome is something that will make the Architect role totally ineffective. They cannot just go into their tower and draw up a design on stone tablets and present them to the implementation team as the ONLY solution. There are always multiple ways to design an implementation that are all technologically sound, an architect must be willing to for go his personal preferences if the design recommended by the team doesn't have any technological issues. Conversely he must stand his ground if the development team wants to do it a certain way out of convenience but in a way that has technological short comings. Sometimes it takes some coaxing to get people to try something different but if it is a sound design a good technology person will at some point during the implementation will see the value in doing it one way over another and they will buy in.

Also an Architect should take on part of the implementation duties. They should write code, configure environments, work on deployment scripts on different projects at different times. Be wary of the architect that doesn't actually do the work on occasion. There are many "academic" architects out there that I feel are not as effective because they have not used the tools and debugged an issue or worked through a technology problem. When there is problem that is when you learn and improve your skills. If you are doing everything in a document there aren't ever any problems with that.

Effective Architects come from a background of broad experience. As I referred to earlier, I don't feel that someone that is specialist in one particular product is a good general architect. An Oracle Architect would not make a good Data Architect because their solution would always be something Oracle which may work but may not be the best fit. (Its the old adage "if your only tool is a hammer everything looks like a nail") The vendors love the Oracle Architect but the best overall solution for the organization may not be implemented.

Vendor marketing material and sales folks can always make their products sound like they can solve your organizations implementation issues, that's their job and most do it well. It's an architects role to sift through that and find what's real and determine if its the right fit for the organizations solution.

The key aspects that an architect brings to your project or organization is that end to end vision from a technology perspective, facilitating collaboration between the different IT disciplines (data, infrastructure, security, development), and facilitating implementation processes.