The question is no longer just what is the appropriate data structure or what type of server to use, but: how do the pieces all connect, and how do we minimize diversity and costs? The focus shifts from one of designing a program that accomplishes a specific task to one of making decisions about platforms and options for connecting all of the pieces. Architecture is really about managing how these decisions are made which is also known as architectural governance.
Paul Preiss, founder of the International Association of Software Architects (IASA), describes that the “project manager reports to the stakeholders while the architect must report to the shareholders.” Architects must be concerned with issues that protect the shareholder’s investments in the companies.
An architect requires a broad set of skills and tools to overcome the sometimes daunting task of architecture. The list of possible skills for an architect can be rather long (See the IASA Skills Library for comprehensive list), but I would like to focus on some of the most important ones. Think of these skills as a basic toolkit to help an architect get started, or improve.
Establishing an Architecture Governance Model
You may have been slated with starting up an architecture practice at a company. Where do you begin? What needs to be in place? You may fail if you decide to start documenting all of the existing systems. Start to get a control over the communication and decision making processes. Focusing on governance models will lead to better reuse and greater standardization, leading to quantifiable cost savings that can be used to prove value quickly.The Right Pictures Can Be Worth a 1,000 Words: Architectural Artifacts
Diagrams and various documents can be indispensible when communicating with the teams on a project. Establish a set of artifacts that are part of your repertoire as an architect to speed up their creation and make you and your team more productive. This may include templates for creating the artifacts or defining what certain types of artifacts contain. Remember that one methodology does not work in all companies. You may know every detail of UML, but that may not fit with the culture of your current company and you may need to adjust what kinds of artifacts are used.See the Big Picture, but Pay Attention to Scope
An architect needs to look beyond the immediate stakeholders, like the person paying for the system and the end users, and make sure the needs of other interested parties are addressed. This is a balancing act, because too many interested parties can lead to “scope creep”. You need to understand how to manage the stakeholders, interested parties and scope.Politics and Architecture
You will have few resources and need to get a number of people to work with you. You will need to understand what you need to do to get buy-in for your initiatives and how to keep people on your side. Remember that resources will be limited in terms of time, people and money and the politics is how resources are allocated.Thinking Beyond a Functioning System
A functioning system is certainly important, but an architect needs to think beyond merely functional software. Cross cutting features such as performance, disaster recovery and security need to be considered in addition to what the project stakeholders need. Remember that the shareholders are depending on you to protect their interests.Think Performance, Scalability and Capacity
How will the system scale? What will need to perform well? Performance and scalability often haunt many past efforts, so being concerned with these topics is important, but don’t over do it by focusing on making everything fast at the cost of increased complexity which can lead to a system that cannot be stabilized.Security Architecture
In this connected age security has become important. You need to understand security techniques and methodologies that are useful when architecting systems. An architect should look at security methodologies like STRIDE and risk assessments like DREAD or RACI and add them to their toolkit.Availability and Disaster Recovery
The architect needs to be thinking about what would happen if there is an interruption of service on the system and how key this would be to the business. This means working with the business owners to determine the cost and time and necessary availability.Deployment
Systems need to be deployable and this needs to be thought through early in the process. Equally important is making sure you have a back out plan and mechanism in case the deployment does not go as planned. This could include governor mechanisms so that the system can run crippled or at a lower resource level.Keep it Simple
The system ultimately needs to be built. It may be and it might be fun to put all of the latest and greatest technologies and patterns into the prototype, but this might not translate to a deliverable system. You need to remember that the resources that will build the system will most likely to learn the technologies. Knowing when and how to introduce new technologies is an important skill.Leadership and the Architect
Ultimately, an architect is a leader in the organization and must develop the skills necessary to support this role. There are many leadership techniques and resources available that an architect should be part of the architect’s toolkit. Some of the best are Situational Leadership II by Ken Blanchard and the Seven Habits of Highly Successful People by Steven Covey. These methodologies help you understand what an individual that you are working with needs from you and what your expectations are of them.Mitch Ruebush is the Leader of the Architecture Team for ING DIRECT, the largest direct bank in the US. He is president of the Philadelphia IASA chapter and serves on the IASA Board of Directors. He has authored many books and articles and speaks at a number of events each year.
Comments