Cosmos Series Part 4: Results-Oriented Critical Thinking

This is Part 4 of a four-part blog series sharing learnings from our journey to optimize the people, processes, and technology powering the platform for our Cosmos managed service. Watch this video to learn how Cosmos combines attack surface technology and expert testing to deliver continuous threat exposure management while reducing the burden on security teams.

Part 4: Results-Oriented Critical Thinking

In my earlier blogs, I have discussed how our engineering and product teams have transformed our approach to building the Cosmos platform, which has improved scalability, flexibility, and velocity of feature development. Those blogs covered our architectural principles, being outcome-driven, and embracing automation. In this post, I will cover how strengthening our critical thinking is improving our velocity even further.

Throughout my career, I’ve noticed a trend: many people avoid critical thinking. I’ve observed three predominant reasons for this. Some people think they are already applying critical thinking yet can’t articulate the reasoning behind their proposed decisions (subjective thinking where the facts aren’t fulling known). Others believe critical thinking stifles creativity and actively resist an empirical foundation for the proposed decision (creativity beats facts). A third group simply haven’t been exposed to critical thinking as a structured approach.

The MIT Sloan School of Management describes critical thinking in business and engineering as “the disciplined process of evaluating information and evidence to make logical, unbiased decisions. It requires questioning assumptions, challenging prevailing norms, and relying on data and analysis to guide conclusions.”

At Bishop Fox, we bring critical thinking into our Cosmos platform development through processes like rank ordering and the continuous measurement, review, and improvement of our engineering practices.

One key aspect of how we implement critical thinking at Bishop Fox is by starting our analysis with the end result in mind. Similarly, we approach architectural decisions by focusing on the desired outcome. While this might sound obvious, in practice, it rarely is. When presented with designing a process, a service, or a feature, most people start by listing the necessary components. They make assumptions about the result (the success criteria) and focus on what they think needs to be done to orchestrate and what the inputs need to be.

I view this input-first approach to be a mistake. Instead, I recommend starting with the desired result, not the (hypothetical) inputs. The design work will then generate an approach to the process that is highly flexible, responsive, and scalable. By starting with the result, we can easily move backwards through each step, which isolates each service more effectively from others and from previous steps.

As the designers, architects, and engineers start with the result and work toward the necessary inputs, an event-driven, asynchronous, small-service approach emerges naturally.

By contrast, when we take an input-oriented approach, several errors commonly occur, including tight coupling, orchestration code, secondary management systems, and active requests.

Common Pitfalls of an Input-Oriented Approach

• Tight Coupling. Tight coupling is where services are connected or dependent on each other, and a change in one necessitates changes in the other. This frequently occurs when the team is still following an inputs-to-result orientation in their designs and thinking. While services share a language, none should require the existence of another specific service.
• Orchestration Code. Another common error is when the team builds ‘if/this/then/that’ logic across multiple services. This mistake creates ‘scavenger hunt’ bug searches and results in important behaviors residing outside of the service code. If the system’s workings rely on external documents (or worse, an oral history), which isn’t in the code, evaluate and address the issue.
• Secondary Processes and Services for Primary Service Management. A third mistake is apparent when teams design secondary processes and services just to ensure the primary processes are operating correctly. Secondary services may support reporting, monitoring, and such, but they should not reach back into the primary services and modify their behavior or force replays.
• Active Requests. Lastly, reviewing the language used in event messages can also reveal issues. If the messaging shifts from ‘I have done this’ to ‘I need you to do this,” the latter indicates coupling has increased, and a review is needed to correct.

By adopting an outcome-based mindset as a foundational element of critical thinking, we’ve accelerated our teams’ velocity to deliver new features and capabilities and minimized code through better design.