Using DevOps to help increase Systems of Engagement

What Is DevOps needed for Systems of Engagement?

Making any kind of change in business is often hard and typically requires an investment. Anytime an organization adopts any kind of new technology, methodology, or approach, that adoption ought to be driven by a business need. To build a business case for adopting DevOps, one must understand the business need for it, which includes the challenges that it addresses.

The Business Need

Organizations strive to create innovative applications or services to solve business problems. This might be either to address internal business needs or provide services that reach out to their clients or end users. A majority of the organizations have challenges undertaking software projects successfully, and their failures are often associated with challenges in software development and delivery. Though the majority of enterprises consider software development and delivery are critical a tiny percent feel that their teams are effective. This execution gap leads to missed business opportunities.

This problem has been further amplified by a significant shift in the kinds of applications that businesses are expected to deliver, from systems of record to systems of engagement:

Systems of record:

Conventional software applications are often large systems that function as systems of record, which include things like massive amounts of data and/or transactions and are intended to be highly reliable and stable. As these applications don’t need to change often, organizations will often meet the needs of their customers and their own business needs by delivering only one or two significant new releases a year.

Systems of engagement:

With the advent of mobile communications and the maturity of web applications, systems of record are being supplemented by systems of engagement, which customers can access directly and use to interact with the business. Such applications must be easy to use, high performing, and capable of rapid change to address customers’ changing behavior and evolving market forces.

Because systems of engagement are utilized directly by customers, they demand intense focus on user experience, speed of delivery, and agility – in other words, a DevOps approach.

Systems of engagement aren’t isolated islands and are often tied to systems of record, so rapid changes to systems of engagement bring about changes to systems of record. Any kind of system that needs rapid delivery of innovation requires DevOps. Such innovation is driven primarily by emerging technology trends such as cloud computing, mobile applications, Big Data, and social media, which may affect all types of systems.

Recognizing the Business Value

DevOps applies agile and lean principles across the entire software supply chain. It enables a business to maximize the speed of its delivery of a product or service, from initial idea to production release to customer feedback to enhancements based on that feedback.

Because DevOps improves the way that a business delivers value to its customers, suppliers, and partners, it’s an essential business process, not just an IT capability.

DevOps provides significant return on investment in three areas:

  • Enhanced customer experience
  • Increased capacity to innovate
  • Faster time to value

In conclusion, DevOps helps deliver better systems of engagement and help business reach their customers by adapting to their changing behavior and keep them engaged

Service Oriented Architecture vs Microservices Architecture

What is Service Oriented Architecture (SOA)?

​Service Oriented Architecture (SOA) which is a software structuring principle, the premise is that software systems are built around the concept of services these can be consumed by applications that can be independently be built around these services. Service providers published a service description that is available for consumers, consumers are able to interact with these using these descriptions (for example WSDL).

In a nutshell the goal of SOA is to decouple systems by allowing the service and client to evolve independently. By following proper versioning Services can provide newer capabilites for clients while supporting legacy clients to be operational and upgrade their capabilities based on their schedules. The follows are the attributes that SOA services adhere to

  • Boundaries are explicit
  • Service compatibility is based on policy
  • Services are autonomous
  • Services share schema and contract

SOA or Tiered Architecture

Microservices Architecture (MSA)

While SOA defines traits that Services need to adhere to the definition for Microservices are not well defined. Microservices are an evolution of SOA with the aim or creating modular services, the primary goal of Mircroservices are to evolve independently with a single application focus. An application can be composed of 100’s of Microservices, each driving an independent feature that allow them to be built on different platforms and deployed independently. Scalability is improved by allowing services to span multiple instances if the demand increases along with fault tolerance as a single service not loading will not cause the application to fail.

Microservices have gained in popularity with teams adopting Continuous Integration and Continuous Delivery, using rapid deployment techniques an application have 100’s or Microservices can have multiple deployments during the day. This is a big shift from SOA where large scale deployments were prevalent. The downsides of Microservices are that though they can be easily scaled they do have drawbacks as an in-memory function call is always less resource intensive than out-of-process component requests.

Microservice Architecture

Conclusion

SOA came about to decouple monolith applications and help usage of contracts to drive application development. This brought about the use of WSDL as a service description along with communication protocols that were standardized. This allowed for client to consume the service and also evolve at their own pace. The downsides for SOA were that deployments took longer as the size of the services grew and with a larger footprint scalability had challenges. Enter Microservices which takes advantage of the Continuous Integration and Continuous Delivery pipelines and also since they are feature focused can be scaled easier and also more fault tolerant.

Microservices vs SOA

See also

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview-microservices