We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

IT Directions

Keith Harrison-Broninski

Is your organization an efficient system?

Vote 0 Votes

This is the sixth and final entry in a blog series on enterprise software development practices. The aim of this series has been to set into context various current movements from a management viewpoint. In particular, I started out by promising to discuss the relationship of application programming (whose state-of-the-art is evolving rapidly at the moment) to other modern approaches (in particular, SOA and BPM), and to show how the use of all 3 approaches can be properly synchronized within the enterprise. What have I covered so far?

I have described the management chaos surrounding all these forms of software development in large organizations (and some organizations that are not so large) - and shown how simple, universal, formal management principles can be applied to sort things out. In particular, this gives you a means not only to integrate the work of diverse teams, but also to ensure that the strategic skills of senior management are leveraged for the business benefit of the organization - even when it comes to IT! In the previous entry, I illustrated this approach by reference to SOA. In this final posting, I will show how BPM and application programming can be brought under the same control.

First, though, why separate BPM and SOA? Many IT writers describe BPM and SOA as part and parcel of the same picture - "your services are there simply for use in your processes". This is true, but it misses a key point. The fundamental aim of SOA is to "decouple" - in plain English, to separate or distinguish - the IT functions offered in an enterprise from the means by which these functions are implemented. In practice, this means that an individual service can be employed without the consuming application or user having any idea how or where is it implemented.

An important implication of this is that the consumer has no idea which particular services are implemented by the same backend system. In fact, even if they do suspect that service PQR is implemented by ERP System XYZ, this may be true one day and false the next, since a primary aim of SOA is to enable the backend flexibility necessary for efficient IT operations. Hence, an ancillary effect of SOA is to prevent service consumers from understanding their IT environment in a holistic way - all they ever see is a disconnected list of individual services, each offering a specific piece of functionality.

It is hard to overstate the importance of this aspect of SOA. To see why it is so important, consider by contrast the nature of BPM and application programming. Both aim at the creation of complete systems - whether such systems are based on processes (like BPM) or on functional needs (like custom applications). Well, yes, of course, you may say - I know what a system is. But do you think about systems in the most useful way? A system is much more than a set of program modules. Here is what Peter Senge, in his seminal book "The Fifth Discipline" (1990, p.68-69), has to say about Systems Thinking:

Systems thinking is a discipline for seeing wholes. It is a framework for seeing interrelationships rather than things, for seeing patterns of change rather than static "snapshots." It is a set of general principles - distilled over the course of the twentieth century, spanning fields as diverse as the physical and social sciences, engineering, and management. It is also a set of specific tools and techniques, originating in two threads: in "feedback" concepts of cybernetics and in "servo-mechanism" engineering theory dating back to the nineteenth century. During the last thirty years, these tools have been applied to understand a wide range of corporate, urban, regional, economic, political, ecological, and even physiological systems. And systems thinking is a sensibility - for the subtle interconnectedness that gives living systems their unique character.

Today, systems thinking is needed more than ever because we are becoming overwhelmed by complexity. Perhaps for the first time in history, humankind has the capacity to create far more information than anyone can absorb, to foster far greater interdependency than anyone can manage, and to accelerate change far faster than anyone's ability to keep pace. Certainly the scale of complexity is without precedent. All around us are examples of "systemic breakdowns" - problems such as global warming, ozone depletion, the international drug trade, and the U.S. trade and budget deficits - problems that have no simple local cause. Similarly, organizations break down, despite individual brilliance and innovative products, because they are unable to pull their diverse functions and talents into a productive whole.

Sound familiar to you? Know of any IT projects that broke down "despite individual brilliance and innovative products", because it was "unable to pull [its] diverse functions and talents into a productive whole"? If you don't, you can't have been around in IT for very long. And you presumably avoid reading the news, in which reports of such failures are constant - frequently not only very costly but also mission-critical for the organizations concerned.

Despite the influence of the many well-known management writers and practitioners such as Senge, Peter Drucker and Charles Handy who have espoused Systems Thinking, and the demonstrable success of organizations that apply its lessons, Systems Thinking has unfortunately not become pervasive in business life - and nowhere is it more sorely needed, or more evidently lacking, than in IT. In particular, anyone working on a BPM project or an application development should apply its lessons.

However, very few do apply such lessons! For example, a recent article in ACM Queue magazine on "Best Practice BPM" recommended that the first step in a new BPM project should be as follows:

