One of the things I am currently working at is a project that affects two communicating components. Both components are handled by dedicated departments and therefor different development teams.

Just phrasing the functional requirements alone won’t cut it.

Phrasing the functional requirements was easy. We knew what we wanted.

What we could’t tell initially was where implementation should take place. One development team was working on our payroll the other on another departments so naturally we wanted the best part of the implementation to be done by the other team.

But without looking into it we risked the implementation to be complicated for some changes might not have been ideal on that side of the spectrum and should better be done on the other side by our own team. Money-wise we would’t care as it’s not our budget but time-wise we would have to accept a much bigger time frame.

Another risk was that misplaced changes that are implemented on the “wrong” side may have consequences in terms of user experience that draw from the attractiveness of the projects outcome.

So it is worth to dive deeper and look at things from an architectural view to find out which todos should be placed on the one and which on the other side.

Discussing this back and forth with both departments before implementation – ignoring the financial aspects for a while – lead to a better understanding for each other on both sides and eventually to all todos ending up on the right side.

Now we can be sure that the project will take the minimum of time and have the maximum of quality.

architecture

<< Could Samsung create a Facebook Killer?

What Open Source is to me >>