Introduction
Have you ever looked at IT marketing and wondered how everything can be different in a glorious digital (replace with whatever the current fashionable buzzword is) future when we still will be creating the same things? Granted we don’t chisel our family tree in a stone tablet these days but use Ancestry.com (or whatever) instead, but it’s still about creating a family tree…
The example is (of course :smile: ) chosen with care, because it illustrates a very simple but important thing: The change is about HOW we go about doing things and not about WHAT we create.
This blog series will explore how, by a simple enhancement and some rigor, we can use classical methodologies like Business Capability Modeling and Business Process Modeling to help us not only to define how digitalization of Government Operations should be done but also to make it happen. This digitalization is one that will be characterized by an ever increasing multitude of the ways of how the same “good old things” can be done.
But don’t get me wrong; the message here is not that there are no new things to be created, the message is that if we simultaneously look at what we need to do using the two lenses of WHAT and HOW it’ll be easier to manage and execute (unless we get all cockeyed in the process…).
What’s the challenge?
So, before getting into how we could manage things better, let’s consider the current state of things and list the some of the major challenges we face:
New ways of doing things
Whilst we can probably forget about stone tablets these days, it’s interesting to observe that we seem to be adding more ways of doing things (using different Interaction Channels) than we remove. This is especially true in Public Sector where the need to service everyone without exclusion typically prevents the removal of Interaction Channels (paper forms will still be around for years to come…). Granted it will happen (as the stone tablet example shows) but compared to Private Sector Businesses the rate of removal will be slower.
The consequence of course is that we will face an ever increasing number of ways of HOW the same WHAT is done. The challenge is that the different ways are not entirely separate. They have major commonalities combined with distinct differences.
The quality of modeling
Modeling we here understand as a way of documenting or representing a reality. This is what is being done when we create Business Capability or Business Process Models.
For those of you who had the opportunity to see the outcome of two separate individuals having to model the same reality, you realized that it can be modeled (i.e. represented/documented) in different ways. Provided that the individuals did not make mistakes, both models are, of course, in principle, equally accurate.
Facing now the choice of which one to use, you’d probably want to pick the “best” one, right? This probably triggers a whole discussion on how to judge what is best (which I leave to someone else to blog about because, whilst interesting, it’s probably a kind of academic discussion). This discussion aside, let’s make the more important observation about that the way we represent reality influences how we think about reality…
A simple example is that a business application development project will most probably build a system that is a reflection of how the business process was represented. Of course, you can here argue that, as long as the different representations are accurate, whichever one you choose you’ll still get a working business application out of that.
The interesting discussion comes when your project doesn’t start from a white sheet of paper (which, let’s face it, doesn’t actually happen a lot – there’s always something existing you need to take into account). The situation is then that the existing system was designed based on a certain way of representing reality (as done by someone in the past) and the new things to be added (let’s say some new way of doing things) has been represented by someone else using a different way.
Combining this with a lack of distinction between the WHAT and the HOW, the result is something we’ve all seen: A breakdown in communications between the new and old generation leading to misunderstandings, scope creep and project delays.
The lesson out of this is that there should be more rigor in how modeling is done. However, this is not primarily a question of which notation standard (e.g. BPMN, BPEL, EPC, …) to use but rather how it’s being applied.
Going from planning to execution
The final challenge I’d like to highlight is the one when we try to transition from the work done by the planners (i.e, Enterprise Architects) to the designers (i.e. Business Process Modelers). Here I’ve sometimes despaired and asked myself “Are we really living on the same planet?”. Here, the very different ways of attacking reality (EA’s top down to-be approach using abstract constructs to organize reality and the Process modelers bottom-up as-is activity/actor oriented way) create a huge disconnect or gap. Finding a way of bridging this gap and make what the planners have done useful also to the designers (and then of course, in turn, to the builders) would increase the value of the planning work substantially.
Introducing the Business Artefact
Let’s now look at the proposed enhancement to the way we do things like Business Capability and Business Process Modeling. Let me introduce you to the “Business Artefact”.
7th Century 15th Century 20th Century 21th Century
Business Artefact is a term used to denote something that gets produced or created. It is the outcome or result of some work and is typically know by different terms like a Document, Record, Transaction, Report, Fact Sheet, etc. Project Managers would know it as a Deliverable. Software Developers would know it as an Object in Object Oriented Programming. A Business Artefact is anything important that needs to be produced (i.e. it’s not the yellow stick it note we used to help us create something but the finished work product). As some of the names allude to, it’s something we would typically (but not necessarily always) keep as proof that something was done at a certain time by someone.
Why is this now useful? Well, going back to the challenges we previously discussed, first of all, a Business Artefact is a “stable” thing. The Family Tree used in the introduction is of course an example of a Business Artefact. If we use stone carving or a web application to create it doesn’t change the fact that we are creating the same thing. Understanding first what needs to be created and then discussing the different ways this should be done bring a structure to a discussion that is very useful. It provides a way of agreeing that, yes, we are still producing the same thing even if the different ways how it’s done is very different.
In the modeling discussion, the Business Artefact forms a very tangible reference point from which we can model/describe how things e.g. are done. After all, there’s a limited set of actions you can do with a thing: Create Family Tree, View Family Tree, Update Family Tree, Delete Family Tree, etc. This means that the Business Artefact forms a basis for deriving a Business Process Model. Similarly, in Business Capability Modeling, the Business Artefact is in fact the actual, real life thing we need to have a capability to produce. It is the thing we organize/classify using a Business Capability Model (or Taxonomy).
So this was the first installment in my small blog series. In the next one, we’ll explore in more detail how we do Business Capability Modeling using the Business Artefact and in the final one, we’ll do the transition from Business Capability Modeling to Business process Modeling and discuss how the Business Artefact will help us there. I’ll also introduce how we can make formalized use of Actors and Interaction Channels to help us manage the similarities and differences between the different ways how Business Artefacts can be produced.
Until then, please let me have your thoughts, reflections and comments. I’d love to learn about any personal experiences you might have in this space to understand if the approach I outline here is as useful as I’m inclined to believe. Also, as this is a rather abstract topic, I expect (and actually hope) that you will understand some of my words in a way I did not anticipate, thus making this a collaborative effort instead of a monologue. Or in the words of George S. Patton: If everyone is thinking alike, then somebody isn't thinking.
- SAP Managed Tags:
4 Comments