To achieve a rich appreciation of the process, it is necessary to model the process at a high level, from a number of different, complementary perspectives. Assessing the business situation using a set of complementary modeling techniques allows people to comprehend the fundamentals of the process better. The ideal techniques for this phase are:

  • Flow diagrams to look at the order of activities, using BPMN (Business Process Modeling Notation).

  • Role activity diagrams to focus attention on role interactions and the desired behavior of the various actors.

  • Object state transition network models to focus on how the things moving through the process change state.

  • Capability models to look at the process as sets of reusable business components. A capability may be composed of other capabilities or implemented by a procedure (BPMN-style model).

In other words, don't even attempt to develop an appreciation of the core concerns of Systems Thinking: the high-level structures that underpin business operations and the influences driving these structures. Rather, dive straight down into "the order of activities", "the desired behavior of the various actors", "the things moving through the process" and "sets of reusable business components".

The writer goes on to say:

The emphasis here is on understanding the process, not building models for transformation into code or executable process definitions.

Is it? Sounds just like software design to me. Even the techniques (flow diagrams, state transition diagrams, and so on) are drawn directly from software design.

As with the SOA RedBook from IBM that I criticized in the last posting, it is actually rather unfair to pick on this one article. The methodology it espouses is typical of current BPM practice - as it is typical of application development generally. The approach can be characterized as reductionist rather than holistic - focused on the atomic elements of a system rather than on the operation of the system itself. Why are so many intelligent people, who know about the high failure rate of IT projects, unable to see the wood for the trees?

The reasons for the failure of Systems Thinking to gain traction are complex, but the root cause is simple - the pioneers have typically been more like philosophers, or gurus, than engineers. Drucker, for example, always saw management as a liberal art: "liberal" because it deals with the fundamentals of knowledge, self-knowledge, wisdom, and leadership; "art" because it is also concerned with practice and application. This is all very well, but most practicing managers simply have not found the time, or demonstrated the dedication, to achieve (in Senge's words) "Personal Mastery". What the "manager on the street" wants, and needs, is a simple set of core techniques that they can apply to get their job done - without having to think too hard about it.

Is this an indictment of human nature? Who knows. But we have to work with what we've got.

What is needed in order for ordinary mortals to employ Systems Thinking is a set of simple, formal management principles that:

  • Are based on Systems Thinking

  • Can be applied to any problem situation.

And this is what the principles of Human Interaction Management (HIM), described in this blog series, provide.

Turning for example to BPM: before starting to develop a set of process specifications, the senior management of an organization should attempt to understand what sort of processes they need. This is a strategic question, to which the answers will be found not in diagramming techniques but in an understanding of how their organization operates - internally, in the context of its target markets, and with respect to its key partners (including particular customers and suppliers). There is no space here for a complete discussion of Systems Thinking. However, to illustrate the difference between such an effort and the sort of effort proposed above for "Best Practice BPM", the output of such an understanding should be a set of structures, connected both by feedback loops of influence and by evolutionary relationships over time. The aim is to model the business as a whole, not to break it down into individual "streams", "chains", "processes", "networks" or "components".

Once such a set of systemic structures has been defined, it is then possible to define targets and measures for the effective performance of these systems. Such targets and measures form the basis of what HIM terms strategic control. As for the SOA example given in the previous posting, these targets and measures can then be passed down to the next level of management - executive control - for definition of outline processes that implement them. Again as for the SOA example given in the previous posting, the subsequent step is for these outline processes to be fleshed out at a yet lower level - via management control, i.e., facilitated and controlled by managers who work as part of corresponding development teams.

As with the SOA example given last time, it is only in this final stage that the details of process or application design are considered. And this is the right place - since both forms of design require an understanding of, facility with, and taste for the sort of diagramming techniques typically recommended for use by board-level executives. Each to their own, and all will not only give their best, but be happy doing so.


The approach described here to managing BPM and application projects provides the much-needed means to integrate process definition and software development directly with the strategic aims of the organization(s) concerned - removing the "strategy disconnect" described previously.

It also avoids the problem with which the discussion above started - that the user of a service is encouraged to think of each service as independent from all other services, the user of a process is encouraged to think of each process as independent from all other processes, and the user of an application is encouraged to think of each application as independent from all other applications.

In fact, it can be argued that the disconnect between high-level strategy and low-level implementation in most organizations is effectively a symptom of lack of Systems Thinking - a problem caused only by the lack of simple, standard techniques with which anyone can apply Systems Thinking. If your IT infrastructure, like most, fails to reflect the stated visions of your organization, this is almost certainly why.

The good news is that there is a solution, it is free, and anyone can apply it easily. Apply the principles of Human Interaction Management - and leverage the power of Systems Thinking to turn your organization into the efficient system that everyone concerned wants it to be.

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.


 Subscribe in a reader

Recently Commented On

Monthly Archives