It's never a good idea, in my experience, to split an application horizontally—into back-end and front-end subsystems assigned to different teams, for example, or into separate application and platform teams. Typically, back-end/platform interfaces are vastly more complicated than they need to be to solve the actual problem at hand. They are based on guesswork about what another team might need, and often introduce considerable complexity to address eventualities that never come up. (It's rare for the back-end teams to have regular conversations, much less a collaborative relationship, with the people who will be using their work, so it's all guesswork.) Too much "flexibility" of this sort is deadly. In the worst case, back-end "improvements" made in isolation can break the front end entirely. On the front-end/application side, the unnecessary complexity makes simple tasks difficult. Sometimes it's impossible to do things you need to do. That mismatch creates a time-consuming "discussion" between the two teams to change or augment the APIs. Your delivery pace slows dramatically, and in many cases, the issues are never resolved satisfactorily. Then there's constant squabbling and infighting (and budget battles) between the two camps. The solution is to work in thin vertical slices, where teams have all the skills they need to get an entire feature (I'm reluctant to use that word, but think small) out the door and can touch whatever code they need to touch to do that. When APIs are created only when needed and do exactly what's needed and no more, unnecessary complexity is never introduced. That's not an easy change to make in the face of entrenched management that has a vested interest in maintaining the silos, however. Governance is also a problem. A team cannot make changes to an API that break existing code, for example. That's one of the reasons you need somebody in the Architect role—to coordinate (not dictate) changes—but that's another political can of worms. Architectural review boards are a disease. So, the problem may be intractable in your organization, but the more collaboration and focus on building the minimal system that gets the job done happen, the better off you'll be.