What is an IT Architect? I’m convinced that the IT industry doesn’t know. I see lead developers called Architects. I see clever designers, pitch men and project managers all called Architects. It has become a term of rank like Vice President and lost its essential meaning. This has had a negative impact on the IT industry and cost all of us billions of dollars.
An Architect is the technical leader for a project. Just like an Architect working on buildings or a Chief Engineer for a bridge project, the responsibilities are the same. It is the Architect who works with the client to understand their needs and desires, then he creates a plan to meet these needs and desires. The process doesn’t stop there. The Architect supervises a team of people, as they build the solution. The responsibility is end to end, beginning with requirements and ending with testing. Every aspect is his responsibility.
There are those who will argue that this is not the proper definition for the term Architect. I will only say that anything short of this definition opens the project to risk. For example, if the development process the team uses to build the solution is unsound the project may never be completed. If the original vision is changed during the process or its important details are lost, the project may be completed but it won’t deliver on the promise made to the client. There are so many ways a project can go wrong. Only the architect can sort out the finger pointing and correct the course of the project to ensure successful completion.
70% of all IT projects are delivered late, over budget, or with reduced features. A full third of IT projects are never finished at all. In any other field of human endeavor this would be considered absolutely unacceptable. Could you imagine paying for a new house and at the end of the project the builder told you that “the house was a failure, you get nothing” This happens 30% of the time in IT, and yet the line of business continues to fund new projects.
I believe the lack of a true IT Architects is the principle cause of this failure rate. All too often the IT organization or the line of business decides to treat an IT project as factory work. They hire a project manager and round up a group of technical people. The process is simple we shall make a list of deliverable and assign these deliverables to a person or a group of people. The flow of knowledge from the client to the business analysts to the designers to the coders and to the testing team will happen without technical oversight.
This is a mechanical process. Everyone doesn’t their best to create a good work product with the information they have, but no one is concerned if their work product is faithful to the client needs, or even if it answers the need to the group who consumes it. In this process everyone is focused on the deadlines and being able to mark their work product complete. After all this is what the project manager is focused on and he is the only person supervising this project.
Granted the Agile development process helps to keep the development effort connected to the business goals by involving the stakeholders in the process, but it is not a cure all. Agile has its own weaknesses. The tendency for the process to iterate endlessly as the features are added for each iteration can not be ignored. There is also a risk that important features of the architecture will be left until the end, because this deep technical issues are rarely the focus of the line of business. Again experienced technical leadership by an Architect can ensure success, or at least increase the odds.
It should be noted that good Architects are often politically unpopular. A good Architect takes responsibility for delivery of the finished product, so he/she is often the one who says early on, “it can’t be done”, or “we’ll need more people to meet that deadline”. These messages are critically important to the line of business because they directly address real risks to the line of business. These are unpopular messages, a kin to saying “the emperor has no clothes”, but someone really has to say it. Perhaps, a contractor should be used in the Architect role to address this issue.