BT

Experiences from Enterprise Integration with REST

by Jan Stenberg on Nov 28, 2013 |

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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT