When I was in college, my university built a “green” (a fancy field for people to hang out in the middle of campus). Instead of building paths immediately through the green, the university waited until “natural” dirt paths were built — and then paved those paths.

Why did they do this? I imagine, they did this because they didn’t know the exact paths that people would take or how the field would be used — and left it to the users of the field to figure it out.

In the enterprise architecture role, it is easy to become overly “zoomed out,” or focused completely on the abstract. When this happens, it tends to slow innovation down or stop innovation completely. Why? Because our mindset shifts from solving problems to fitting solutions into individual problems.

So what can we do to “pave the way” for developers without getting lost in abstraction?

Solve Problems For Individuals

Imagine a team wants to expose a service as an API or set of APIs without any pre-defined guidelines. What are the common concerns when the time comes to implement this? (Please note we are assuming the API has already been strategized, designed, and mocked — and skipping straight to implementation.)

Security

Adherence to global standards (logging, security again)

Resiliency (Retries, failover, graceful degradation, timeouts, circuit breaking)

Observability (Logging, metrics, tracing)

Exposing the API for consumption and being a good “API Citizen” (versioning your API, giving deprecation notices, etc.)

Typically, the application team will have a strong opinion on how to solve these problems — and that is a good thing! As an enterprise architect, letting the app team drive can be equated to a university letting students “create a path” where one wasn’t before.

Of course, when a similar problem or requirement from another team comes up, that same architect will be able to draw on the previous experience and implementation details, speeding up the implementation process for the next team.

Once a few teams have come up with similar solutions, a path has been blazed. At that point, it may be good to officially endorse the path/pattern, and start taking steps to smooth the pain points that developer teams have experienced. Smoothing pain points can take many forms including:

Implementation guides

Automation

Tutorials

Video Series

When solving for pain points and implementing an enterprise process, it is important to note that every situation is different, but making the process simpler and easier for beginners to understand and start using effectively is almost never a bad choice.

What does this accomplish?

Makes it much easier for new developers to get onboarded and start contributing.

Allows natural standardization of workflows (and hopefully graceful evolution if those workflows are modular!)

Creates a how-to guide for new hires.

Improves developer experience by giving a baseline that can then be innovated on top of, effectively “standing on the shoulders of giants”

The idea is not to set standards for the sake of standards — instead the standards can be set based on real life examples that have already been optimized and battle tested. This allows developers to use their brain power and effort for higher level outcomes.

If we really think about it — teams are made up of individuals. Individuals are the ones building true value — and the ability for individuals to focus on interesting problems instead of mundane ones that have already been solved directly correlates to both the velocity of value an individual can add to a project as well as that individual’s enjoyment of his or her work.