Finding the path to success is a major part of our work, as there is no “one process fits all”. Nonetheless, some patterns emerged in the past that show how our contribution could unfold.
The Manager’s Perspective
When joining a project, we start by understanding the goals, constraints and status quo of the affected stakeholders. We review existing plans, identify potential action items—including those already in place and new ones emerging from our analysis—that might contribute to the solution, and then conduct an initial prioritization. Often, we find that time constraints make some actions immediately necessary, while others can be deferred. Following this, we perform a deeper analysis of the highest-priority items until we’ve identified sufficient improvements.
Architecture and organization are inherently linked; architectural and organizational interfaces frequently overlap. As a result, changing the architecture and the corresponding interfaces often requires convincing many stakeholders in different organizational units—as it impacts architects, developers, testers, integrators and potentially even customers. Therefore, we rely on our experience as a guide but ensure that decisions are data-driven. By gathering supporting data, we enable stakeholders to evaluate and contribute alternative solutions based on clear insights.
The Developer’s Perspective
While it can be frustrating to have to modify your code due to newly identified architectural properties and limitations, not knowing how to change it to make it fit is even worse. That’s why we thoroughly analyze your system to develop tailored guidelines specific to your situation. Rather than stopping at generic advice commonly found online (e.g., “respect data locality”), we provide actionable engineering insights to address your unique task.
For instance, in the case of data locality, we might give you precise figures what “local” means, what the penalty for non-local access is, which tasks you can perform while waiting for non-local data, and what all of that implies for your algorithms and data structures. Depending on your project’s needs, we can either stop at this advisory stage or support you all the way through implementation—whether collaborating directly with you or providing pull requests for you to review.
The Software Architect’s Perspective
Data and facts are the foundation of sound design decisions. With the increasing complexity of modern systems and the numerous specialized areas to address—such as safety & regulations, features & usability, organization & schedule, efficiency & cost—it is nearly impossible for any architect to collect and organize all facts one would ideally consider.
We support this effort by gathering hard facts on hardware, software and the system level. These answer basic questions like:
- What is the cost of a kernel call?
- How many numbers can that accelerator crunch plausibly per second?
- Is that algorithm really the best choice for our SoC?
- What would happen if we changed the number of threads?
- Where are we currently memory bound, and where compute bound?
With these questions addressed by us, you can concentrate on the broader system design.