What is Compass?

Compass is a developer portal that provides a unified real-time representation of the engineering output in one place.

Compass helps you track the things your engineering teams build — we call these components. It naturally compliments Jira, which tracks the effort of your engineering teams in building those components.

What are the main aspects of Compass?

Compass has three main aspects that help you manage the output of your engineering teams:

• Component catalog – a collection of all your organization’s software components that brings dispersed information and teams together all in one place. Navigate your software architecture, track your components and the relationships between them, the teams that own them, and the tools and practices that power those components – not only to keep them running but also to improve them.

• Apps and integrations – a platform to build custom apps and integrations with a forthcoming focus on component discovery and data ingestion from external tools to provide insights into the status and health of components.

• Teams and culture – strong guidance inside Compass to help you cultivate behaviors that improve your organization’s development and operations practices.

Who is Compass for?

Compass adds value at different levels of your organization, from developers to engineering managers running multiple teams.

Compass is for you if you are in one of the following roles:

• Developer – You write code, and with the advent of DevOps you also take on the responsibilities to deploy and operate that code. You want to learn about your software architecture; find information about components, their owners, resources, and evolving relationships between components.
• Engineering manager – You lead one or more teams, facilitate their work, their practice, and their success. You want to onboard new team members to your software architecture; find information about components, their owners, resources, and evolving relationships between them; gain insights into the operational status and health of the components that your teams are responsible for or depend upon; verify the performance of your components and ensure metrics are trending in the right way.

Compass is for modern engineering organizations that have identified the difficulties of development sprawl and see opportunities to address operational health holistically. Learn more about what is development sprawl and how you can manage a sprawl with Compass.

What is distributed architecture?

A distributed software architecture, or a microservice architecture, is a set of loosely coupled, coordinated services running independently of each other, often across multiple sources of computing, in multiple regions. Each service performs a separate task and orchestrates into a larger set of outcomes.

A distributed software architecture provides several benefits to modern software organizations:

• Regional deployments provide resilience against computational failures and bad deployments.
• Smaller teams that specialize in different services are responsible for each service. They work in independent codebases that are easy to manage. The development effort is scalable as you add more functionality to your software.
• Each service provides separate and complete functionality. You can expand the capabilities of your software by adding services to your architecture.
• When a service reaches its maximum load capacity, you can deploy new instances of that service, thus enabling horizontal scaling.
• Smaller frequent deployments to individual services help achieve higher velocity.
• Separation of functionality reduces the risk of breaking changes that impact the entire software. It is easy to isolate and fix faults and bugs in individual services. You can deploy changes only for a specific service, without bringing down the entire software, thus providing higher reliability.
• You can choose the technology stack that is best suited for specific functionality, providing you with more flexibility.

A distributed software architecture has some challenges:

• The connections between small services create a complex distributed system requiring precise coordination and optimization.
• Increased dependency on multiple services means developers need to create communication mechanisms with services and handle failures of other services.
• A large number of services and frequent deployments increase the operational complexity of the software. An experienced operations team is required to manage constant redeployments and frequent changes in the architecture.
• Participation by many teams requires precise communication and coordination. Everyone involved must be able to easily find the required knowledge to understand the product.

An example of a distributed architecture is an e-commerce website, which has many capabilities such as user management, catalog and inventory, shopping cart, checkout and billing, payment, shipping, and delivery management. You can realize each business capability by a separate service or group of services that are owned and developed by specialist, domain-expert teams. Collectively, these services form the distributed architecture of the e-commerce website.

Modern software organizations that are using a distributed architecture often experience software development sprawl.

What is development sprawl?

Software development sprawl is the ever-growing mass of output that a modern, distributed software architecture generates.

An increasing number of software teams are using distributed software architecture. A plethora of built-for-purpose tools and frameworks encourage developers to build new services, rather than expand on the existing ones. Advanced CI/CD capabilities enable software teams to deliver less error-prone changes in a much faster and automated way. As a result, there is a sheer amount of growth in the engineering output, such as services, APIs, libraries, and other artifacts, which we call components. There are also artifacts such as repositories and documentation which are linked to these components.

With an unmanaged growth of their output, software teams experience difficulty in maintaining complete and timely information about their software architecture. They must have a holistic approach to software and service development, which understands the entirety of the process and tools involved.

Software developers often have the following questions:

• Who owns a particular software component?
• Who to ask if I need information about a component?
• How to reach the component’s owner when there is an incident involving it?
• How are different components related to each other?
• How to make changes to the components in ways that can maximize operational health?
• How to avoid causing a negative impact on the dependent components?
• How to create software components that follow best practices?

In addition, engineering managers and leaders have the following questions:

• How is the health of the components that my team owns or uses?
• How do I know if those components are performing to an agreed level of compliance?
• How do I apply best practices and policies to ensure compliance and consistency?
• Are my teams achieving operational excellence?
• How can I monitor performance trends of the components that my teams own?
• How can I collect timely and accurate information about people, data, and trends of the component for reporting purposes?

The inevitable complexity of so many moving parts becomes overwhelming to software engineering organizations of all sizes. The complexity of software development sprawl, if left unmanaged, can result in a lower velocity of value delivery and poor operational performance, affecting not just your teams, but also your customers.

You can manage development sprawl with Compass.

How does Compass help manage development sprawl?

The increasing use of distributed architecture leads many modern software organizations to experience development sprawl. If left unmanaged, sprawl leaves you with disconnected information about your engineering output, which we call components, and the teams who maintain those components.

Compass brings disconnected information about components and teams all in one place and helps you manage development sprawl.

Here’s how to get started with managing your sprawl with Compass:

1. Create a component catalog and start tracking a component’s ownership, relationships, and health from a centralized place. Populate the catalog by creating components either manually or via the Compass API.
2. Declare component relationships to get a bird’s eye view of where a component fits in your software architecture. Have a rich context of how a component works and understand the impact a component can have during incident resolution.
3. Add ownership to keep track of who maintains and operates a component. Surface a team’s deliverables in one place and make components discoverable. Enable team collaboration towards following best practices for maintaining the long-term health of components.
4. Automate component management by reusing existing code repository structures to configure and manage your components like code. Apply version control to component data and ensure components are always in sync with your repository.
5. Integrate with other DevOps tools in your toolchain. Build custom integrations with third-party apps for component discovery and data ingestion to track the status and health of components from within Compass.