Legacy systems still form the backbone of many enterprises. Yet as the demand for efficiency, scale, reliability and agility grow larger, we’ve seen an evolution in these underlying technologies to meet those needs. Let’s explore some of these technologies, their history and their evolution to see why such a change was inevitable. Because in today’s digital economy, organizations need to drive at a very different speed than was previously acceptable and embrace change in their competitive landscape and products. Service-Oriented Architecture to the Rescue

Legacy systems, which are the mainstay of many enterprises, weren’t developed to support the implementation and adoption of new technologies and growing economies working at breakneck speed. Consequently, as the number of digital transformation initiatives increases and the speed of expected delivery intensifies, IT leaders become overwhelmed by the sheer number of requests across the systems. Moreover, existing legacy interfaces, developed in a world of daily batch calls, are not fit for purpose for today’s digital channels that require real-time data. 

Enter service-oriented architecture (SOA), with its promise of speeding up project delivery, increasing IT agility and scalability and reduce integration costs. Gartner analyst Roy Schulte defined service-oriented architecture in 1996 as follows:

“A service-oriented architecture is a style of multi-tier computing that helps organizations share logic and data among multiple applications and usage modes.”

The goal of SOA is to create independent services that represent a single business activity with a specified outcome, that is self-contained and can be consumed by others irrespective of its implementation details based on the exposed interface. However, as SOA was adopted by organizations across the world, SOA governance requirements, large scale ESB integrations, and a need for large service registries made the implementations heavy and monolithic.  

The original promise of SOA was to speed up project delivery, increase agility and reduce costs. However, SOA adopters found that it increased complexity and introduced bottlenecks. Although teams were able to create faster connections, they also needed to maintain a large ESB implementation which slowed down time to production and didn’t provide a reasonable return on investment.

Microservices are in fact, the next step in the evolution of service-oriented architectures. A microservice is:

• Functionally Scoped: Microservices design is based on services and applications that accomplish one narrowly defined business function. A microservice need not necessarily be small, its size depends upon the complexity of the business function it accomplishes. However, it will be smaller than an application that contains its functionality as well as other business functions.
• Autonomous: As essential element of a microservice is that it should be autonomous. That is, it should be able to function on its own and without the need for other services. Other services might be layered on top of it (such as a service that handles user authentication), but it performs its business function independently. It can be developed and tested independently, and it can be deployed independently. 

More than anything else, a microservices design forces us to rethink the way we plan projects and lead teams. It affects how we think of deliverables, application lifecycles and time to production. It is amenable to a DevSecOps based approach which is founded in amalgamated scrum teams with a focus on automation, speed and agility. In some ways it is akin to the change in thinking that came with assembly line production and Lean philosophies that revolutionized the manufacturing industry in the early 20^th century. Some of the benefits of using a microservice-based architecture are:

Speed — Since a microservice is an autonomous unit, independent scrum teams can develop, test and put it into production irrespective of other parts. Each new unit provides a critical and unique functionality but no one single unit prevents the whole from functioning. Hence services can be created and deployed to production in small sized scrum teams. 

Agility — An agile environment succeeds on small units which can be built in scrum teams of six to eight, tested and added to the release pipeline. Microservices not only just work, but thrive in an agile environment and promote quick, faster releases of independent units that can be promoted to production as autonomous units. 

Flexibility — The autonomy and lack of dependencies in microservices provides a number of advantages: teams are able to use the language and tools that best fit the problem, they can test, build and deploy functionality without being impeded by other teams and services, and the code base each team must manage is considerably smaller and simpler. They provide the flexibility to try out a new technology stack on an individual service as needed. There won’t be as many dependency concerns and rolling back changes becomes much easier. With less code in play, there is more flexibility.

And last but not least, Simplicity — Microservices provide us with the smallest productivity unit in a complex ecosystem of IT services within any organization — like the cells with the complex human body. It forces organizations to think of their simplest business function and smallest unit of work. In addition, rather than working on an element of a project that is centrally managed, each team working within the context of a microservices architecture is free to innovate within the context of a simple business function, promoting innovation and risk taking which does not affect the entire organization.

Thinking about and designing our applications in terms of small independent units is the first step towards building a modern infrastructure that is nimble, agile and scalable. While there will still be technical debt as teams balance timelines and design, it easier to pay down that debt. In fact, as organizations evolve and modify their requirements, IT departments can work alongside them in replacing services rather than maintaining them.

About the Author

Geetika Tandon is a senior director at Booz Allen Hamilton, a management and technology consulting firm. She was born in Delhi, India, holds a Bachelors in architecture from Delhi University, a Masters in architecture from the University of Southern California and a Masters in computer science from the University of California Santa Barbara.

