Event based processing and capability architecture
Blog: Achieving Business Outcome With Enterprise Architecture
The illusions of process architectures
Most of the time people expect that a process is a linear execution of activities that has been predetermined, some people call this the happy path (top illustration) and expect that this is the way things should work. On other occasions people realize that processing is a bit more complex and adds in what they see as the alternative routes a process can take (middle illustration). These two views of processing is how almost all process architectures are expressed. In reality though processing from a business perspective is a jumble of alternative paths (bottom illustration) and it’s all but impossible to know before hand what the process would look like.
Sisney (2012, l. 1406) writes that `adaptation to the environment is supreme and fitness or capability is always secondary´. This fits well with my view on the notion of dynamic processing and agile businesses.
Bloomberg (2013, p. 101) writes that `the end results are dynamic processes that have no predetermined flow. Instead, the people involved in the process begin with the goal for the process and then the technology supports the interactions among the people in order to achieve the goal´. This fits well with my assumption about processing as only dynamic activities that have no predetermined flow.
The traditional process view on a business solution architecture
This is the way most process views are expressed and it sucks. It sucks because it forces the business to become stale. It sucks because it forces the information systems into rigidity and complexity. After a couple of months or years people find new ways of working and there will be variations to the services offered. At that time it will become increasingly difficult to make changes in the systems and the business will suffer. The lead time from idea to realization will be longer and longer and complexity will increase until the system collapses under its own weight.
However it is not all bad with the traditional way of doing process architectures. Considering the fact that the same activities could be activated in the same order repeatedly we would leave tracks in our logs. Those tracks we could refer to as processes. By stitching those processes together we could use them as generic processing patterns, which would enhance our understanding of the overall behavior. From a systems execution standpoint tracks would enable us to reach higher performance, since we would not have to start from scratch all the time.
Agile processing view on a business solution architecture
Richards (2015) writes that `Claims processing is a very complicated process. Each state has different rules and regulations for what is and isn’t allowed in an insurance claim. For example, some states allow free windshield replacement if your windshield is damaged by a rock, whereas other states do not. This creates an almost infinite set of conditions for a standard claims process´. The complications on process variations that Mark bring to light in his book is one reason why going to a capability based microservice architecture is the right thing to do for many information systems.
The processing dimension depicted in the illustration below is to be considered as a generic processing pattern. If you where to interview a business expert this is how you like them to describe their work. Knowing this we could start asking the business expert for each activity what it really is they would like to achieve by performing that particular activity. The result from such an inquiry would be activity goals, these goals we could express in the architecture as activity events. If we did this transformation from activity goals to events we lay the foundation for freedom in processing and retain the ability to continue our conversation with the business experts.
The illustration above is a good representation of how I would recommend expressing parts of a business solution architecture. This way ensures that the architecture is future-proofed for the business and at the same time able to realize the promise of agility and scalability through digitization.
The event hierarchy is the foundation for dynamic processing
Events map naturally to capabilities and activities which gives us the guidance needed to allow the users infinite ways of executing a generic processing pattern. If we then choose to implement this business solution architecture as an event based software architecture we can support the users no matter how they choose to work as long as they satisfy the goals in the activity events.
The Elements of an event based goal model
- The Market Events serve as a reflection of the goal a customer seek from interacting with the business.
- The Business Events serve as a reflection of the goal a business seek from interacting with the customer.
- The Activity Events serve as a reflection of the goal a role seek from interacting within the servicing of a business event.
- The Transaction Events serve as a reflection of the goal an actor seek from interacting within the servicing of an activity event.
When you should use this
- When business requires future-proofing the support they get from information systems
- When you consider moving to an agile enterprise architecture
- When you are set to create a microservice architecture
What you should consider when you view this
- This is not “the complete, nor may it be the correct” views of any specific insurance company architecture
- Continuously refine your events as you go down the capability hierarchy
- When naming events think of each event as the goal to be achieved
- In the end it’s all about just doing it
Related
- Capability architecture and microservices (local link)
- The Capability Canvas (local link)
- The Capability Inventory (local link)
Reference list
- Sisney, L. (2012). Organizational Physics | The Science of Growing a Business.:.
- Bloomberg, J (2013). The Agile Architecture Revolution: How Cloud Computing, REST-Based SOA, and Mobile Computing Are Changing Enterprise IT.:.
- Richards, M. (2015). Software Architecture Patterns. Retrieved from http://www.oreilly.com/programming/free/files/software-architecture-patterns.pdf
Download note:
I’m currently in a process of changing my presentation design (the images shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.
Post change log
2015-07-10: Published initial post
Leave a Comment
You must be logged in to post a comment.
