Large-scale legacy replacement is the hardest job in the IT industry, Brandon Byars, a principal consultant at Thoughtworks, claims when sharing his experiences from using RESTful integration in large scale legacy replacement projects.
Brandon consider REST over HTTP to be an attractive option for many of these projects; it is simple to use and understand, and requires no large frameworks. Architecturally he believes that REST has proven to be scalable as well as fit in well with domain modelling. Too often though he finds the discussions on REST to be about small details instead of aspects as deployment and testing strategies which he consider to be more important in ensuring success in his projects.
Brandon's first advice is to use logical environments during development to satisfy the needs for different teams and roles:
A logical environment is an appropriately isolated set of interrelated applications, services, and infrastructural components needed to satisfy a business or development need.
He then describes different techniques he has found valuable working with and maintaining a large number of these environments. One thing he argues against is versioning of environments, which he thinks can complicate working with a system significantly.
Brandon's experience is that poorly defined data boundaries are one of the most expensive mistakes an architect can make. A common anti-pattern is storing all information about an entity in a single data store, and export as needed, a strategy he believes is encouraged by a superficial misunderstanding of master data management (MDM). Instead his solution is to wrap each team's definition inside a bounded context, a concept from Domain Driven Design, DDD, within which a term means the same thing whenever it is used.
Each business unit has a different model for common entities with explicit translation between their bounded contexts
When working in distributed systems Brandon recommends grouping user stories for high level features into epics and to use these epics for measuring progress. That avoids a scenario with a false sense of progress; most stories are completed showing the teams are delivering, but the few stories missing prevent demonstration of the feature.
Program-level metrics keep epics as the principal metric for tracking velocity, as team user-story velocity can give a false sense of progress.
Brandon ends by emphasizing that although he is for a strategy using RESTful services, believing that it facilitates a simpler development, REST is far from a silver bullet.