And it's not just me saying that - it's IBM.

Last week's posting to this blog explained why a first step in building a service layer in your enterprise is to ensure that you grasp the general shape of a modern development infrastructure. In other words, you must ensure that your organization possesses a mature and up-to-date software development capability. This is not as simple as it sounds, not only because there are a huge range of competing technologies out there, but also because vendors of middleware systems are doing their very best to spread FUD (Fear, Uncertainty and Doubt) in the marketplace. Haven't got a BPMS yet? Not doing BAM? No enterprise Business Rules Management System? Tch tch tch.

In fact, many BPM practitioners - and certainly most BPM thought leaders - agree that BPM is a management discipline, not a set of software technologies. And this view goes not only for pure BPM, but for supporting applications like BAM, BRM, CEP, and so on. Technology is simply an enabler of management practice. Get your practice right, and you can often do all this kind of thing very cheaply and easily without need for any big iron middleware at all.

Long-time readers of this blog will remember that, as a simple illustration of this, I often mention the number of monthly downloads of JBoss application server - generally over 200,000 - and point out how this by any reckoning this must dwarf the total number of BPMS installations ever performed, anywhere, at any time. Last year I spoke at the largest BPM conference in Europe and the largest programming conference in Europe. Attendance at the former was in the hundreds. Attendance at the latter was in the thousands.

So why does low-level programming still rule the roost - is it about price? Hardly. Only recently has the success of the open source movement made low-cost or free development tooling a reality for enterprise-level software construction. Further, there are now various free and open source BPMS products available. What it's about is functionality.

Taking the Java world as an example, all the advantages claimed for applications such as a BPMS are now available out of the box for plain old Java programmers. There are low-level technologies that automate process implementation from models - see the IBM white paper mentioned below, for example. Business Activity Monitoring, aka BAM, can be handled very well using aspect-oriented tools such as AspectJ in combination with a dynamic configuration framework such as Spring. Business rules can be implemented, and changed on the fly, using a combination of the Strategy design pattern and flexible deployment technologies such as JMX. These are only examples - there are many more ways to build everything you need for software support of BPM using mainstream programming tools that (if you wish) are available for free and as open source.

BPMS vendors and those with a vested interest in the adoption of such systems (for instance, vendors of associated technologies such as business rules) will no doubt respond to this assertion with the rallying cry: "You may be the kind of techie who just likes programming, but our systems place control in the hands of business people, permitting true business agility".

Oh, come on. As mentioned in the last post, you will always need IT people to manage the configuration and deployment of business processes. No business person is ever going to be able to change anything in a BPMS or associated system - and if they have permission to do so, it ought to be taken away!

What a business person does have every right to expect is for it to made abundantly clear to them, in a plain manner suitable for a non-technical stakeholder, what their systems do. Then there is a proper basis for discussion between them and their IT staff on how the system can be configured to behave differently in future. Then their IT staff can go away and implement the requirements of the business.

Over the last 15 years, I have seen far too many cases in which an enterprise application vendor's promises of tech-free administration, together with a sexy user interface, led to quite disastrous mis-configuration by end-users. Some of these cases would make anyone blanch. And once you have been bitten by the business consequences of such unfortunate meddling by people who have not been trained to understand the consequences of their actions, you will be quite happy to leave the IT department in control of back-end systems forevermore. Business people, give the techies your requirements and let them "make it so"! It's their job, not yours, and everyone will end up happier.

TAKE AWAY

I think it is inevitable that BPM systems and programming technology will converge - and that this convergence will be driven by the programming community, not by the BPM community.

For a start, best-of-breed programming tools now possess a degree of smarts to which no BPM system even comes close. This is partly thanks to the emergence of software design patterns during the early 1990s, and the consequent rise of frameworks based on such patterns, but also due to a number of breakthrough innovations in the last decade such as model-driven development, test-first design and aspect-oriented programming. Modern programming tools are the result of years of massive-scale community effort, and incorporate thinking about software that easily surpasses the best efforts of any application vendor.

Further, since you need IT people to make changes to systems, why not let them do it using the tools they know and prefer?

To conclude, here is an extract from a recent IBM white paper:

Once BPM systems are implemented, they are very hard to change because they are engineered as software development solutions that are linear and rigid or because the monitoring solution derives from process models. Solutions derived from processes are flexible but not comprehensive enough to include the nonprocess metrics needed to represent the full state of a business. Thus, a BPM approach not based on models can fall short of fully meeting business needs.

The abstraction of the BPM solution to higher-level models, as we propose, overcomes the shortcomings of BPM alone. It enables business analysts and system architects to contribute directly to the solution. The MDD approach to BPM means that business goals can be defined independent of an information technology (IT) platform. Business-level models either provide linkage to or can be automatically transformed directly to IT-level models using transformation routines. MDD can quickly reflect changing business goals and monitoring needs through models.

Model Driven Development for Business Performance Management, IBM Systems Journal, Volume 45, Number 3, 2006

Like these IBM researchers, I believe that BPM system implementation in future will be an end-to-end programming effort driven by modelling. My own recommendation if you seek a software infrastructure for BPM is to leverage state-of-the-art modelling tools such as Eclipse EMF, together with a low-level code library for the mechanics of state machine implementation (preferably a free and open source solution such as jBPM). This is not only a practical and low-cost route, but also one that satisfies the need among business people for an object-based description of their processes.

So would you like to discover how to prepare your own enterprise for implementation of such solutions? Then stay tuned to this blog.

Posted by keithhb in Business Process Management • Service-Orientated Architecture | Permalink | Comments (7)

This blog has often addressed leading edge techniques for the integration of business processes with an enterprise IT backbone. A particular focus has been "human-driven" business processes - those in which people not only enter data and record decisions in online forms, but where they also collaborate with each other and leverage business intelligence to create and innovate business solutions.

In recent entries I have articulated a top-down business process management methodology which addresses the most pressing needs of the modern enterprise - to acquire the agility necessary for survival in a globalized, wired marketplace, while simultaneously complying with statutory regulations and company policies, all within a safely controlled management hierarchy. Here is the methodology in outline:

1. First draw up a process architecture, to unite business goals with business processes.  This is a sine qua non - unless you start here, you will be building a house on sand. As discussed often in this blog, goals are the true foundation of all business activities.
2. Next apply Human Interaction Management, to make best use of the humans in your organization, at all levels of the organization chart - not in order to downsize your people away, but rather in order to leverage the skills you have on board.  Only via HIM can you gain the dual advantages of structure (for efficiency) and agility (for responsiveness).
3. Use BPM/workflow to improve your performance of mechanistic work - but be aware that there are no magic bullets to remove real-world complexity!  The idea that BPM would make it possible for business people to change mechanistic processes on the fly is a complete myth.  The IT department are going to stay involved for the duration, and when you want a new version of a mechanistic process you will need to ask IT people to draw it up, IT people to ensure it complies with regulations, IT people to test it, and IT people to deploy it.  Agility is for human-driven processes only - it is the province of HIM, not of BPM/workflow.
4. Finally (and only at this point should SOA enter the picture), look at all the processes you have defined - both human-driven and mechanistic - and ask: which of these could make use of services?  Then build the services you need, not those that the IT department suggests may be quite handy.

This methodology goes by the name of Goal-Oriented Organization Design, aka GOOD.

In previous posts I have discussed most techniques required to implement GOOD, and shown how tooling for BPM and SOA is evolving to meet these requirements. However, the area to which so far I have devoted least attention is the final level, which from an IT specialist's perspective is where the rubber meets the road. How should one go about the provision of a service layer in the enterprise?

There are several related aspects to such work. No longer is it appropriate simply to put together a team of designers, coders, testers, and technical authors, add a project manager and start building systems. The world is full of new deployment frameworks, application frameworks, architectural techniques, programming techniques, communication technologies, ...

Anyone that starts out on an SOA programme without grasping the general shape of a modern development infrastructure runs a serious risk. They are likely to find out part-way down the line that they have not only wasted a large amount of their organization's resources by failing to leverage modern best practices for development, but that what they have spent so much time and effort building is not in any way future-proof and hence only ever going to have a limited life.

Of course, a site such as ebizq.net is full of advice on aspects of SOA implementation. There are also fully-fledged SOA methodologies available from various vendors and even analysts, and no end of consultancy and training services on offer to support it all.

However, many people that I speak to are looking for something much simpler: a simple, clear description of the capabilities required to build a service layer, and roughly how these capabilities relate to one another. The SOA marketplace is chock full of arcane buzzwords, which often describe techniques and technologies that do not so much compete as overlap in ways that confuse almost everybody. This serves to disguise the shape of what actually needs to be done by an organization seeking to build a set of services.

TAKE AWAY

Suppose you plan (as most organizations do) to develop code in Java, either in place of or along with code in .NET. How well do you understand the different offerings of such component technologies as SCA, JBI, J2EE, JMX, OSGi, and JPF? What about new proposals such as JSR-277, or vendor-specific technologies such as the SAP Composite Application Framework? Which of all these are Java-specific and which ones can be used to integrate Java with .NET components?

Most people are struggling so hard with the subtle differences between these acronyms that they have no mental space left for getting the perspective required to make strategic decisions.

In this next series of blog posts I will try to un-muddy the waters, and talk at a high level about the kinds of things you need to think about if your organization is planning to implement SOA on any scale. If you have difficult decisions to make about technology implementation for an enterprise backbone, you may find that my articles over the next few weeks help to clarify the issues - and ensure that you do not come unstuck when justifying decisions to the board.

Posted by keithhb in Service-Orientated Architecture | Permalink | Comments (2)