When I started my career I wanted to work with computers. I knew that being a programmer was not for me, I liked to play with hardware and the big picture. So I dabbled in PC support and quickly learned that I did not like being reactive. Some jobs are mostly reactive for example a firefighter. They train and prep, but most of their job is waiting for an emergency so they can react. It’s impossible to be 100% proactive as a firefighter. They have safety prevention and work to limit the effects of fire on the loss of life, but in the end they are still waiting for a fire. PC support was the same model. You wait for someone to break something, then you fix it. I have seen some really great PC support teams that are very proactive with training and locking down the PC. At the end of the day you are still waiting to react. I wanted to be more proactive resolving problems before they become needs to react. I went into systems administration convinced that computer will do what I tell them and I can enforce better outcomes. I spent a number of years focused on Linux-based server working to create a very well-managed solution that would allow us to not be reactive. I felt very successful in this journey to the point I became bored looking for new challenges. When faced with many years left in my career I needed the next step. That next step seemed to be Systems Architect.
What is an Architect?
In order to define an architect we should look to people who hold the title outside computers. Building architects are the easiest. A home architect takes into account many factors and produces a physical design for the builder to follow. Some of the factors a building architect has to consider are the following:
- Building code
- City regulations
- Lot size
- Available funds
- Customer requests and needs
- Best practices
Each of these things can really be categorized into two columns:
- Requirements – Things that must happen
- Constraints – Things that limit or control what must happen
- Building code – Constraints
- City regulations – Constraints
- Lot size – Constraints
- Available funds – Constraints
- Customer requests and needs – Requirements
- Best practices – Things to keep in mind
Notice how best practices are not requirements or constraints. It may be best practices to have a bathroom on the main floor but it’s not a requirement. In IT this is true as well. Systems Architects take information from the customer, their personal knowledge, and the constraints and form a solution. Each solution should represent the requirements and constraints of the project. An architect should understand building practices but does not have to be a practiced builder. They need to understand the innerworkings and requirements for each design choice. For example if I put down laminate flooring I need a underlay to reduce noise. An architect should be the master of proactive administration. Looking to reduce risk on a design and meet customer needs. Each systems architect needs a methodogy to ensure they don’t miss critical steps in the process. In systems I like to use the conceptual, logical and physical design model. An architect does not form the perfect solution. They form the solution that meets the customers needs with an eye to the elements of design.
Elements of Design
Early in my career I struggled to understand the elements of design. What critical thinking should I use to make sure my architecture will work well. VMware introduced me to the elements of design which mirrored my own really well. I use the term RAMPS to remember them:
- Recoverability – How do you recover the design from a failure, what is the requirements needs,
- Availability – How do you ensure availability of the solution, What options do you have
- Managability – Is the design too complex and costly to manage, how do you manage it
- Performance – Does the design meet performance needs and take into account growth
- Security – Does the design meet security needs and requirements
I would like to illustrate the elements of design with a simple scenario. The customer wants to deploy a web server running drupal for some new brand site. The following questions might help you figure out the requirements and constraints while ensuring the solution meets RAMPS.
- What is the expected RTO (Recovery time objective, how long to get it back into service after a full failure)
- What is the expected RPO (Recovery point objective, how much data is ok to lose in a failure scenario)
- How do you expect to backup the application, database and user-generated data?
- Is there off hours for the application?
- How much planned downtime is acceptable for the application per month?
- What is the cost per minute of unplanned downtime?
- Do you have a SLA (Service level agreement or objective) with your customers?
- Who are your customers and where will they be accessing the application from?
- How do you expect to make changes to the application?
- What are the roles involved in this project (Form a RACI)
- How often do you expect the content to change?
- Is there any unique requirements around the application that we need to know?
- How many concurrent users do you expect?
- How large is the application? Do you have any test metrics or data to show usage patterns or expectations?
- What is reasonable response time from the application?
- Any unique performance requirements?
- How much network bandwidth do you expect the solution to use?
- Does you application require a login? Where are they kept?
- What type of data is stored in your application? Is it sensitive
- What is the cost of a data breach on this application
- Are there any security policies from the organization that should be taken into account
At lot of these questions will yield no answer or unknowns. The performance metrics are a particularly sticky question. This is where our friend assumptions come to town. When you don’t know write down an assumption so people understand what your designed to with a lack of information. For example the customer may share they have no idea how many concurrent users will use the application. You should make an educated guess about the number, get the customer to sign off and move forward.
So what is an Architect?
So what really is an architect? It’s someone to attempts to meld best practices with customer requirements to form a usable solution. A systems architect has to take into account all types of things like:
- Interconnections between logical and physical elements
- Building space
- Logical architecture of the solution
- Best practices
- Current practices that are constraints
It’s a fun job that changes each day. If you do it correctly you should be reducing the reactive nature of your systems architecture. You need to plan, document, study then plan again. It’s a detail job that requires lots of thought but mostly lots of reworking and negotiation.
Yep in order to architect you need a customer. When building a house everyone wants a huge house with gold walls. You need to manage the expectations to successfully complete the solution. You have negotiate. The first rule of negotiation is simple every answer is a “yes, however” the customer can have anything they want, as an architect you have to help them understand the impact. Every choice has an impact just like every action has a reaction. If you want gold walls the cost will be impacted. If you want no bathroom on the first floor, expect to be an expert stair climber. Being an architect is as much about people skills as technical skills.