Big picture vs. little picture

- [Instructor] One are the challenges you, as a new architect, have starting out is realizing that the scope of your responsibilities have changed. You no longer have the freedom to focus on a single aspect of an application. Focus, an essential skill for a developer, is often inappropriate, not to mention impossible to achieve as an architect. In an orchestra, when you're playing an instrument, such as say the violin, you must understand deeply how to play the violin. You must understand the music that you are expected to play on the violin. You must understand how to interpret instructions from the conductor to know when to play the different parts of the music that you have before you. As the conductor, you understand what it takes to play the violin, along with the other instruments in the orchestra. You may have even played the violin before, but you may have played other instruments instead, or in addition. You need to know how all of the instruments work together to play the composition. You do not need to know the specifics involved in playing the violin's part of the music, but you need to know how the violin's part fits into the whole. You need to lead everyone else in the orchestra, give them the instructions that they all need in order to play together, synchronized, and make beautiful music. The conductor, you are the architect. The individual instrument players are the developers. As an architect, you must keep many distinct components and concepts in your mind at all times and have a rudimentary knowledge of how they all work simultaneously. The big picture, the overall application, not just a single component or module, is the focus of the software architect. Developers must understand one component or at most a few components to a deep level of understanding. As an architect, you need to understand many, many distinct components, but you only need to understand them at a higher level. As an architect, when one development team determines they want to make a change to a component that they own it is your responsibility to understand the impact of that change beyond the scope of that single component. What other components will be affected by the change? Will a performance change occur? And how will that impact the overall performance of the entire application? Will it cause another component to behave differently? Perhaps in a manner not previously tested. Could that performance change expose a previously unknown bug somewhere in the system? Will the change have an impact on multiple levels of the application in different ways? These are all questions that you need to ask yourself in a role as an architect. You have to understand enough of all of the components of the system to determine if the desired change will have the changes to other parts of the system. Will the team that owns those other components have problems implementing these needed changes? Will they have the necessary time to make the changes? Will they understand why those changes are essential and support making those changes? As you move from developer to architect you will find your scope of responsibility expands from a single component to the interconnection of a large number of components. As such the word focus, as we started with earlier in this lesson, takes on a whole new meaning. No longer do you focus on the in-depth technical aspects of a single module. Instead you focus on the wide ranging interaction between multiple disparate systems. It is still a type of focusing, but it is a broader coverage of things you are responsible for, but at a higher level of understanding. As you move from developer to architect you're expected to operate in this different level of abstraction and to think about the problems in a different way. Management and other developers will be looking to you for this external knowledge and systemic understanding.