There was a time when enterprise architects fought for recognition and support, but that time is passing. Most...
enterprises now recognize that achieving agility and efficiency in business processes demands uniting business goals, human resources and information technology.
EA roles have broadened, changing from focusing on mapping business processes in abstract to mapping work, workflows and worker productivity. An important step is to introduce software architecture design into EA, and to do that, recognize that the critical element in software architecture evolution is the shift away from the workflow concept, introduce event-driven concepts into your EA plan, map events to IT services by domain and map IT services to software architecture, practices and products.
In classic EA methodologies, architects focus on business processes as the endgame of their modeling. This approach has mapped well to service-oriented architectures, service busses and workflow processing -- all mainstays of software architecture design until very recently. The introduction of the Internet and cloud computing has eroded support for the "workflow" vision of IT. Today, the preferred approach is to think of software as a collection of microservices assembled ad hoc to serve the production needs of every worker. With this software model, the driver of software activation isn't linear flow, but events.
While the disconnect between the conception of "business processes" as being "business process flows" and event architecture -- or microservices architecture -- seems obvious, it's not being adequately reflected in most enterprise architecture methodologies. The business process output of EA is often prestructured into business process flows and leans toward workflow thinking when translating EA requirements to IT requirements. It is possible to "retroject" an understanding of modern software architecture evolution and design approaches based on the cloud and microservices into today's EA methodologies, but this is difficult to do in a consistent and organized way. To do this, developers need to reject the notion of business processes as the endgame for EA, and focus instead on business events.
Understanding business events
Businesses are already logically transaction-driven, meaning they respond to things from the outside, such as orders, and generate other things to drive partner activity, like shipping advices. These things are business events, and they're the common driver of all business activity, and as such, they are a logical EA focus. But today's EA is more likely to describe the process than the event, and that process description can be what ties EA to a potentially obsolete software architecture design.
A business event is a driver of the business or an output of one business to another, described by what it represents in business terms and not what's done with it. It is the starting point not for an event tree, rather than a straightforward flow. Each event or transaction spawns a series of required internal events and transactions. An order, for example, might generate a "check inventory" event and a "check credit" event. These can be represented as branches from the original event, and unlike traditional EA flows that often describe the order of things in sequence, event trees focus only on the key relationships.
A business visualized as a "forest" of event trees can provide useful insights into software architecture design. For example, many primary events will naturally spawn a set of related secondary events -- credit checks, customer order management and even CRM are all related secondary events. These related events form domains at a business-function level, and can, in turn, be the connection point between solidified enterprise architecture and software architecture. Event-driven EA frees the architecture from workflow dependence, and the domains establish a link between independent event analysis and software approaches.
Dividing domain responsibilities
Most domain-related EA discussions focus on a different kind of domain -- for example, security, information, IT infrastructure and networking -- and many organizations will have these domains represented on the IT side. This means binding EA and software architecture is a union of functional and structural IT domains. The functional domain experts should reside beneath the EA organization, subject to the prime overall EA, and the structural domain experts should be part of the IT organization itself.
The sum of the functional domain requirements should dictate the broad model for software architecture design -- a model to be selected by structural domain experts. In most cases, there will be a broad architecture selected for the software, including some tuning and function-specific mapping for each of the functional domains. This means the software architecture design can be visualized as a collective "domains of both types" meeting that sets the overall framework, which would be followed by meetings between each functional domain expert and the structural domain experts to solidify the design. After a final team review, the final step of domain mapping then has to be translated to software design and technology selections.
Picking your processes
Evolution from the current IT model can be accommodated in this approach in a variety of ways. One is to let the domain experts guide the process by examining the difference between the legacy IT approach and the new strategy. Since your original EA work probably ended with business processes, these processes can be considered functional domains, and structural domain experts could then align the steps to the new approach for each of the functional domains. This works best when the event trees created earlier have minimal crossings between the old business process terminations of your EA model.
Where the new EA model will transform IT into a set of broadly distributed services, the best approach is to look at each of the old EA business processes to find the ones that can be mapped most easily to the new event trees. That means finding processes that contain a simple set of events. These processes can be transformed to an event-driven model, and the results will then build an inventory of services that can be used to select subsequent EA business process targets.
The most critical requirement of this software architecture evolution is to not get trapped in the past. The impact of software architecture design on EA is earth-shattering, because it changes the tools workers can exploit. The flexibility of the event-and-service approach depends on decoupling current IT processes -- not inadvertently perpetuating them.
Why you need to determine your complex event processing architecture bias
Do you need a microservice architecture for mobile?
Are microservices more like SOA or MVC architecture?