When an IT Organization sets out to deliver a new product, functionality, or system against a set of business requirements, the top of the funnel begins with Enterprise Architecture (EA). The end of the funnel is the support organization that is ultimately responsible for deploying the production, functionality, or system that EA designed based on business requirements. An area that is frequently lost in the shuffle, which EA depends on for success, and vice versa, is Operations. More specifically, in 2020, most organizations are increasingly turning to Site Reliability Engineering as a way to implement DevOps practices in their operations organizations. The intersection of Site Reliability Engineering (SRE) and Enterprise Architecture (EA) are highly dependent on each other for the success of not just a given product but the success as defined by the business requirements that EA is accountable to meet.
The rise of SRE as a means to support operational environments is multi-faceted, including providing better visibility into an environment through SLIs, SLAs, and SLOs. Additionally, having a support team focused on automating toil and manual processes will inherently lead to more stable environments by limiting human interaction. However, organizations are frequently turning to SRE teams for supporting applications in production, which were either not designed or developed for resiliency. Development focused on resiliency, including leveraging PaaS to be OS-agnostic and using the Twelve-Factor methodology, are a few of the ways software development can shape the long-term success of support. Ultimately, the success of an SRE team begins with EA and specifically the framework leveraged by EA to develop and finally deliver applications.
The days of delivering only on business architecture, information architecture, infrastructure architecture, or systems architecture as the only output from EA are over
The days of delivering only on business architecture, information architecture, infrastructure architecture, or systems architecture as the only output from EA are over. There are several frameworks different organizations are leveraging for EA to try and find the right balance of delivering against business requirements while ensuring maximum frugality and flexibility in future architecture. EA functions ebb and flows over time, and many frameworks portend to be future proof solutions for designing systems. N-tier architecture, for example, seemed capable of scaling when it was introduced, but over time as data has become ubiquitous in companies, N-tier architecture has struggled to scale.
There is a truly forward-looking solution available to enterprises today. Event-Driven Architecture (EDA), a radical move away from the N-Tier architecture of yesterday, breaking large monolithic services into small, highly scalable services focused on singular functions offers a great deal of flexibility in what plugs into a system moving forward. In previous iterations of EA and systems development swapping out the way that a retailer processes payments were previously an entire technology transformation. EDA also allows for asynchronous processing of transactions, an ideal model for high volume systems such as retailer transactions where payment may be a prerequisite to fulfilling an order.
EDA enables many services to be dependent on another service executing a task, without needing to know the details of what was executed. One common way that EDA is implemented is in a publish/subscription model where the service which creates an event is publishing while those services receiving the event are the subscribers. This publish/subscription model provides a way for services to be developed, which may publish without concern or dependencies on the subscribing services. Additionally, EDA allows for a queueing model whereby an application has a queue to take a message then take action based on receipt of the message off of the queue. This model enables several reliability advantages, including potentially recovering lost data and providing on-time delivery of a message from a service. The flexibility of either a publish/subscribe, or a queueing model is further justification for implementing EDA in your next product.
An Operation organization in support of business requirements with DevOps and SRE will find EDA is a model that fits a perfect balance to ensure a seamless transition from EA through deployment and ultimately through support. SRE organizations are focused on providing key insights into the performance of their services from the business process down to the infrastructure. EDA allows development teams to build small services which can be instrumented for very granular monitoring and tracking of performance in line with expectations of an SRE.
Another concern of SRE organizations is ensuring failures inside or outside of deployments, do not cause catastrophic failure to their systems. EDA necessitates multiple small services to make up a broader function or application; the inherent nature of small services is that their failure makes diagnosis and resolution of issues exponentially faster. Furthermore, EDA enables work in small batches, which is another key tenant of SRE.
Selecting an EA framework for your next development product is critical to the success of the delivery of the product. Choosing a framework, such as EDA, may be the difference in your product having a shelf life that is measured in years versus having a shelf life that may be decades and far exceed the current requirements of the business.