For the first breakout session of the day, I attended Ken Orr’s talk on Business Process Driven Enterprise Architecture. He started out with some observations: improving business processes is essential for enterprises; business architecture is critical; modelling is critical; and business processes are hard to manage in the real world and especially in big organizations. Nothing earth-shattering here, but excellent points.
He made a great analogy by talking about IT levees — fragile yet critical applications and systems where you know that they’re a weak point but just never find the time or money to fix them — and understanding when they’re going to break. Apparently, a year before Hurricane Katrina, there was an exercise that modelled exactly what would happen if a force 4 or 5 hurricane hit New Orleans, but nothing was done; when Katrina hit, the levees failed exactly as modelled. Orr talked about mission critical spreadsheets as being one class of IT levees that are all set up to fail at the wrong time.
He talked about how enterprise architecture is like city planning, where your deliverables are things like a city plan, a zoning plan, a building code and an approved building-materials list. Sticking with the disaster analogies, he talked about how building codes are the result of disasters, and the obvious analogy with software and system disasters is pretty clear.
He covered off their enterprise architecture framework briefly, but used it mostly to discuss how the different layers in a framework interact: in short, technology changes enable business changes, and business changes drive the need for technology changes. He also talked about determining what type of business that you’re in, that is, what business processes are you really doing, so that you can figure out whether or not you should be in those businesses as well as how to improve them. Funnily enough, he really answered part of the question that I asked in the panel in the previous session with respect to getting an end-to-end business process view, but that’s sort of expected from an enterprise architecture person since EA can be a key tool in doing just that. In his terminology, what I’m talking about is a value stream, defined by James Martin in The Great Transition as “…an end-to-end set of activities which collectively create value for a customer.”
Update: I forgot to add “Orr’s rules of modelling”, which he gave after I had shut down my laptop, so were just scribbled on a piece of paper:
- It’s more important to be clear than correct. If you’re clearly wrong, someone will correct you. If you’re obscurely correct, you may never know.
- It’s not important that your first model is correct, only that your last model is correct.
I have read previous posts and articles.
I have worked on process mapping and automation. When I finish the work and have the process in execution it is old and have to be redesigned again. The applications and solutions are too restritive to allow business process continuos enhancement.
Now we are working in an approach where we leave the process to run with minor restrictions/rules and these rules are periodicaly changed.
In this solution the mapping is performed by the process that tell us how the activities are being executed by the users.
We leave the process run (document and activities flow) and through the analysis of the documents the process can be mapped.
Now we are deploying the system using this approach. The core of the system is the document not the system.