As an architect out in the community, I am often asked by people how they can become an architect. They want to know what an architect does. After all, it is sort of obvious what a developer does. They develop software, usually by writing code. But what does an architect do all day? Well, It Depends.
That’s the answer. It Depends. It’s really easy. The answer to all architectural questions is ‘It Depends.’ Should we use an ORM in our persistence tier? It Depends. Should we use role based or claims based authentication? It Depends. Which is the better starship captain? Kirk or Picard? It Depends.
One of the most important skills an architect has; the greatest value they bring to their teams and their organizations is critical thought. The architect needs to use critical thought to explore the options, weigh them against the company’s strategies and what makes sense. This critical thought must expand beyond what she wants to do on her team, and understand the effect across the whole organization. Critical thought goes beyond just picking the right technology, and brings together all of the aspects that we, as architects, need to address.
Many times customers will ask me to walk through their proposed architecture for a system, and to give feedback. One customer was walking me through their new ‘standard application model.’ This model was to be used on all future projects, big and small. It had a database, with a persistence layer. This layer was exposed through web services to a business layer. The business layer was in turn exposed to the presentation layer with web services and REST. Each service layer had to map and unmap messages from their Data Transfer Objects (DTOs). This resulted in a very flexible architecture, if not somewhat complex. They asked “Is this a good architecture?” My answer? “It depends.” I then followed up with a series of questions. What type of applications do you plan to develop with this model? How much flexibility is your business driving you to implement? Does the service façade in front of the persistence tier provide any real value (ie. Hiding the complexity of where the data resides.) My end goal was to find out what they thought they were buying with their use of complexity.
I often see complexity as a currency that architects spend on their projects. Less experienced architects often feel the need to deliver a super complicated model, to show the value they bring to the team. They hope their model has so much foresight built in, that the team will appreciate this, and love them for it. When in the end, the complexity wasn’t needed, and only added to the challenge and cost of the project. An architect needs to know when to spend complexity on the project, and know what they are buying. In the case above, they were spending complexity to buy flexibility they didn’t know for sure that the needed. So we discussed a way to provide hooks for eventually putting in a services façade, without actually building it in yet. We left the door open to that complexity, when it was needed. The critical thought came into play when trying to decide if their model was a good spend of their complexity currency, or if they were seeking complexity because they could.
An architect is usually the bridge between the business and technology. This is not meant in a ‘requirements gathering’ position, but an active engagement role. The architect must understand the business, and be able to provide solutions that use technology to answer to pains or opportunities the business is facing. To be successful in communication with people in the business, the architect must be able to understand their concerns, use the business vocabulary, and be able to show that she understands how to align technology with what is truly important with the business. You can’t be seen as the ‘Nerd Herder’; you need to be seen as the person who knows how to deliver business value through driving IT.
In order to do this, the architect must understand the business. What does their company do? Who are their customers? How do they provide value to their customers? What is the market cycle? What are the numbers management looks at every day to make sure their company is on track? If you can answer these questions about your company, then you are in a good position to provide the best guidance possible.
In most organizations an architect typically carries the flag for process. The architect should work with their teams to develop a process for successfully delivering projects to the company. This process needs to support the modern needs or a technical project, as well as provide the business controls the company needs. These business controls are usually dictated by the regulatory and legislative environments of the company’s industry. The architect must work to help their project teams understand the process thoroughly enough that the team buys into the process.
This leads us to the next important skill, consensus building. The architect can never dictate. This only creates walls, and walls reduce the business value you can provide. The architect instead must try to build consensus and buy in on important decisions. The architect can also provide value by providing guidance. Guidance clearly outlines a situation, the proper approaches to the situation, and the reasoning to why those approaches are ‘proper’. There are several tactics that fall into this category, but they are mostly a flavor of ‘get everyone’s fingerprints on the murder weapon.’
This is the concept that everyone involved in a decision must have complete buy in when the decision is made. This isn’t for CYA purposes, or to protect your career in case the result goes sideways. This is important because you are more likely to be successful when everyone is on the same page and supports your direction. You don’t want anyone holding back from pointing out a potential risk to your plan.
One way of getting everyone’s fingerprints is by socializing an idea before it comes up for serious discussion. Start this process by knowing as much about the idea as possible. Perhaps your idea is to take a different approach to processing orders from your company’s website. If you do your homework, write a proposal, and send it up the food chain, you will most likely be greeted with a lot of resistance, if not an outright no. On the other hand if you start socializing your recognition of the current approaches limitations and pain it might cause, and then shift into possible ways to alleviate that, you will start building a base of support and understanding. When you do finally float your official proposal, the ground work has been laid. People are already familiar with the issues, and possible fixes. They are prepared to understand and approve your proposal before it is presented to them. This applies to all changes you want to implement, not just ideas that must get CEO approval. Circulating around the project team an idea to move to a different approach to testing can also help in building support for the change.
These are just a few of skills you need to be successful as an architect, and there are many more. Having a strong grasp of these core skills can form a base upon which you can build the rest of your career as an architect. Take these skills, and use them to answer ‘It Depends.’ Break the situation down, bring to bear your understanding of the business, and find the best answer for your business.
written by Brian Prince
Subscribe (RSS)
