# Learning in IT - Think like an Architect

- URL: https://www.technolitero.com/blog/learning-in-it-think-like-an-architect
- Markdown: https://www.technolitero.com/raw/learning-in-it-think-like-an-architect
- Date: 2026-08-16
- Author: Buddy
- Topic: Learning

## Architect Workflow

<div>There are many qualities in a great Engineer and an Architect.  I would say that in my experience I have worked with many Engineers that could become Architects if they wanted to.  The expectations are different and some would rather be more technical than deal with design, processes and documentation as their primary role.  It doesn't mean that they are incapable of it, just that they're not interested in it.</div><br><div>Architects look at things holistically, cross IT teams, the business, end user usability.  We select vendors and make the decisions if we can do it with what we have or if we need additional hardware/software/head count etc... in order to support a solution.  A good Engineer can design and implement a solution well, most of the time this is for their area of expertise.  They are not looking at what other teams are doing and see tooling costs can be lowered by using the same system.  That's not their job and I can respect that. Architects look at things from a different perspective, and the job is as much political as it is technical.  I like to build things so that's why I went down the path of Architect but at a high level these are some of the questions that you need to answer when building a solution.</div>

  - Understand the problem you are providing a solution for, ask questions.
    - Investigate the solution.
    - Have questions answered by the ones that are impacted by the solution.
    - Know what you are working with.  What hardware or software is involved, what is the user impact and the expected Tier.
    - Know the BCDR plan and expected MTTR, MTBF and what the SLA is.  If there isn't one, ask about this as part of the design or propose one based on past experience and criticality of the system.
    - Know that you need this or the plan you create will fail or at the very least be updated several times, and in my opinion that's not a plan.
    - What does the budget for it look like?

- Look at things from the 500ft view.
  - The best solutions typically cross teams, technology and skillsets.  Design in for those.  Bob in accounting has different needs than Kim in HR or someone in IT.
  - If a solution is too hard to use, it won't be.  Design in a way that if you have to put a burden on someone it should be on IT not your non-technical users unless needed.
  - Pull additional teams in at the right time, this includes the business.  Don't pull in the Network and Security teams after you have already designed, make them part of the design.  This reduces rework and as many of us know best practice is environment specific and what works in a lab designed by the book doesn't work in production most of the time.
  - You need an understanding of how the solution is going to work cross teams, and the expected operational impact when the solution is live.
  - Don't be afraid to push back when something doesn't make sense.  Bad design decisions don't get better just because they are documented.

- Design
  - Once the first two steps are completed and you know what you are designing for, what the expected outcome is and who is going to be affected, make sure all of your documentation is correct.
  - Have the stakeholders review the initial documentation and once approved with only minor questions start building the design.
  - Design based on the parameters you have, Cost, Functionality, Operational Impact etc...
  - Have the stakeholders who will be implementing the solution take a look at the design, be open for questioning, you are not infallible and you could have some mistakes that need resolved to move forward.
  - Validate that it meets the requirements and then hand off for the build process to take place.

- Build
  - Once this has been handed off for engineering to build, or if you are also part of this process, make sure documentation is number one.  The reason for this is two fold.  The first is operational, if an engineer doesn't know how to run or fix the solution you will experience extended downtimes as they reverse engineer it.  The second is that depending on the regulations of your company you may have to provide process documentation to external auditors.
  - Automate as much as possible, having a script do the work reduces accidental configuration changes that lower security, delete files, corrupt the configuration or make the solution more prone to human caused downtime.  If you can document it, most likely you can script it.  Sometimes that doesn't make sense and it's not needed for everything.  I believe that if there is high impact if something goes wrong, automate as much as you can including standard care and feeding.

- Document
  - Documentation is the record of what was built on day one, it loses relevance over time as configuration changes are made, technology improves, software and hardware are upgraded and patched etc...
  - You must validate that nothing has changed that changes the documented design when something occurs that you know about can have an effect.
  - I would suggest at least a yearly review to make sure the document is current, this helps with troubleshooting or additional deployments.