The role of an architect is not always that clear-cut and can differ per organization. For that reason I will describe the architect role as I try to fulfill it. Of course, there are different types of architects. Think of enterprise architects, solution architects or project architects. As a consultant I’m typically involved in projects, so I’m focusing on the role of the project architect.
Ever been to a classical play? There’s an intriguing analogy between the director of an orchestra and the architect of a software project. It may sound a bit philosophic, but think about it. Why does the same orchestra sound differently when directed by a different person? A musician will be able to play all notes, just like a developer will know all of the syntax to code a solution. What the director brings, is not skills, but rather guidance, inspiration, communication and cooperation. On the other hand, try holding back. Don’t disturb processes that go well by themselves. Each director will bring his own experience, knowlegde and preferences, but there’s a thin line between the objective and the subjective. There’s no right or wrong. There’s no single truth. Musicians expect charisma, calmth, confidence and perhaps a bit of magic.
Now, let’s go back to the architect role. As a consultant you are either hired by a big company or a small company. Big companies most likely do have an architectural body already. Small companies might not even aspire an architecture. That means you will either have to align with an existing architecture or create a new yet minimalist and clearly focussed architecture. Always be aware of the commercial context you’re operating in. You’re not just an IT guy promoting the latest and greatest. You need to balance added value with costs, risks, performance, avalilability, etcetera. And then again, you must also show vision and be able to promote change. With a sound IT landscape you need to prepare the client for a future business context that might not be clear yet or subject to change.
The above observation directly leads us to the notion of agile architecture. Working agile is very different from a waterfall apprach. The architect will play different roles in different project activities. Think of analysis, design, implementation, test and release. You could state there’s a tension between traditional software architecture and working agile. You need to balance anticipation and adaptation. Spending too little time on upfront architecture will increase risk. Spending too much time will most likely decrease customer value. You simply can’t anticipate everything upfront, you need to work agile and adapt to changing conditions.
Also, it’s good to be aware of your position in the organization. Always ask yourself how you relate to general management, project management, enterprise architect(s), solution architect(s), business analysts, subject matter experts and designers. Sometimes you’re more of a project manager, sometimes you’re more of a designer. You must be able to move along the spectrum and not restrict yourself to the formal architect role if your true added value lies elsewhere. Remember that the client might ask for a project architect, but look for a designer, a solution architect or a scrum team member that can fill the backlog and participate in sprint planning.
Finally, be aware of the fact that IT is evermore becoming a specialist role, that’s not in the core business of the enterprise. There’s a knowledge gap between the IT side and the business side. This gap obviously needs to be bridged. Clear communication is key, but don’t oversimplify. Take up an advisory role and try to become a trusted IT advisor.