We are adding these architectural requirements to the project. The purpose is to bring consistency between applications and enable us to realize better re-use across our code base.
Those "requirements" to add any value to the application from my customer's perspective. They introduce complexity and risk as an added "benefit."
The complexity is a balancing act. While it may introduce some complexity to your application, the goal is to reduce the total complexity as taken from an organizational perspective. In other words, while we may add some here, we balance it out by reducing complexity in other place and by having consistency, which makes complexity more tolerable.
In the meantime, I'll never get my application done because I'll be building an infrastructure that doesn't give me an application. Customers don't buy architecture, they buy features.
But architecture enables features to be built. Done carefully, it provides for cost reduction and faster response in development. It also allows for better deployments, which means happier customers.
Go back to drawing your pictures and leave me alone to build my application.
It is that myopic attitude that codes us into a corner every time. Somebody has to look at the big picture.
I'm in an interesting dilemma. I'm the architect. I'm supposed to be thinking big picture. But I'm a developer at heart. I think pragmatically. This is leading me to ponder a lot.
Take a series of products (web and thick) that have been developed over time and distance, brought together now mostly by acquisitions, and meld them into a seamless whole. In the process, open up the internals so customers can customize their workflows using our products. Oh, and do this without disrupting development.
Do this without disrupting development? Architecture should never be a disruption to development; it should be the foundation. As such, if it is being seen as a disruption, that means that there is something out alignment. Until your environment is realigned, you will struggle. From my experience, these are the most likely to be out of alignment.
The Architecture: The architecture itself may be causing the misalignment. Most often, when the architecture is at fault, it is because it is too complex for the problem it is trying to solve. This tends to cause ripple effects through the organization as people fight back. Since this is the architect's primary domain, this should always be checked first. Be honest about it. As architects, we have to decompose complex problems, but it is possible to over do it.
Far less often, but still possible, is an architecture that doesn't accomplish what it is setting out to do. If the architecture isn't complete, it will be difficult for people to catch the vision.
Developers: Developers and architects should not be constantly at odds, but sometimes it can feel that way. In my experience, the most challenging developers are the ones who want to know "Why?" It isn't that they shouldn't be allowed to ask, but rather that answering that question can be time consuming.
Answering "Why?" is a two-fold process. First, each aspect of the architecture should correspond to a real business driver. Second, there should be management agreement with those drivers. Ideally, all developers will be satisfied with the business drivers, but at some point, you may be forced to say "because it's the way we are doing it" and without the management agreement, you won't get anywhere.
Management: Management can throw things into confusion if they do not have a firm understanding of the answers to "Why?" There are problematic developers that will try to use management's lack of understanding. Management doesn't need to know the details, but they need to be sold well enough that they will back you up.
But management support isn't just about the problematic developer. It is also about the costs incurred while building the architecture. There is a cost associated with building an architecture, but it is a cost that should have positive business impact. Make sure you have management alignment.
I don't have things aligned yet. The fact that my assignment is coming under the terms of "don't disrupt development" means that management isn't clear on the value of changing the architecture versus continuing down the siloed application path. Instead, there needs to be a clear understanding that we are trading off a certain set of features for the opportunities that a consistent architecture provide.
And, honestly, if I'm having a conversation with myself like that one above, then I need to work on "why's" myself. If you aren't aligned with yourself, well, then you have a real problem.