1. How come you are in New Zealand at the moment?
I’m the guest of Software Education who is celebrating their 20th anniversary, which is no mean feat, staying in business that long means they are doing something right. And I’d like to think they are doing something right by having me down to speak for a couple of client engagements.
Actually you’ve probably got about three or four questions in there. Let me just go back to beginning. You talked about the resistance to modeling. I think this comes about because so often the modeling that we’re exposed to is done at what I would call the specification level. For instance, in the field of data modeling, when people are shown a data model, what they are actually shown is a graphic of a physical database design. In the business process modeling world, especially with the emergence of BPMN, if we see a full blown process model, it’s not so much something digestible or consumable by a business person, but something that is designed for specifying and automated workflow - an SAP workflow or MQ Series workflow or some tool like that.
I think this happens because the tools that have been developed for modeling purposes largely exist to support construction, as opposed to supporting analysis or even planning. This has led to a lot of resistance. I could go on and on about that, but I think you asked a couple of other questions in there as well, such as: Why should we do modeling? - We should do modeling if we’re dealing with a subject matter that can’t be observed directly. So it’s better to build an iconic or a symbolic model of it, so we can come to agreement on what it is we’re discussing. Maybe we can manipulate the model like manipulating a model of a process instead of moving around the people who are part of that process.
Any time you’ve got some important factor that you are working with, that you can’t observe directly, then modeling is appropriate. I can see you poised to ask me one more question, but let me just go a little bit further. A business process, which is where I do a lot of modeling, is something that can’t necessarily be viewed directly. Not all at once, especially if it involves people in multiple geographic locations. In that case, a simple but complete model is invaluable. Much less valuable if you are talking about a group of people doing some work in a tightly scoped departmental set of activities, for instance.
Yes, it is. Building complex models is definitely contradictory to what Agile is all about, but building simple models isn’t. Let me give you an example. If I have a list of user stories in my backlog posted on the wall in my war room, that’s a model. It’s a textual model or I could have my user stories on some sort of a nicely shaped post-it, but it’s a model. It’s a model at what I would call the scope level of detail. I think we are going to get into this a little bit later, but any sort of modeling that I’m engaged in, whether it’s process modeling, use case modeling, business service specification modeling or data modeling, can exist at three levels of detail: the scope level, the conceptual level and the detail or specification level.
Those detailed models that have enough content, enough rigor in them that you could actually build something from them, those specification level models, probably aren’t very appropriate in an Agile environment. But a scope level model saying "Here is a list of processes or user stories that we’re going to work on" or "Here is a very high level overall picture of our process flow" - those are entirely appropriate. And as the scope of your initiative goes up, they get more useful.
4. Can you explain a little bit further this concept of levels in your modeling?
Some of your viewers may be familiar with the Zachman framework. John Zachman was one of the pioneers in noting that when we model or discuss any subject matter, especially in his original article he was talking about information systems, there are these three perspectives. There are more than three, but the top three I’m concerned with. He called them "the planner’s view", so very high level models that let us discuss scope, for instance what’s in, what’s out. That corresponds to what I call a scope level model. Then he talked about the owner’s view and this was a model that the owner of the subject matter would be comfortable with.
That’s like a conceptual model in my terms. Simple symbols, boxes and lines, not a lot of syntactic rules, but terrific for establishing communication among multiple audiences. Then we get down to what John called the designer’s view, which is models that are detailed enough that you could actually build something from them. John’s original article described these in terms of a building analogy, but I use it and so do millions of other people around the world to talk about business and systems constructs. I could go a little bit further. If we took say process - again, that’s where I spend a lot of work- a scope level process model would be a very simple block diagram illustrating perhaps a family, a related set of business processes, like customer relationship management.
And maybe depicting the individual processes within that area, such as acquiring a customer, completing a customer communication, resolving a customer’s service issue - that sort of thing. Maybe even going down to the pieces of those processes, but a very simple block diagram so people can point to some of those boxes and say "This is in scope and the other ones are out of scope." Again, nobody needs any training of any sort or even special tools to be able to understand or create models like that. Then, in the process context, if we were looking at a conceptual level process model, that could take the form of a swim lane diagram, could take the form of a decomposition.
But we’ll stick with the swim lane diagram where there are lanes illustrating the different participants in the process and basically boxes and lines showing the activities performed by the different actors and the overall flow amongst them. When I do those things, it’s simply boxes and lines, not even our old friend the decision diamond. There is no symbolic overload, there is nothing that would put off any business person from feeling quite comfortable reviewing that model. That’s fine for getting a shared understanding of the overall flow or the process. By the way, those are very useful in an Agile environment where the individual steps might correspond to a user story.
Within that there is an awful lot of dialogue and maybe a lot of rules and logic happening, but we don’t need to see that. We just need to see the overall flow, so people get the concept of the process. We can go finally down to the specification or the detail level and now we’re at the level where there is a lot of logic maybe showing the different paths through the process put down at the level that it has enough specificity that you could implement this in some sort of a workflow engine. In other words you might have a very detailed BPMN model that would generate BPEL [Business Process Execution Language] which would then drive one of the commercial workflow tools.
5. This is where the heavyweight syntax of things such as BPMN comes in.
Absolutely. I get accused of being a BPMN basher from time to time, which frankly I am once in a while. But more what I object to is the misapplication of tools. If you’re talking about a very detailed logical data model or a very detailed class diagram, there is syntax in there that is necessary at that level of detail, but it’s not necessary at that conceptual level where we’re working on a shared understanding.
6. I’ve heard you use the term that a tool such as BPMN is a visual programming language.
Yes. That’s liable to get me in trouble with some people. I was looking at a very rich BPMN diagram once and I realized that it would be utterly incomprehensible to the business person who owned that process and it got me thinking. The parallel that came to my mind was 30 years ago I did APL programming and I don’t know if your viewers are familiar with APL, but if you go and Google it you’ll find that APL stands for A Programming Language. It was a language that was constructed of all these Greek symbols - Rhos and Taus and Omegas and things like that. Each one of them was a matrix operation that was incredibly powerful and you’d string these together ideally into the famous one-liner we liked to write APL programs that had many of these symbols but they all lived in one line.
They could do wonderful things and they are still in use, say in insurance, in some underwriting areas. Anyway, the underwriter could look at one of these and find it absolutely indecipherable, but it did represent something important to their business. We could even draw comparisons with COBOL (Common Business Oriented Language). You don’t want to expose necessarily your business person to the logic that’s expressed in a COBOL program, but it is important. Anyway, BPMN is the same thing. It’s just like APL, just like COBOL, it’s a programming language. One of the things I object to is calling it a business process modeling language. I think it would be far more appropriate to call it an automated workflow specification language. If any of the BPMN fans see this, I’ll have earned their ire.
They may not. If we are dealing with something that is tightly constrained enough that there isn’t any significant workflow, then they may not apply. In fact, in the book, which I think you generously plugged at the beginning at this interview, we asked the question "When should you do workflow modeling?" And our answer was "You should do workflow modeling when the work flows" - not surprisingly. If you have a complex order fulfillment process where the work flows from the customer to the sales desk, to the order management people, to logistics and so on, then a simple workflow can help.
Just so people understand "If I’m working on this user story here, what has happened before, what’s happening afterwards?" Because in a complex process it can be pretty easy to get things out of sync, to do work that’s unnecessary because it’s already been done, or to fail to see a significant opportunity to improve or simplify the process. I think as long as we focus on keeping it useful, which is up at the appropriate level of detail - so we’re not spending a lot of time on the modeling and we’re not spending a lot of time on arguing about the right symbols to use in the right situation.
Then, I think it’s extremely useful in an Agile environment in fact I’ve done a lot of work in the last few years and a lot of training for Agile teams who have found often much to their surprise that this scope and conceptual level modeling is very useful because it can constrain some of the detours that they might have otherwise taken and some simple conceptual modeling, whether it’s process modeling or use case modeling or old favorite data modeling can improve communication and cut a few iteration cycles out of the process.
8. Thank you very much for taking the time to talk to us and good luck and enjoy the rest of your trip.
I’m here at one of the great parts of the world, just outside Wellington, New Zealand, so I am a happy fellow. Thank you for having me.