A recent (and currently active) project brings to mind the need for thoughtful transition architectures.  Our development team is installing [gasp] a web content management tool.  In the long run, I have no doubt it's the right move for our group and I advocated enthusiastically on its behalf.  The gasp is because it represents a paradigm shift for our technology stack insofar as the WCM is a commercial open-source J2EE application that is replacing an open-source Rails cms-- and don't hold that against us, we love Rails and continue to use it in many applications.  We just couldn't live with the relative lack of business-user friendly content management, workflow control, multi-site management and localization features.  When we get one of those in the Rails community then we'd love to switch back!

Back on topic....our web publishing platform is home-grown, meaning it's highly customized and poorly documented.  The good news: we haven't had a lot of turn over on the team and we did a good job of separating business logic into a discrete service layer.  The bad news: we have a lot of complicated business logic because the service layer is shared across multiple ecommerce sites in various countries and languages.  One case in point: Imagine the already-daunting complexity of calculating taxes in the U.S. for a multi-channel retailer, and consider how you would do the same thing in 5 European countries where you must display prices inclusive of VAT--all at different rates, plus a couple Asian countries, and throw in a South American country too.  And then imagine all the marketing campaign tracking, revenue allocation and web analytics that need to go along with each of those sales portals!

Now, the architecture diagrams....

A single website's high-level architecture today looks something like this:

And tomorrow we want to get to a place that looks more like this:

It will give us a bit tighter integration with our ERP.  And assuming we can achieve the required up-time on the ERP to make this happen, then it will make my life easier in terms of maintainability and supportability....but, I'm not sure we will (and that's a post for a different day.)  For now, we're going in this direction so we had to figure out a way to get there in small steps.  We had a couple options:

Transition option 1

Transition option 2

Ok, by now you realize the choice here is pretty much a no-brainer.  We have to create a new client in either case.  However, with option 2 we have to shard the business logic into two different sets, each to drive that portion of the ecommerce experience.  Despite the diagram, this isn't as clean a cut as an architect might hope so buried in this challenge is the need to deal with things like, If the business logic for controlling the catalog is on the presentation side how do I validate that a user's cart has rights to purchase the products in his cart?  There a trust factor we could work out, but no solution there is going to be as tamper-proof as sharing the logic across both layers.

The Bottom Line

You need to take small steps to get there from here, especially when dealing with short timelines as we are with our project.  And even if the solution is obvious, it's worth taking time to think about and document them-- even in an agile environment.  It's just not reasonable to ask marketers to hold off driving sales until developers figure out how to switch out the ecommerce platform completely. So the value of transition architectures (at least for me) lies primarily in having a way to break up a large project into smaller pieces to mitigate risk while still delivering incremental success and value for the business.