Containerized Microservices require new monitoring. Read the eBook that explores why a new APM approach is needed to even see containerized applications.

The stage is set for companies to reach a new level of productivity and digital evolution. Small and autonomous is winning over large and centralized. Automation, DevOps, and microservices done together in the right way allow business units and IT to work together as a team again.

Entering the Faster-Than-Competition Digital Evolution

The benefit will be significant for the companies that succeed - and life will be harder for their competition. The good thing is that it can be an easy transition, and all parties will understand business objectives as well as architecture.

But it can also go very wrong. It requires a coordinated effort between various function within a company, it requires a new functional view on architecture, it requires (Biz)DevOps and good automation, and all of this must be done with business-IT alignment as the ultimate driver.

When all four areas are done together, in the right way, it releases the full potential of organizations:

When business lines own their own (Biz)DevOps teams and (Biz)Microservices, they can evolve quickly and autonomously, controlling investment against value, and innovating easily.

When (Biz)DevOps teams align with the business organization, they are stable over time, they constantly help with innovation, and they digitize their own processes for productivity and stability.

When (Biz)Microservices, which are functionally oriented components, each fulfill a business function, it allows for the maximum probability that new features only affect one single component.

The long-term relations between the business and (Biz)DevOps allow DevOps teams to understand the business they support, releasing the brilliant area where technical expertise meets business acumen and new ground is broken. It's time for CIOs, architects, developers, and business teams to take the next steps together!

Even if all four areas seem obvious, it is not easy to let go of history, and doing all four together can stretch thin the organization, teams, management, architecture and development. Many organizations only do parts of these measures - or do them in a non-coherent way.

For some examples: DevOps with N-tier architecture, monoliths or COTS will not make teams autonomous. CI/CD automation without DevOps teams and functional Microservices is a developer's exercise, producing code more quickly, but missing the business alignment.

Microservices Are Much More Than Architecture

To get DevOps teams to work with the business, we need to build functional microservices that work the way the business works as the default option. These microservices have business names like "Shipping", "Inventory", "Returns", and "Quotation". Data flows through the architecture as if microservices were actors in the process.

Business stakeholders, developers, and architects will work together on architecture. Business objectives, delivery, and operability are as important as regular architectural concerns.

The result should be:

Architecture will be understandable by business-oriented people.

Maximized probability that a new feature touches only one microservice.

Amount of integration is low, and it requires few service calls to run.

Changes for business innovation will be easy.

Autonomy of business units, DevOps teams and microservices is so important that it often makes sense to build new functionality the way one wants it, rather than re-using older components or buying functionality. The size of microservices will then be according to what is good for the business, as long as it fits in one DevOps team.

Enterprise level microservice architectures will be organized as a hierarchy of "Systems" each built as one to ten microservices, all resembling the way the business works. It is time to make Conway's law from 1967 a good friend: "Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

The era of monoliths, common-off-the-shelf software, and SOA layers is being replaced by a business-like microservices architecture, where DevOps teams build, deploy, manage and improve reasonably sized, business-oriented microservices, that can stand alone, or be part of a larger "system" or "application".

The biggest threat to this healthy evolution is actually if people go too far, and decide that smaller is always better. Very small, technical microservices, focusing on size rather than function, will not generate business benefits and architecture will not align with business function. In this scenario, the productivity benefit will not materialize. The worst-case scenario is that dependencies will grow, making things worse than they already were.

(Biz)DevOps Breaks the Final Barriers

DevOps is being introduced by more and more organizations to create smaller empowered teams and to break down the borders between the Development and Operations departments.

Going from larger departments with conflicting goals, DevOps believes in autonomous, cross-functional teams where the team members share problems, solutions, and tools, to build not only good business microservices but also their own automatic regression testing and operational safety mechanisms.

The team is closely aligned with the business line it supports, it has an agile mindset, and it digitizes its own DevOps processes, specializing to the specific needs of the business unit's required microservices. This saves money, makes the architecture more stable, and makes people more happy and productive.

In the end, business people and DevOps teams solve problems together. Roles merge. Business lines start seeing IT investment as a profit-loss business strategy. DevOps teams innovate in a valuable way - because they know how the business works.

The strategy works because it starts and ends with ownership. Ownership makes cross-functional teams responsible and it aligns them with a business purpose.

Altogether, full business-IT alignment is possible with autonomous teams and components, when using cloud and automation to keep DevOps teams small and microservices significant.

Key Takeaway

It is worth taking an active interest in what microservices can do for your organization. It is much more than architecture; it's a mindset. Some architects may be reluctant to change for historical reasons - or they are afraid to lose control of decisions in their domain. But this is DevOps and it's about business alignment where problems and solutions are shared and decisions are made together. With DevOps, people will get involved with more than one task. So, decide on microservices with all parties in the room.

Automation in IT delivery continuously increases productivity step by step and changes how we look at what we build and how we maintain it.

(Biz)Microservices and (Biz)DevOps enable autonomous and smaller teams and components.

Business-IT alignment finally gives the business an IT vehicle to run on.

The Essence of Mendix Is Business-IT Alignment

Mendix provides a platform that, from the beginning, was built to make the business and IT work together. It is reflected everywhere in the platform, in the culture, and in the community:

Mendix makes microservices "out of the box" because from a one-click deployment there is a unified environment for data, logic, and UX that can serve any business purpose. It ensures that microservices communicate via explicit services rather than cross-service database queries.

Higher productivity (up to 10x), and high levels of automation means that less technical skills are needed (functional business developers) and smaller teams can build significant microservices.

This makes DevOps easier and promotes an agile mindset, where the business is easily involved and the full advantages of out-of-the-box cloud and a central high productivity platform are realized.

Governance, CI/CD, containerization, and monitoring are part of the platform, and automatic testing and quality management tools are available as add-ons.

Mendix's Five Architecture Recommendations

Embrace cloud and automation.

Aligns architecture with organization.

Balance reuse with autonomy.

Establish clear positioning, specialize for purpose.

Implement new governance, allow agile, be ready to change.

To find out more:

Martin Fowler and Sam Newman have an appealing functional view on microservices

Mendix offers workshops around Business alignment, DevOps, CI/CD, and microservices.

Coming soon: blogs on Business Alignment, DevOps, microservices, and automation.