There’s a lot of “alphabet soup” regarding Business EVENTS in technical literature:
· EDA - Event Driven Architecture
· EPC - Event-driven Process Chain
· ESP – Event Stream Processing
· CEP - Complex Event Processing
Also high level SERVICES in SOA (Service Oriented Architecture) are equivalent to the concept of Event processing. If you are in Information Systems you may already be familiar with some of these 3 letter acronyms that encompass the word event. My keen grasp of the obvious tells me that the common denominator of these acronyms is Event.
I did a Wikipedia definition search on “Event Driven Architecture” – EDA and it said: (EDA) is a software architecture pattern promoting the production, detection, consumption of, and reaction to events. Well, it can be used for software but - using Event Driven concepts is not just the domain of software. It’s also highly applicable to human as well as computer systems. It is the basis of an architecture though. Basically Event Driven means focusing on whomever or whatever is your customer.
I Googled the title of this article “Event Driven business” when I was putting it together and I got over 10 million hits, that was about four times as many hits as a year before. So Event concepts are finally mainstream or at least catching on. That’s really nice to see, as I have been teaching its importance for over three decades.
· Here’s an example of an Environmental Stimulus/Response system. This first example always reminds me of a faux par I committed while teaching a seminar at the US Bureau of Land Management, (I’ve conducted a lot of seminars at US government agencies – the larger the organization the more ripe they are for implementing and benefiting from Event-Driven concepts).When referring to Stimulus/Response systems in this particular seminar I said I’m not talking about a rock here - I’m talking about systems. One of my students spoke up and said “So you don’t think a rock is a stimulus response system? Go look at the Grand Canyon”. I thought “Oh dear what did I say?” Of course a rock is a stimulus/response system. Since that mistake I’ve included this example in my seminars. The event - A storm, produces the Stimulus rain, especially acid rain, and the Response, over time, can be something as significant as the Grand Canyon in Arizona.
· Here’s an example of a Biological Stimulus/Response system. A Hammer blow to the body is the Event; causing the Stimulus Pain and the body’s response being to remove the body part (and maybe some verbal response also).
· Here’s an example of an Organizational Stimulus/Response system.In the business world this is probably the one we are most interested in. The event is the customer wanting to buy our product or service; the Stimulus is an Order and the Response is an invoice and product going out.
The important thing to acknowledge here is each Stimulus arises from an EXTERNAL event, in other words from a business point of view we are most interested in satisfying the needs of our external customer. Here’s an example of an Organizational Stimulus/Response system. In the business world this is probably the one we are most interested in. The event is the customer wanting to buy our product or service; the Stimulus is an Order and the Response is an invoice and product going out. The important thing to acknowledge here is each Stimulus arises from an EXTERNAL event, in other words from a business point of view we are most interested in satisfying the needs of our external customer.
You’ve probably heard the phrase “Money makes the world go round”; actually I think Events make the world go around - certainly the world of business. Unless you are a bank, processing money is usually one sub-process of an event. In one process view, the world consists of a mass of things (Events) happening through time. We select the ones we are interested in. In my company, LCI, we’re interested in Events to do with teaching, consulting and selling books on the subject of Event-Driven concepts. That’s LCI’s context. Let me show five examples of different Events and their stimuli but within their specific context.
· If we looked at the context of a Pay-Per-Click COMPUTER TRACKING PROGRAMits stimulus from an Event in the external world may be a mouse click.
· If we looked at the context of one Department Operation in an organization, its stimulus may be an Inter Office Memo or partial Order Folder being received from another department. The sending department could be thought of as being external to the receiving department.
· If we looked at the context of one Computer Program or System we may find its stimulus is an Input Transaction triggering a portion of the code. That transaction could come from another system or an input device.
· For this talk, the context I’m most interested in is the Business or whole organization. It’s stimulus could be an Order or Request coming from a Customer. Remember my Bureau of Land Management example, well a customer isn’t always a human being. The external customer could be the land, with Smoke or an earthquake being valid stimuli. Now from a whole organization context, I tend to view the first three examples - the computer tracking program, the internal department and the computer system as probably responding to fragments of an event. So I’ve labeled them internal,
· Of course we can have an even greater context, such as the Global System, triggered by global stimuli. I really hope someone is taking care of this event response.
Depending on our context of study, these are all valid Events and their Stimuli, however most benefits are obtained by viewing events from an organization context, within which we tend to have control.
If I believe the first three examples on the previous slide were probably responding to fragments of an event, then what is an Event in the Business World? Remember my comments - Every organization selects a set of Events that it wishes to respond to from the external world and each organization usually responds to a similar category of events – banking, shipping, computers etc. The important words in that sentence are No Control. If we do have control over the event we’re probably not at the edge of our business and we’re looking at an internal fragment of the business. Or we may be looking at a System Event and not a Business Event. More on this later. Each external need to which the organization responds is called an “Event.” From an organization’s point of view the first thing you see is the stimulus, not the event – that’s external. For example here’s a person thinking,
· I need to go to San Francisco…Which makes him contact an airline.
· I need some cash…Which makes him go to the bank or ATM.
· Its tax time…Which makes him send his tax documentation to the Government.
· I need to buy a briefcase…Which makes him purchase a product.
These are all external events to the organizations that are going to respond to them. If we focus in on this last event we may see more detail of the Order processing stimulated by the incoming Order to the organization. The Order may go through a whole bunch of departments, computer systems, databases and so on before it comes out as a Response. This example shows what I call an Event Partition of an Event – one initiated by the customer. In the business world the most important Events are initiated by whomever the organization calls its “Customer” or whatever is the main external source of its stimuli.
Let’s take a broader view for a minute and look at what we need to specify in the business world. If we take a disciplined approach to specifying the various aspects of an organization we need to capture and define many components. I tend to think of all the information we can capture about an organization as needing to be pigeon holed into an accessible location. Like a parts rack of Captured information. Actually in analysis we capture what’s known as Metadata – data about data. For example, a Data Element such as Customer name would be metadata its value or content, Jane Doe, would be data. I already stated that event driven concepts are applicable to very small all the way through very large organizations. For example when a start-up organization begins to grow there’s a distinct need to capture the procedures to train new staff and to make sure the procedures are carried out consistently, such as how to correctly process a Customer Order.
This was true for my company. When I started hiring more instructors and especially when I opened up another office I needed to get all the knowledge of what was needed to run my training and consulting business out of my head. I was amazed how much information I needed to capture even for my small business: Functional Processes/Procedures, Data Groupings with Relationships, States and their Transitions, Controls etc. Placing this information in a database was a good first step but I realized that I needed a structure - an architecture that could bring these separate sets of information together. You probably already know what I did – I used Events as a means to partition that documentation. I even get a little weird, in my latest book Managing Event Driven Organizations and recommend that managers should manage event compartments, not departments, but that’s another story.
If we want to be specific enough to hand this information over to someone else in a non redundant, easy to access form, with no misunderstanding, then we start to see why the building profession requires detailed blueprints up front when building a house. Unfortunately many organizations have grown without the equivalent of even a rudimentary blueprint to refer back to. So I believe Defining these components is important but how we organize and group them together is even more important.
Over the years of teaching this topic I’ve used various metaphors to put over the concept of events and their resulting event partitions. One that I’ve had some encouraging comments on is what I call the Three Tiered Cake. I want you to use your right side of your brain (use a picture) to conceptually view the make-up of what I call an Event Partition, as a cake. Each Event forms One Business Core of the cake. If an organization already has a mission statement, it will dictate the area in which to identify the Events that it wants to respond to, in other words its market. Most organizations take on a limited set of events so it isn’t a big task to create an Events List. I want you to think of each Event you satisfy for your customer as a core – a core business event. All we need to know, at this point is the Event Identification, its outside source, its stimulus and maybe a one liner description of what it is.
Next I want you to separate “What” you do to accomplish this event from “How” you accomplish it. I want you to imagine the next tier of the cake being the Events Policy Layer made up of business rules i.e. the Business Logic initiated by the Event; only the data, the processing and any controls associated with this one event - not the forms/screens, people or computers etc. The policy layer is where each organization gets to separate itself from its competition.
The last tier of the cake is the Technology Layer which identifies “How” the business policy is implemented. We wrap around the technology (people/computers and Hardware/Software) that we use, or would like to use, in the real world response to the event. The technology layer is where the customer interfaces with our organization.
If you’re new to analysis verses design thinking let me use a banking example for these last two layers. Suppose the external event is a “Customer wants to Withdraw funds from their Account”. The business processing logic might be “Does the customer have an account with us. Are the funds requested less than or equal to the funds in their account, if yes, issue funds to the customer and reduce account balance by withdrawal amount else reject withdrawal request. This logic can be implemented in design by a manual teller with slips of paper or an online system with screen displays. The technology layer is usually not unique to each event or even across different organizations. For example an Automated Teller Machine can be used for several event partitions and many banks utilize ATMs.)
Obviously your customer imagines that your goal will be to satisfy their needs seamlessly and efficiently. We wouldn’t want to slow down their request through our company; after all the organization depends on the customer to stay in business. So it would be a good idea to keep this set of information together with the Event, right through the new implementation. Remember we do this for each event. So in our simple banking example we would have many cakes – one structure per Event.
Let’s talk about an all-too-typical fragmentation of an event’s Implementation. Unfortunately, the typical organization has not maintained the “cohesiveness” of their Event Partitions and has allowed old departmental structures and haphazard systems development efforts to fragment a response to their customers. What appears to be very obvious in many organizations today, is our event cake has been sliced-up (partitioned) for very different reasons than around an event. In fact the predominant structure seems to be based on implementation reasons, in other words from the bottom of our event cake, up.
After my extensive career in information systems I don’t believe there are many functional systems out there – there are a lot of dysfunctional ones though, such as shown in these classical slices. You are probably used to these organizational slices - sales department, accounts department, stock control, order entry, order fulfillment, reporting, these are common boundaries for manual and computer systems. Fragmenting an Event Response in this way is known as “Stove Pipe” or “Silo” partitioning. One of my earlier books was on the subject of Reengineering back in the 80’s and we used the term silos and stove pipes for these structures in reengineering ideas. These boundaries slow down the response to your customer. I remember using this graphic, and the fundamental error in understanding business partitioning, at a conference talk I gave in Holland many years ago, before reengineering ideas became popular. When I’d finished speaking the host of the conference, who was about to retire after many years in the business world, came on stage and said to the audience “How could we have been so stupid”. I wanted to hug him. These old design slices do not represent a functional partitioning of a business. To me they are leftover aspects of implementation from the industrial age.
What I find interesting is when I started my company I implemented an event as a cohesive whole because I was the only employee. When a company called up for a seminar I took care of everything right there together, scheduling the seminar, boxing up the materials, shipping them out and of course teaching the seminar (albeit after a time delay). In many organizations the cohesive structure of an event partition seems to get corrupted as they grow. Maybe many old business schools promoted this old structure.
We need to be aware of the classical implementation groupings. So let’s take a closer look at some of those typical organizational slices. It’s all too common to see groupings of processes, data and controls into historical, industrial age patterns. It seems we get caught up perpetuating the last age and it takes a lot of time to break the pattern. In the agricultural age I’m pretty sure there wasn’t a forty hour week or an executive vice president in charge of the barn. And the information systems department was nonexistent. There was a more flexible or network structure in place governed more by seasons and weather. When the industrial age came along the flexible structure of the agricultural age didn’t work. Another structure was needed as the production line became important and people needed to be at the line with ridged time constraints. I’m sure you are familiar with Human system groupings: So a hierarchical structure became common - divisions, branches, department, jobs and tasks with a new management style to match.
In the information age we perpetuated those structures for a while with Computer system groupings. Of course that’s breaking down now with work-at-home and internet implementations. However we still seem to have some leftovers. If you look inside some computer systems you will often find a similarity to the manual partitioning. Why is that? Well I’ll pick on myself here, when I did real work for a living, as a computer analyst/programmer, my boss would say something like go to that dept and write a system to help it or go talk to Sally and write a program to help her with her job, she’s getting over loaded. Did you hear what I just said, “go to that dept” or study “Sally’s job” - my area of study was already bounded. So I perpetuated the department boundary into a computer system. Or I perpetuated Sally’s job into a computer program boundary. So what was the Basis for these historical groupings?
Obviously the original groupings were based on human skills. E.G. Accountants in Accounting, Sales people in Sales Dept, but please note: Historical groupings will perpetuate themselves (unless actively changed) and can become “hysterical” groupings, for example: Here’s some body in accounting that got his job because he has an accounting degree and has a lot of experience in the field. He’s overloaded with work, so a manager, of the old data processing department, in the 70’s, says we can automate this and help you do your job with a computer system. We’ll create a batch system and run it in the middle of the night. So now, I guess the batch computer system knows accounting logic and is experienced, just as the accountant was? No – wait a minute all computer programs can do accounting logic and the longer a computer system runs doesn’t mean it gets more experience. Oh well, the 80’s arrive and online technology gets cheaper. So the computer department says “We should put this online with an integrated network of PCs. But we don’t have a big budget so we’ll just convert the existing programs to online.” The 90’s arrive with a chance to bring in a new structure but we have a problem - Y2K. All resources get channeled into replacing the hardware and buying software packages to match the existing systems structure so there won’t be too much disruption. No radical new structures please. Great, the new millennium arrives- the internet takes off. Business managers take control of their own Information System needs. They say we gotta put our systems on the net. Now customers see strange messages like “error code 404” and “not on this server”. Next its “We gotta put this on the cloud.”
Now, replace this example with order entry, new accounts, scheduling and especially any accounting systems such as General Ledger, Accounts payable, Accounts receivable. All those groupings are fragmented event responses and are historical partitions from the industrial age. The moral don’t carry on the old partitions. So many computer systems followed the same grouping as the old manual systems.
How did we get into this hysterical situation? To me the biggest reason (next to budget issues, that is), is not being able to take ourselves out of the picture. So: One major problem of perpetuating historical groupings stems from not recognizing that humans, just like computers, are an aspect of technology, in other words an aspect of implementation. Implementation issues always get in the way of a good Analysis of organizations/departments systems etc. Let me prove this technology issue with my banking example: I know I can use online banking or an Automated Teller Machine to take care of most of my banking needs. I can also go to the Manual teller and take care of my banking needs. Well, if I can conduct my banking needs without an Automated Teller Machine (a computer system) or conduct the same banking needs without a Manual Teller (a human system) then human beings and computer systems must be aspects of technology/implementation - not essential business issues.
I mentioned budget issues: a student asked me years ago what I thought was the biggest impediment to implementing Event Driven concepts. I said the middle management budget. Let me use an example: Here’s Bill again, now he’s head of accounts; I say to Bill “This order form goes out of your area and comes back in with a check mark on it from Sally’s department. If I can just spend some time and follow it through her area I will probably find a way to get a faster response to this customer order”. What does Bill say? “That’s Sally area. You’re not studying Sally’s area on my budget. If Sally wants a system for her area she can budget for it or she can go buy a software package for her department”.
Unfortunately many old Information Systems people as well as Packaged Software Vendors perpetuated old boundaries when they “built systems for” - and “sold systems to” department managers. So if you ask can’t we just leave this up to the Information Systems people or just buy a software package from a vendor. Well maybe, it depends obviously on what methods they used to create the software. Remember the sellers of software usually aim their product at the department or middle manager. Information Systems (IS/IT) folks should build systems using Methodologies which recommend analyzing and seeing through these old designs. They should not use historical groupings for new specifications within a new Enterprise Architecture. I’ve always taught that designers of new systems should not just use the latest technology to mimic the old designs structures. That just creates faster bad systems.Using EVENTS to drive business partitioning allows us to see through these old/outdated groupings.
OK so how do we fix this situation? I can’t think an established profession that doesn’t have formal methods and models. If you’ve ever look at a house blueprint you’ll have notice that there is more than one diagram in the complete set. Each page of the blueprint contains a different view depending on what aspect of the house you are interested in. Such as the outside views of the house, the floor plan or the electrical plan etc. Likewise there are lots of models we can use to help us fully specify an organization. One discipline calls this an overall Enterprise Architecture. An Enterprise Architecture is a representation of ‘How you view your Business’. It utilizes distinct major specifications in order to capture all aspects of the enterprise/organization.Depending on how formal and specific we want to be in the specification of our business we can utilize a number of proven types of models. I teach some in my seminars but I want to state that I’m a believer in minimal, non redundant documentation. So if you are a small business person listening to this you could use a video camera to capture the current flow of an Event response through your business. Realizing that that would be a design oriented record, with a limited useful life, but never the less could show the tracking of each complete event partition through your organization. There are many ways to formally specify an enterprise:
· Business Process view - A Process Model
· Data Flow Diagrams or Workflow models are examples of process models.
· Business Information view - An Information Model
· Entity Relationship Diagrams or Data Models are examples of information models.
· A human Implementation Structure
· Company Hierarchy diagrams or Management Control Structures are examples.
And other models such as a Systems Application and Computer Technology structure. The Formal methods such as Process Analysis, Information Analysis, Object Analysis, that produce these models, already partition them by specific views –for example As Is/To Be or Old/New. I also recommend that each one of these views be based on the organization's Events.
I’m going to tell you about some event partitioned models, before I do I want to cover one important concept. I’ve already said, we should structure our organization around Events but it’s important to differentiate between the kinds of Events that occur in and around an organization. The following is important to me especially as I am proud of discovering this one. In my Business Process Analysis Seminar this concept takes me over an hour to clear. But as you’ve stayed with me to this point I’m not going to lose you by getting too detailed. So let me just do a brief description of the different types of Events you’re likely to see in any organization, just in case you are thinking that event-driven concepts don’t apply to your particular area of business. After working with the concept of Events for years I realized that there are five types (I call them flavors) and they’re not that difficult to categorize. The most important type is a Business Event.
· Business Events – are those to which an organization wishes to respond. These fulfill the organization’s mission. They always originate at whom or what is called a Customer. In a private business these are usually revenue generating. In government they are the ones that support laws.
· Dependent Events – are those to which an organization responds to be able to satisfy its Business Events. They usually come from vendors and suppliers and are created when part of a Business Event is outsourced. For example when I use a package delivery service such as FedEx to get my books to a seminar they will trigger me later with an invoice. That’s an incoming event stimulus for my organization. I could buy my own delivery truck or Lear jet and bring this part of the event back under my control, but that would be too expensive, so I outsource that task to FedEx. Notice though that they are now fulfilling one aspect of my business event. Note that any part of your event partition you outsource reflects on your organization so pick your vendors well.
· Regulatory Events – are those to which an organization is required to respond. They come from a government or business regulatory agency. For example, responding to your corporate fiscal year end. This could be a date range such as January 1st thru April 15th.
These first three are the most important for Business Process Management. Capturing these three kinds of Events enables the guarantee of what I call “data conservation” (No Dead or Unnecessary stored data) across the whole organization. Ensuring that any data created is used in at least one other Event – I’ll say more on this later. These first three also make up your true business model.
· System Events – are “invented” at design time to support the implementation of the above three types of events on your business model. These are the ones that make your business run in the real world. Remember the lowest level of the 3 part layered cake; that is where we introduce System Events. They are invented to support the implementation of human and computer systems. So if you are in Human Resources or anything to do with implementation technology e.g. purchasing computers for internal use then you are probably working with System Events. I usually say System Events are anything to do with “silicone” (i.e. computers) or “carbon” (i.e. human) based units”..
· Strategic Events – are those that dictate the contents of the organization’s policy. (These form what’s known as the Meta Model – the model of the model. Analogous to building rules/codes that dictate the creation of every blueprint – so they are the rules for creation or modification of the models.) These are the hardest ones to talk about in only a few seconds. They are the events that make you form or change your business itself. An example might be if a strategic planner sees the competition just lowered the price of the same product, that you also sell, then that may trigger you to change the price of your product. You may also go into a brand new line of business that makes you introduce new business policy. These are examples of strategic events that I recommend you document on a separate model.
Let me tell you about the beginnings of a business process model. Now every enterprise/organization has an Event Horizon (so does each business area, if you want to apply event driven concepts to an area smaller than the whole organization).At a high level we can conceptually view and model an organization as a ‘Black Box’ that responds to a set of external Events. Remember every organization relies on outside stimuli - if no one requests whatever product or service you provide, you’re out of business. We call this initial view an Organizational Context Diagram and accompany it with an Event list. So the first process model we want to produce is a simple, high level model that depicts our organization’s event horizon. This is the edge of our business over which the stimuli and responses of events cross. We just depict our organization as a black box. Then show each event’s Source, Stimulus and its resultant Response around this box.
For example, here’s a Business event; Customer wants to Order our Products, creating a Customer Order stimulus to us and resulting in an Ordered Product and Invoice response. Here’s another Business Event; Customer wants to pay our Invoice, creating a Customer Payment stimulus to us and resulting in a Customer Receipt response. Here’s another Business Event; Dividend Period Arrives, triggered by a Dividend Period control stimulus to us and resulting in a Profit and Loss Statement response sent to the Owner.
Here’s a Dependent Event; Supplier Delivers Material triggered by a Material Delivery stimulus to us and resulting in a Supplier Payment response back to the Supplier. Finally here’s a Regulatory Event; Tax Deadline Arrives triggered by the calendar Tax Deadline date and resulting in the Tax Reports being sent to the government.
When studying an organization we can use this Context Diagram and its Event stimuli as a guide to further analyze and partition the organization’s business model, as well as its specifications. So we can now take each event and follow its stimulus through the organization.
If we concentrate on one event at a time we can easily remove any fragmentation in the existing organization from our business model. To produce a view/model that is not corrupted by any old design characteristics we should concentrate on capturing details of six components for each Event. These components form an Event Partition. This will create the next level down from our Organization’s Context Diagram. As we want to analyze our organization before we get into any design issues, we need to remove any existing design aspects from the past (or even what we may put in place in the future). This is relatively easy if we concentrate on gathering six components for each event.
· The Source (initiator) of the Event. This is Whom, Where or What is the source of the event.
· The Stimulus resulting from the Event. This can be Data, Material or Control. A data stimulus might be Customer Order. As a material example, I did seminars for the US Park Service where Debris and fallen rocks on park land were stimuli to take action. A control stimulus might be “End of the Year” indicated by the calendar or a “Too cold” signal from a thermostat.
· The Processing initiated by the Event Stimulus. This is the business policy. If this is not a trivial event, this can be just a summary of the processing.
· The Memory used in the processing of the Event. This is any stored data or files needed to accomplish the processing.
· The Response generated by the Event. This can be Data, Products/Services accomplished or Controls.
· The Recipientof the Response to the Event. Whom, Where or What receives the output of the event.
I’ve found that every Event Partition will have a Source, Stimulus and associated Processing, however Stored Memory, outgoing Response(s) and Recipient(s) are optional. These are the 6 things we need to gather for each Event Partition. I call this view an Event Context Process Model as it forms the context of one event for any lower level decomposition. These six Event components form a functional, EVENT-DRIVEN, partitioned model – one level below the Organization’s Context Diagram. We can now use this Event Partition to develop lower levels of detail for complex events and therefore keep the cohesiveness of this event partition intact.
Let me now give you my formal definition of an Event Partition. An Event Partition consists of an End-To-End set of components required to completely satisfy one need of a Customer. That’s my definition of the result obtained from analyzing the complete reaction to one Event through the whole organization. I’ve used variations of that definition since the 80’s but there are also terms used in the technical literature for similar groupings such as: Use Cases/Swim lanes/Value Chains/Services.
We can break down complex Event Partitions (ones that can’t be summed up in one process) into more detail. Here’s an example of four Event Partitions. Three of them are at a lower level of decomposition than the single process Event Context Diagram shown previously. As stated before these Event Partitions are Functional from the customer’s point of view. I’ve shown these four event partitions on one model to make an important point about stored data. Notice in this diagram I’ve shown files only at the intersection of two or more Event partitions. In my Business Information Analysis seminar I say something that is quite powerful for anyone analyzing information. After having worked for years with the concept of Events I realized that the only time you need to store data (be it in a wire basket, a file cabinet or a database) is when 2 or more events need to share data. All other stores are what I call “Designer Files” invented to accommodate the existing design and they can be removed in the new design without any loss of data to the organization. I can’t give you much more than that in an overview video but remember files halt or at least slow down the flow of the customer stimulus through our organization. So the more designer files we can remove the more efficient our response will be to our customer.
It was nice to have taught hundreds of people at the package courier company Federal Express, they already acknowledged their main event stimulus – the package – and that any internal department boundary could slow it down. So the package was king and needed to be kept flowing as much as possible in implementation. It’s also worth noting that - As files are only needed at the intersection between Events these Event-Driven Partitions can be implemented as separate systems.
We can easily recognize “Dead/Unnecessary” data and files when the Event-Driven Partitioned model is overlaid with typical old design structures. Let me take the previous diagram and overlay it with all-too-typical system and department boundaries. With this old industrial age partitioning you can see the huge number of interfaces between the artificial design partitioning and the need for more designer files. These overlaid boundaries do not form functional systems. Given my rule on the need for only essential files, you’ll notice on this diagram that we still need the Essential Files between events – that’s a given – but we will also need the non essential files between the design boundaries. In the real world some of these data between these two types of files will be mixed.
Notice also the large number of interfaces (flows of information) between each design partition. In the old days these used to be combined into what was called transaction files with Transaction Codes prefixed to each record in them. These codes were needed in order to separate back out the individual records in each system or department that used the designer files. Always question the need for designer codes.
In my Business Process Analysis seminar I tell my students to distrust the need for files (for the above reason). However in my Business Information Analysis seminar we love files (but only the essential ones).This overlay with its classical design indicates that more system boundaries will result in more files and an increase in potential errors and inefficiencies. We can also see how unnecessary files slow down the response to a Customer.
Creating Seamless, Natural Business Boundaries.
I’ve given talks at conferences, in the past, on what I call “Frictionless Commerce”, which is accomplished by creating seamless, natural business Boundaries. I believe we should strive to produce a “natural response” view to the fulfillment of a customer’s need - at least on our analysis model. I’ve consulted with many projects over the years and seen some fairly complex models. So I don’t want to imply with my simplistic examples that your event partitions will always be one simple flow. What I do see, especially in complex events, is many branches stemming from the initial stimulus as well as external data being pulled in during an event partition, such as in a dialogue with a customer. However I do want to give you the feeling that the process of developing these models is not difficult. I recommend As much as possible using data stimuli to detect the true business flow; both the initial stimulus and then the ongoing stimuli to each sub-process. If you concentrate on just process flow you may come out with a different view as process flow makes you ask ‘”what happens next - then what happens next”, as opposed to ‘what does the stimulating dataflow trigger next’. Also I would recommend being careful, in the business world, of falling into the trap of flowcharting (which is actually flow-of-control oriented). Notice in this model I’m still capturing the 6 components for the Event Partition just at a lower level of detail.
If you present these analysis models to existing staff you may come up against the “but we don’t do it that way” syndrome, especially when crossing an existing boundary - and that problem applies to Computer systems as well as human systems. But that’s just an education problem. In this model we see an un-fragmented, seamless response to a customer’s need without any old design boundaries. This model shows a more “natural” view of the essential business processing. And if I might add it follows an adapted Newton’s First Law of Motion: The Event impetus (like a body in motion) wants to stay in motion until impeded by some resistance (i.e., an unnatural boundary). Its original driving force (the Event stimulus) gets lost when dissipated through a series of false partitions. I hope you see how that law applies.
At least when analyzing an organization we should model and specify this partitioning and then, if there are no overriding issues, implement this analysis partitioning in the new design. It’s certainly easy to implement in a small startup organization but even a large organization such as Federal Express has shown the value of implement a whole event partition. If we fragment this view in design we may cause customer problems and delays. When I have the luxury of presenting these principles to the high level management of a large organization they usually say, aren’t we doing this already? But it’s even better when I get to explain these ideas to a start-up company; they don’t have to undo any old designs. You may have heard the saying God created earth in 6 days, but he didn’t have any legacy systems.
So let’s move onto the implementation of an Event Partition. We can use each Event-Driven Partition as an efficient structure for implementation of a new system in our organization, resulting in true “FUNCTIONAL” units (Manual and/or Computer systems). Here’s one implementation of a typical Customer Order processing and how we might use silicon and carbon based units (humans and computers) in a team approach. In my latest management book I call this view an Event Compartment. If we are not forced to corrupt our Event Partition in design and implementation we gain the advantage of ending up with simply the shortest distance between two points to satisfy our customer’s needs. If you have an established organization it’ll be easier to restructure the old computer systems as they don’t get too attached to their old structure.
With this Event Partitioning carried through into design the Event-Driven Implementation “Team” can:
· Consist of one individual (wearing many “hats”) with one computer program/system. This first option reminds me of when I started LCI in 1980. I personally did every task based on the stimulus request for a seminar and with minimal computer software.
· Be an empowered team of individuals with many reusable computer programs. As my organization grew, more employees worked together as a team and we used lots of reusable software but the team was still functional, triggered by external stimuli, and not put into industrial age boundaries.
· Take on one or more implemented Event Partitions - depending on the size and volume of an Event Partition. An example of taking on many Event partitions is an Automated Teller Machine system. It gives you a choice of different banking transactions to perform.
· Be replicated for voluminous Events. An example of replicating a team is many Automated Teller Machines doing the exact same transactions (Events) for the one bank. Or multiple airline check in clerks doing the same customer services (Events). (Note that the airline check-in clerk is one fragment of an Event).
Of course any combination of these bulleted options is fine. We can also collect effective metrics for each Event team, rather than by fragmented departments. The team metrics can be derived from measurable performance, such as customer satisfaction or complaint level, or repeat customer business. Then offer rewards based on the most successful Event Compartment teams.
I mentioned previously that an Event Compartment could consist of a human and a computer system team. Well let me tell you about an experience I had while writing this article. I was putting together a party at my house when the stress sensor in my refrigerator detected how important the refrigerator was to my party and thereforetriggered a part breakdown. You’ve probably experienced these stress sensors. They appear to be in most important consumer products. So I called a local appliance repair company, expecting that there was a very slim chance of getting the fridge repaired in time. I gave them the make and model of my fridge and the next day… The repair guy Arrived – Confirmed the part, he had brought with him, with his laptop and – Fitted it, within a couple of minutes the refrigerator was getting cold inside. So he asked me if I wanted to pay now. I said “sure”. He brought out another silicone based unit, accepted my credit card payment – Printed a Receipt - and Left.
This amazed me as I was used to the “4 to 6 weeks” or the “10 business days” response time. It amazed me so much I asked if I could take these pictures. This “instance” of an Event-Driven Partition was implemented in 7 minutes with an empowered Human (carbon-based unit) and Computer (silicon-based unit) team. Well actually less than one day from my stimulus to the organization. With the exception of their scheduling process I could easily tell there were no department boundaries or separate computer systems holding up the response to my event.
Throughout this article I’ve been stating some of the benefits of applying Event Driven concepts to an organization. They can be quite significant. Implementing Whole Event-Driven Partitions may help us realize orders of magnitude savings of time and money over our current systems. Now, orders of magnitude improvements might sound a little extreme but depending on the size of your organization and how old it is (actually how long it’s been using industrial age concepts) this is actually quite possible. Here’s a worst case implementation example of a “fragmented” Event partition:
As I’ve mentioned previously the biggest problems with the old industrial age structure is the delays caused by designer files. But on top of that is the amount of rework in processes for example re-editing and re checking information passed from the last fragmented department and program/system. In the industrial age customers were used to slow business responses because orders had to go through many manual department boundaries triggered by partial order folders arriving in “in-baskets” or the beginning of the next labor shift. Even in the information age when computer systems were introduced many systems still were driven by batched files and message queues sometimes triggered by time and computer availability but today we have a computer literate customer base. Home computers are common and customers know their capability and are less likely to accept slow response excuses. They can spot industrial age systems both manual and computer implemented. I for one don’t accept customer service reps saying “it’s in the computer system so we can’t do anything now” or “You don’t seem to understand how our business works” – No I understand how your business works.
You probably already know what I’m going to say, I believe that implementing Event Driven systems produces a win-win situation and that’s because: An Event Driven organization is more efficient to operate and also responsive to its customers.
Here’s A best case implementation example of a whole Event Compartment:
Now it’s been documented in many books on team concepts that human beings are more satisfied with their jobs when they know they can see the accomplishment of their work. That means rather than working on a fragmented slice of a customers need, they get job satisfaction by being part of a team that accomplishes one complete need. As I said in a previously, on a team approach, this human part of my example doesn’t have to be one person, it can represent more than one person on a complex Event Partition but for a small Event Partition it can actually be one person with many “hats”. Also I’ve worked on enough computer systems to know that the computer part can be one system or dedicated program with reusable modules/subroutines. So this example isn’t unrealistic. Of course those Event Partitions that have systematic processing logic the customer can act directly with an online computer system. When unnatural boundaries are removed there is no reason why the event response should not be a continuous flow performed in a minimum time frame. Of course there may be valid external time delays affecting the event partition, such as waiting for the customer to responding to an intermediate question but that would be a natural delay and your competition would have the same necessary delay.
If you are lucky enough to be applying Event Driven concepts to a startup company you’re going to save a lot of problems in the future but most importantly you’re going to implement a structure that I believe no other organization can beat. If you are applying Event Driven concepts to an establish organization then you can look real good to high level management as you may well see Orders of Magnitude savings – especially if your current event partitions are implemented with separate hysterical departments and disjoint computer systems. Event-Driven partitioning coupled with the new technology available to implement systems today, such as the internet, will allow you to implement “fast good systems”, not “faster bad systems”.
Why wouldn’t an organization do this when - An Event Driven system is:
• The most responsive to the customer (it’s the shortest distance between two points),
• Easier to maintain (because manual procedures and computer code are specific to one Event and not bundled with other unnecessary and unexecuted processes and data),
• Easiest to Modify (as policy changes and new lines of business (new events) are easier to make for the same reason just stated),
• Even easier to build (as business policy is specific to one event and therefore there are less design codes and less testing required).
I recommend you try out these concepts in this presentation on one Event Partition and see the benefits. As I mentioned at the beginning of this presentation the whole point of Event-Driven Business Concepts is to successfully satisfy the needs of your customer and to do this an organization cannot implement a better structure than Event Driven systems. So I believe Event-Driven organizations should be the rule not the exception. I hope the contents of this article will play a part in guiding your organization to be one of them.Oh and remember my appliance repair company as a customer myself, if another one of my appliances fail guess who’s going to get my Event stimulus call.