Over the past year people have asked me to articulate what makes our approach different to that offered by other vendors, along with what the approach is moving forward. In answering this, I’d like to tie together some thoughts around the business focus we’ve taken for our products and how this relates to a number of topical issues in the marketplace. These include: Before launching into today’s discussion though, I’d like to take this opportunity to wish you all a Merry Christmas and Happy New Year!
Do Away with Programmers?
Let’s start by looking at whether programmers and their tools will eventually become obsolete. This is something that some vendors have been touting for at least 2 decades now. I think that the need to program will never go away, it’s more that the role people play will continue to change, along with the tools they use, so that eventually everyone will program at least a little bit. Whether it’s graphical programming with bubbles and arrows, setting up a device to record movies, or using a text editor with fields, it’s still programming of sorts and what people recognised as programming in the past will be very different to what it will become in the future.
I raise the debate because it has relevance to the argument that a single process modelling formalism is enough to satisfy business users and that you can get a free kick on creating system executable processes at the same time.
Pega Systems for instance is an impressive example of how a workflow and rules engine can be focused to capture business execution rules, process definitions and form design. It provides a great mixture of intelligent execution engine design, along with programming tools that can be used by people who have traditionally been involved with the business, not the IT side of an organisation. But can we really do away with all programmers and just let the business come up with rules and have software execute them? Yes and no.
Business users can become programmers of sorts. It’s just that the skill level required in order to perform these tasks means that few people today will be able to do this without considerable assistance. They will also need to get comfortable with concepts like version control and change management at the same time. Also, large companies don’t have the luxury to replace existing systems with shiny new ones based on modelled system processes. Often the best these businesses can do is to use an SOA-approach to encapsulate services and relate these back to system processes; and this kind of work requires developers that use traditional programming tools.
Even if you can get business people more involved in the programming of systems and change the toolset they use, this is certainly not the only avenue for improving the cost, efficiency of effectiveness of an organisation. Other things need to be taken into consideration for this to occur.
A Techno-Centric Approach
Technologists in particular come up with ways to improve business processes using new and innovative technology, often in response to a new business need. In some cases there are green opportunities to create new systems, in others, say when there is a dependence on a legacy system, the technology can hamper the business to adapt to new market conditions. So, technology choice is important as this can help or hinder in the execution of a business strategy.
But can organisations simply focus on the technology that executes, rather than requirements and outcomes? More efficient ways to define process models have lead to a tendency to reduce things to their most essential elements – what executes in a computer system. Whilst this is efficient for computer execution, it is not effective in an organisation if it forsakes creating a more complete model of the business, including the human dimension and the purpose for the system in the first place. The politics of many organisations alone will mean a technology-based approach is doomed to fail. This is because the approach lacks consulting people, getting their buy in, and jointly arriving at an outcome.
Many technology vendors claim to represent “the business” and at the same time offer an execution of business processes as the answer. This results in only a portion of a solution. I’ve seen this kind of approach from products ranging from BizTalk, WebSphere, and UML-based tools (although typically repurposed as being “Enterprise Architecture” tools these days), claiming to be business oriented, but still without a doubt rooted in the software engineering space. That’s not to say these tools aren’t useful for system design and implementation; it’s just that they are still used by IT people to focus on the system definition and execution space and only offer a thin veneer of business modelling around this, which leaves the models relevant to and owned by software developers, as opposed to a business audience.
This is in vast contrast to drawing tools like Visio, which allows you to create very pleasing images, or even maps. In many ways, it’s really like a more advanced kind of PowerPoint presentation, and allows for a person with basic skills to draw something and at the same time appear to be productive. However, this is certainly not something that can be consider a model and the benefits attributable to models are therefore forgone—such as the ability to keep content up to date and use it for multiple purposes.
A good deal of customer feedback to date has been around how with previous approaches, they had to create models using a system modelling tool, and that these were not even close to being consumed by a business audience. The models subsequently had to be redrawn in Visio or PowerPoint in order for the business people to understand what was happening. It’s hardly surprising that some organisations decide to skip “as-is” modelling altogether, given the difficulty surrounding the capture of validated process models. Needless to say, modelling to the wrong audience and drawing maps is a waste of time and effort and is avoidable if the right toolset can be used from the start.
Skill Sets and Abstraction
People in an organisation have a vast range of skill sets and requirements. Many business users don’t ever want to become expert process modellers, let alone system process modellers; they want to review and follow easily understood representations of their business, such as standard operation procedures or business requirements, without having to complicate this with execution syntax or the latest technology-based standard.
From a traditional programmer’s perspective, looking at a business model is like looking at a map that doesn’t have code in it – what’s the point of doing something that can't run? To a business person, it’s more of a question of creating an artefact that they understand, and ultimately are prepared to sign off on as representing their business. However, it’s not just one view that needs to be catered for, a system view is just as valid but this is related to the business view.
Traditional use case modelling struggled with business requirements versus system design and came up with a separation of Business Use Cases from System Use Cases, where the business ones were higher levels of abstraction (and less implementation focused) than system ones. To this day, use case modelling is inherently textual in nature and therefore open to analysts writing copious amounts of prose for a use case body, which can make them hard to read and follow. The ability to integrate use cases with process modelling has since assisted with keeping use cases focused on system design, leaving the business focus as part of a process model.
One Notation to Rule Them All?
For process modelling, some would argue that the Business Process Modelling Notation (BPMN) has the ability to represent high level business processes, as well as system processes. This notation was initially created by a group of process execution vendors, and in a way, it is possible to represent a high level business process, but in practice the shapes (and even many of the execution formalisms) of BPMN are a turn off to business users that don’t have an IT background, in the same way that diagrams with shaded colours and images of people are a turn off to system developers. The notation also tends to downplay, if not ignore the role of the user.
Even from an execution perspective, few if any successful process execution vendors have plain vanilla, “standard” execution models; they offer some kind of customisation to make the models work properly, or simply make the notation style look vaguely the same as BPMN for instance.
The bottom line is that having a BPMN-like support in a modelling tool is not going to be enough to meet the demands of business modelling, where business users have diverse, non-technical backgrounds and there is also a need to integrate these with system processes. It’s a myth that there exists a lowest denominator notation that caters for everything.
A Holocentric Approach
The approach we have taken is to focus on business users in an organisation, first and foremost, from executives through to people doing work on a shop floor. We provide relevant views for this audience, as well as providing a bridge into system design and implementation.
Business models are the lynchpin and it is therefore essential to be able to work with a flexible metamodel that can capture multiple models, which are effective for their intended audience. These models should also allow costing and return on investment to be calculated.
This approach is not fundamentally based on kludged extensions to a software metamodel model, as is the case with UML profiles, but one that encompasses business and system concepts; and these must be seamlessly incorporated into the metamodel.
Whilst not advocating BPMN for business process modelling, there is a role for BPMN-based models around system design and execution and this certainly can be catered for as one of the views in a model, provided it's related back to business activities.
Comments