I spend a lot of time consulting with some of the largest, and most complex, companies in the world. Interestingly they all seem to approach things in the same way.
They work in siloed teams, create tight coupling between applications and divergent experiences for their end users.
The result of this is:
- Interdependent release schedules reducing overall agility
- Increased QA overhead, validating changes across multiple applications
- Core back office system updates or changes become almost impossible, due to the knock on effects (e.g. change PIM from supplier A to supplier B has knock effects in both the website and partner portal)
- Frustrated developers and business stakeholders, as even minor changes take too long
- Difficulty getting a single view of the customer, as customer data and trends are spread across several systems, websites and analytics accounts
What is the alternative?
In my opinion we should always be working against API’s and web services. We should be creating loosely coupled application architectures, in which each piece of the puzzle can change and release independently of any other piece.
In this approach
- Each team can innovate quickly and therefore ultimately better serve the end user
- Systems are “hot swappable” with little/no impact on the public website
- API’s can be exposed to many systems (internal and external) to create consistent web experiences (mobile app reports user preferences that can be replicated on the desktop)
- Versioned API’s allow legacy systems to continue working whilst not limiting new initiatives
- Specialized development teams vs. enforced silos = happier developers
Most frequently I work with the SDL Web (SDL Tridion) Content Management System, which in recent releases has headed in this direction. It exposes Content Delivery as a Service (CDaaS) so it can be plugged into a web application with little dependency. CDaaS is a collection of micro-services which allow consumers to access content (and other SDL Web Content Delivery assets) via a set of RESTful web services.
Following writing the post, I was pointed to an article by Martin Fowler on a similar topic which is worth a read: http://martinfowler.com/bliki/BranchByAbstraction.html