Architecture and framework choice team issue

Question

We are in the process of planning for a rewrite of one of our fundamental applications. It is web based, and we are locked into PHP. However it is not a web 2.0 site. It's closer to an enterprise application.

It's by no means simple. There are at least 2 main interfaces (I think there are 4, but that's another topic). It needs to be both highly configurable and highly customizable. I would expect between 50 and 200 installs per year, so ease of maintenance is a major concern.

So the problem comes in the architecture. I want to do a formal high level architecture first. Before anything else. After that, we would then either pick a suitable framework (one that fits the architecture) or pick one close and use it as a library set. I feel this methodology will guarantee a workable system in the long run (since at least the full architecture is considered)

However, the rest of the team wants to pick a framework (they want to use YII) first and skip the high level architecture completely. Their argument is that the framework did the high level architecture first and let's you "just start coding".

Basically, I think this is like putting the cart before the horse, or building your house with no foundation on top of a mud pit. I know this view is popular in the post-ROR days of rapid application development since more can get done faster. But I really fear that for a mission-critical core application, this is short-sighted at best (and negligent at worst).

I really fear we are going down the wrong path.

Management considers me as a senior developer. So technically I can overrule most of the others. But I am not above them, so in practice doing so would be bad. Mot to mention that there is a major language barrier (they speak Polish, I speak English).

And I think I should mention that I really don't like most RAD PHP frameworks. Not because they are bad by any means, but because they tend to (IMHO) enforce the mentality that architecture is not important since they do it for you. Not to mention that they typically want you to work their way (Rails is famous for that) rather than a way that makes sense for the project at hand. So I typically only use a framework as a set of libraries. Using the classes when they make sense, and building my own when the project requirements dictate so).

So my questions are as follows:

1. Am I right in my concern? Or are they right and am I just over-reacting?
2. If I am right, is there any advice on how to handle the situation?
3. How can I get the team on my side without causing a mutiny?

Answer 1

You may be interested in my recent blog post: Don't Put the Cart Before the Horse where I talk about how important it is to define the problem you're trying to solve before settling on any architecture choice.

As for getting the team on your side, there are multiple solutions because there are multiple reasons for resistance.

I recommend this book: Driving Technical Change: Why People On Your Team Don't Act On Good Ideas, and How to Convince Them They Should by Terrence Ryan. It's coming out soon, but you can order the beta e-book right away, and this applies to the final e-book when it's ready.

(disclaimer: I reviewed a draft of that book, and it's published by the same company who put out my own book.)

Answer 2

I'd say both of you are right. Considering the architecture is fine. But Architects often tend to overcomplicate things. It's not uncommon for developers to accuse Architects of living in an Ivory Tower, while they are down in the trenches. However, being in a trench is pretty low down to the ground, so developers often don't see forest for the trees, which can lead to equally undesirable ad-hoc architectures or island solutions that dont connect too well.

As for frameworks providing a higher level architecture already, well, yes. They do. But that doesn't mean it is the architecture you need. The things you will find in frameworks are (hopefully) modeled after established Design Patterns. Design Patterns are suggested solutions to common problems. If you do not need to solve these problems, you dont use a framework solving these either. It is the wrong choice. Now, that's rather generic, but you get the idea.

My advice would be not to abuse your senior developer position and force a decision onto them. Find a compromise. Involve them in the decision but expect them to discuss. I don't know the working environment at your place, but maybe consider adopting some agile processes, like Scrum. Maybe make some exploratory coding first with different frameworks to see what is better suit. It's better to fail with one framework early than to realize it's the wrong horse in the end.

Answer 3

I'm having trouble picturing the high level architecture without any detailed info, but for what it's worth, this:

I want to do a formal high level architecture first. Before anything else

sounds pretty sane to me. Before picking a framework, it needs to be clear whether its structure is suitable for what you need to do, without having to bend it so far that it isn't that framework any more.

As to the how... I'm sure others are more qualified to answer that than I am. However, if time is of the essence, and the majority of the team wants to go the "let's get started right away" route, I would try to convince them to do at least a small number of architectural sessions first - and if it's just one or two afternoons.

If you don't really have authority over them (and even if you have), ask them to humour you for a limited amount of time. In my experience, architectural shortcomings and problems tend to come out pretty quickly once you get into it ("We need to do xyz. How do we do this in Framework X?"). An intensive session of simulating scenarios (and problems) might make people want to think twice about which platform they pick.