As enterprise IT seeks greater speed and agility through the adoption of a microservice architecture, they find this new paradigm can collide with long-established operating models.
To reconcile the conflict, enterprises will often apply legacy thinking to a modern problem, which ultimately decelerates innovation. This second post in my microservices blog series details how organizations can begin to innovate at the outset of their microservices journey by maintaining a focus on business priorities and learning from early adopters.
Picking the right destination
Early adopters often look at new technologies through the eyes of a scientist: asking questions, researching, experimenting. But given the demand for new experiences from the business isn’t slowing, many well-intentioned projects in IT often go from research directly to conclusions, skipping the construction of a hypothesis and its tests altogether. As Mary Poppendieck aptly stated, “The biggest cause of failure in software-intensive systems is not technical failure; it’s building the wrong thing.” We speed past gaining general agreement and the enablement phases of the scientific method, and before anyone realizes it, the train has left the station, leaving business stakeholders standing on the platform with nobody quite certain where IT is going. The odds of derailment are high.
Observing that microservices initiatives are as much about an organizational transformation as they are about the resulting technical artifacts helps keep microservices programs on track. Top-level business goals and associated principles can help guide decision making.
2 ways to leave the station
In a technology and business partnership, as IT is helping to transform the business, it stands to reason that the business should help transform IT as well. Looking at IT as a business is often a challenge; IT is usually seen as a cost center, after all. However, if we look to some long-established models to inform the process of transforming IT and use this initiative as the catalyst, we will be much better positioned for success.
The franchise business model
Look at McDonald’s, for example – its ability to scale is a function of the franchise business model. McDonald’s offers centralized services (a recipe, marketing, brand, distribution, etc.) and allows the franchisee to grow its businesses by catering to regional and local tastes. I never really appreciated this fact until I bought a burger at a McDonald’s outside of New York and discovered that it had mustard on it. Mustard in New York on a burger would be a crime! But it’s the ability to customize (Freedom Within a Framework) outside of central services and at the edges of the business that allows McDonald’s franchisees to prosper. If IT could adopt that model – offering shared services to their business partners that bootstrap innovation, allowing others outside of core IT to innovate and create experiences their customers want – the ability to close the IT delivery gap increases.
The platform business model
We don’t have to go far to look for examples of businesses using platforms to disrupt their industries when phrases like the “Amazonification of retail” are part of common vernacular. But how does that apply to IT? Consider Apple – Apple uses its platform (iTunes) to allow developers to create and scale experiences (apps). Apple packaged an elegant set of technologies in the iPod, but without having “an app for that” developed outside of the Apple Core (see what I did there?), it’s arguable that Apple wouldn’t be one of the most valuable companies on the planet today. Can IT today learn from this model and apply those same principles as well?
Guide rails that bootstrap innovation
The franchise and platform business models help define a path to success, but aligning the technology to those models is equally as important. Again, we don’t have to invent everything, we can look at other successes to help instruct our own activities.
The World Wide Web has a few rules (or guide rails) that bootstrap innovation. Like a platform, the web offers shared services that provide a level of resiliency, stability, security, and scalability, and (as long as one stays within a limited number of constraints such as a protocol, transport, etc.) anyone may add or remove nodes or experiences under their control to the web without permission (like a franchise serving a local market). The architecture of the web changes over time, but consistent contracts and constraints allow anyone to innovate and push the boundaries of the experiences we’re afforded.
The web isn’t built in a series of microservices, per se, but it is an example of 1) democratizing innovation as a franchise and 2) of a platform. The platform provides services and empowers and encourages innovation by those who are closest to their customers and understand the products that are compelling to buyers.
The open railway: MuleSoft’s approach to microservices
MuleSoft’s API-led connectivity approach exemplifies the creative consumer phenomenon and is entirely complementary to this model of innovation. API-led connectivity offers enterprises the opportunity to realize this acceleration via a new IT operating model, and it empowers citizen developers and integrators to enjoy new technological freedoms in the enterprise. The API-led connectivity approach has already been proven to democratize innovation in organizations through reuse by leveraging a platform and approach to deliver experiences at the edge.
MuleSoft’s approach to microservices is the only commercially viable solution on the market that balances the needs of the microservice development ecosystem with the democratization of innovation at the edge.
My next post in this blog series provides further historical context and digs into the “why” and the “how” of microservices. For more on choosing the right architecture for your organization, read our top six microservices patterns whitepaper.
Matt McLarty contributed to this post.
