Normally architects are at the top of the technology decisions along with principles. The focus of architecture is generally two fold: 1) Satisfying decisions

Normally architects are at the top of the technology decisions along with principles. The focus of architecture is generally two fold: 1) Satisfying decisions that please many opposing masters. 2) Deciding how the company will build software from its current talent and the expected talent in the marketplace. Consider the architects as the practical application and technical planners that represent the technical things a CTO might bundle together from a senior managerial perspective. —- Things an architects will need to do: 1. Make decisions. Know your various competing stakeholders and master written documentation. Be good with influence and always have supporting evidence. Never propose ad hoc decisions or use data that is either invented by you or poorly estimated. This is the essence of your reputation. Push back on decisions that are poorly qualified. 2. Place the product first. This means the most principal interest is a balance of generating revenue and pleasing the customer. Everything else be damned. That also means telling people no and putting developer interests as a far lower priority. From a business perspective people understand the answer “no” when there are competing priorities and when their pet priority isn’t fully qualified. 3. Account for talent. Temper that previous point against talent availability. For example if there is some giant JavaScript framework out there that there is giant slow, both in development time and execution time, trash and yet the only JavaScript you can find require that framework this must be factor in your proposals and technical planning. 4. Plan. Your ideas and proposals must be feasible. Are they things that can actually be built in a given timeframe, with the given talent, and the given resources? How long will it take to build? What are the risks? Will more assets be required? Will more time be required? In what stages and order will it be put together? Your plan should be communicated in two ways: a high level summary for stakeholders and a supporting specification that provides technical details and evidence. —- Things to learn: 1. Leadership. Stand behind your decisions. Own them with confidence and yet be willing to accept changes in the face of better evidence. Openly accept fault when your decisions fail in practice. 2. Administration. Learn to document data points across a variety of subjects and build knowledge cases. 3. Management. Management is a hybrid of leadership and administration. Even if you are not in management yourself you need to empathize with those that are in order to solve for their concerns and influence them. 4. Expenses. You need to estimate how much a given technology costs before adding it to a technical proposal. Expenses refer to asset consumption which is much more than money and free software comes with expenses. 5. Behavior and motives. You cannot influence people if you have no idea what they want. What people claim to want versus what they actually seek out are often two different things and nobody will tell you that.