Did you ever want to become an IT Architect, and have been wondering what it is that Architects actually do? I have been trying to highlight what’s important from my point of view. I have tried to highlight those areas that are – in my opinion – important but definitely not key concerns for architects…
Even though I have been working as IT Architect for many years, it took me some time to realize what the role of the IT Architect is really about. I will try to describe here what I have rationalized for myself. Possibly it’s not perfect. If it isn’t, let me know and post a comment. I hope, it provides some guidance on the subject.
The easy part – Mostly technical stuff
There is more than one explanation or definition out there, but I have to come to believe in one in particular. In my view, the IT Architect is the technical leader on a project. Imagine the Architect more as a Chief Engineer. According to this, the architect is responsible for:
- Understanding the non-functional requirements
- Making sure the non-functional requirements are addressed by the technical design of the solution.
- Directing the design
- Communication in the widest sense: communicating the technical aspects to the stakeholders, project management, software developers, testers, etc.
- Keeping an eye on the critical aspects of the solution, seeing to it that the key aspects are designed and implemented thoroughly
- Providing technical leadership
- Making sure the technological and design decisions taken, are in balance with the risks inherently taken. In addition, the architect needs to make sure mitigations for those risks are in place.
- Drive the methodological and qualitative aspects of the development process
Let’s face it. Most of us Architects have their origins in the technical arena, such Software Development, Systems Administration, and other more technical areas of work.
Often, the real challenge for a technical person is, to develop the soft skills required for the job: such as developing leadership and communication skills.
Do not let others confuse you – There is no truth about how much Code an Architect needs to write…
This morning, I walked up to one of the software developers on the team, with an idea on how to track down this elusive performance bottleneck we have been trying to find for a few weeks. He listened, and said with kind of a joking, sarcastic tone (we have known each other for many years so no harm was done): “Oh right. You have actually been technical at some point…”.
Leaving the jokes aside. Do not let others confuse you by whether Architects should write code or not, should be theoretical nor not, should be this or that. It is really not that important. This aspect of your line of work really depends on many other things, such as:
- Type or project (technical or nature, process-savvy, consulting, etc.),
- Size of project (you will be more technical on small projects and merely a communicator on large projects),
- Personal aspirations (what you want to be five years down the road),
- And many more…
Generally, it will be more technical and hands-on if you are working on a smaller team of 5, 7 or 10 people. And it will have more the characteristics of a management and communications function, when leading large teams of 70, 100 or more individuals.
The true objective – in my eyes – is leadership
But what really doesn’t change, is that you need to bring technical leadership to a project, no matter what kind of project it is. This means:
- Bring technical realism into a project.
- Make sure the project doesn’t get lost along the way on one of the winding paths, and stays on the most direct and pragmatic route to the project’s objective
- Actively manage the non-functional aspects of the project
- Communicate, communicate, communicate … about everything necessary, to everyone necessary…
[Lan2009] Langer, D. 2009, “Architecture as Leadership”, An Architect Makes It To The Big Show [online] available at http://blogs.msdn.com/b/dave_langer/archive/2009/04/30/architecture-as-leadership.aspx
Copyright © 2011 Michael Pichler