The post From Service-Oriented Architecture to Microservices appeared first on Artificial Intelligence.

Service Oriented Architecture (SOA) was the great hope of organizations decades ago when they sought to advance legacy system integration, reduce and bypass layers, and rapidly access the system of record. At the time, the existing solution was point-to-point integration, creating a brittle “spaghetti” middle layer that was hard to manage. This was replaced by SOA, which was later augmented with ESB. This fixed the spaghetti mess by creating an intermediate set of layers, which added complexity to the integration process.

Unfortunately, most IT departments with legacy systems and SOA still struggle to be as agile as needed in this ever-increasing global and digitized world. 

SOA Solved Many Problems, But Not All

Today, upward of 90% of the world’s enterprise applications are monolithic. When they were created, monolithic design was the best approach available. However, as business needs evolved and the demand for greater agility intensified, developers and IT teams are considering breaking free of these monolithic architectures.

SOAs have become a hindrance, not the solution they once were.

The SOA Integration Challenge

The promise of SOA initiatives was extending the reach of core business functions while reducing the internal expenses and complexity that grew alongside monoliths. SOAs achieved these goals by breaking the core functions of a monolith into web services using protocols such as simple object access protocol (SOAP) and eXtensible markup language (XML).

SOAP was built for universal application communications. Because it’s based on XML, SOAs designed with SOAP could, in theory, be used to create an agnostic integration layer. Rather than struggling to piece together various proprietary systems, these protocols would open monoliths on different operating systems so they could work together.

This agnostic integration layer would let system administrators connect pieces of a monolith to an enterprise service bus (ESB) to achieve an agile, plug-and-play SOA. In some cases, this approach succeeded.

A great deal of “legacy SOA” still provides value. In these cases, the value the SOA provides is the behind-the-scenes server-to-server communication that mostly aids developers. When it comes to serving internal and external customers–and their rapidly changing demands–SOA isn’t always up to the task.

To achieve service integration, the ESB must oversee the messages from start to destination. This communication isn’t as simple as the SOA vendors may have promised. Consider an SOA integration within a core banking application. The message must go from the core application on the mainframe to a branch office server. If the business logic states a message is only relevant for one business day, administrators must decide whether to move it to a queue, log or disregard when the day passes. This is a common scenario for core banking applications in an SOA, but how well does it work?

In this example–and others like it–the ESB must know whether a business day has passed to make the right decision about where to send the message. Therefore, the integration requires an algorithm–meaning that ESB cannot simply rely on a universal rule for sending messages between the monolith and external integration.

When administrators introduce new business logic into the monolith integration, it turns what was supposed to be an agnostic service layer into a new application layer, increasing complexity. Instead of simply integrating the monolith into a new digital service, the enterprise ends up with a larger monolith–one that includes the mainframe and all the new integration stacks.

Despite the promises of SOA, the integration problems result in increased maintenance time, greater complexity of code and software and the continued growth (not elimination) of monolithic applications.

The first rule of effective integration is “smart end-points and dumb pipes.” Building logic and layers into the service layer breaks that rule, increases the overall complexity and adds another legacy application to your portfolio.

Bottom line: Trying to optimize the SOA approach will only result in larger monoliths.

Improving SOAs with Microservices

Using microservice architectures helps realize the original promise of SOAs, delivering the benefits of SOAs while removing many disadvantages.

For decades, CIOs have tried to transition away from monoliths by taking traditional approaches to integration, only to find they’ve doubled down on legacy investments. All these integration stacks end up coupled to legacy systems and only result in more work for the IT team–and a less agile organization.

The integration step of SOA was never intended to include business logic. Trying to force business logic into this approach leads to workarounds and extra effort just to achieve a less-than-ideal result.

The key factor is how to incorporate microservices without adverse effects. Luckily, microservices architecture can be forged from SOAs by introducing these new principles:

•   Context Mapping: When replacing an existing SOA, teams must consider the size and scope of the new microservice and apply proper contextual boundaries. For example, SOAs that typically sought broad integration with digital services should be broken down into smaller domains to simplify operation.
•   Shared-Nothing Architecture: Too many SOA integrations create sprawling dependencies that create complexity in the tech stack. Microservices avoid these cross-service dependencies. For those looking to move to microservices from an existing SOA, it’s important to look at the list of dependencies and work toward standalone functionality.

The post Microservices: The Advantages of SOA Without Its Drawbacks appeared first on Artificial Intelligence.