We have two distinct agile teams, each working on separate, but related, applications.
Each team has, until now, been able to work in an independent fashion (distinct code bases, persistence stores, sprints, backlogs etc). Recently, product management decided that these applications will become even more closely integrated. On a side note, the size of each team (comprised of QAs, Devs, BAs) will be increasing over the next 6-12 months.
Management has decided to keep the agile process largely intact, since it has worked well (two teams working independently as much as possible) but have floated the idea of a contract-based service layer as means of integrating the applications.
In each sprint, any story that requires integration with the other application will be identified. At that point, an additional “integration” story will be added to the other teams backlog. That team will then be tasked with fulfilling the contract. In the meantime, the other team can continue their original story work, substituting a mock/fake service until the other team produces a working service.
Since Agile preaches a KISS philosphy, several people on the teams have taken issue with the “complexity” of this approach. They are advocating continued used of stored procedure sharing as a leaner/simpler integration methodology that “has worked well in the past”.
I prefer contract based programming for all sorts of reasons, but the main reason is it’s ability to provide compile time visibility into the behavior your application is expected to provide. You also get clear boundaries around who owns what code, and whose code you are likely to break if you break your contract. Stored procedures do none of that.
Since we have already reaped many benefits from agile, I’d like to think that there is already an “agile-friendly” way to deal with this kind of app integration/synchronization. Does creating a contract based SOA layer meet the agile smell test? Is there a third option I haven’t considered?
Great question. Walking the design tightrope is always a tricky one. I think keeping the applications as loosely coupled as possible is definitely the way to go.
The simplest thing that could possible work is a great approach, but following this to a dogmatic end without regard for the SOLID principles and general good design is going to give you two applications that are tightly coupled and probably full of technical debt that will bring the team grinding to a halt at some point in the future.
Decoupling and adding the abstraction in now seems like the most sensible thing to do, as long as you aren’t adding lots of additional “framework” that isn’t yet needed. The trick is to ensure you have a good enough design that would allow that framework to grow if needed, without building out a lot of unnecessary stuff at this point – you need to do just enough to decouple the applications.