<aside> 📐 When people in the software industry talk about “architecture”, they refer to a hazily defined notion of the most important aspects of the internal design of a software system. Good architecture is important, otherwise, it becomes slower and more expensive to add new capabilities in the future.
</aside>
<aside> ❓ Feel free to contact us at [email protected] if you have any questions.
</aside>
The architecture team exists to provide high-level technical advice on how to tackle difficult features in the applications we build at Bitwise. The first interaction a POD will have with the architecture team is during the internal kickoff of a new project, where we will be looking out for difficult or complex areas that we can help clarify and/or provide options on how to implement.
The architecture team also fields requests from anyone in tech services about anything from questions about whether it’s wise to rewrite a project, difficult technical problems that have been stumping the team, to just general sound-boarding sessions.
Architecture takes a broader approach to software development, we specialize in the breadth of technical solutions as opposed to depth. It’s important for architecture to take a broad view of the development landscape so that we can provide multiple solutions and trade-offs between them, as well as know techniques that developers may not be aware of.
Our first interaction with a project is during the internal kickoff. We also are proactive in identifying projects that may benefit from our help and reaching out to them. Additionally, we take requests from the Development/PM/DevOps teams as well and react to those accordingly. Architecture can be consulted during any stage of the project.
You can reach out at any time to request support from architecture. The best way to reach out would be to email [email protected]. Based on your requirement, please use one of the two forms documented below.
Architecture New project/Internal kickoff request form
Architecture consultation request form
When reaching out to architecture, we will try to gather as much information as possible. This usually involved looking at the code to get context on the ask, referring back to the original Project Plan and various amendments since then, and potentially looking at client communications and various other sources.
Essentially we will be trying to gather as much relevant information as possible so we can be as useful as possible to your team. Developers’ time is precious and we don’t want to waste it!
An ERD or Entity Relational Diagram is a description of how a developer could map out the database in the system they are going to build. Architecture will not often provide complete ERDs but often we decide to focus on a particularly complex or unclear part of the system and turn this into an ERD to help concretize ideas of how to implement the system for the developers.