In response to requests for BPM best practices… However, I need to cover some ground with a few initial topics. Later, I’ll breakout and add details on focus areas:
- Project Management
- Requirements
- Architecture
- Design
- Patterns for Reuse
- Infrastructure
- Integration
- Durability, Robustness, and Security
- Life-cycle and Operations
- Others, etc.
Forward
As with relatively new technologies and methods, discovery is a significant part of the learning process. And, notwithstanding misconceptions, some lessons will be learned from trial-and-error.
It’s my attempt here, via these chapters, to share a few of my own experiences. Many of these lessons were learned the hard way. You’ll find, as I did, that classic and modern software development techniques do not apply without adjustment. This new “process oriented” way of thinking requires change in both philosophy and approach – as some paths will lead to a rocky experience, we’ll learn to backup and adjust our approach.
Assuming others will take the same road – I’ll start my series from a look-ahead perspective, where otherwise good software practice leads to BPM project troubles. In-other-words, the “hows” and “whys” we call BPM methods “process oriented” as apposed to (for example) “object oriented” techniques.
Process Management versus Software Development
Departmentalized IT Stovepipes
BPM projects require a new approach as their work extends beyond traditional IT boundaries. For example, topics like business strategy and departmental alignment.
In taking on this work, our methodologies require adjustment and tolerance as what was once a typically predictable path now leads us wandering through a seaming maze of new discoveries, obstacles, and political minefields.
First change on the agenda is institutionalized dogma (or, departmental habits die hard).
A Change in Methods
The corporate IT organization casts a long, deep shadow of institutionalized thinking (or dogma) across projects. Institutional thinking and approach, which ordinarily works well on “standard” efforts, will interfere and harm BPM projects – usually leading to failure on initial attempts. Though good intentions in mind, the old way of doing things must end if we’re to succeed on our next effort.
One Project Plan and Synchronized Software Development (project versus team milestones). It’s a dangerous practice attempting to share deadlines on otherwise naturally distributed, asynchronous work efforts. In contrast to a drum’s dancing rhythm, forced synchronicity for BPM work has the opposite effect on enterprise projects. Cross-project milestone alignment will lead to a grinding loss of productivity.
Architecting Process as a Single Software Point-solution. Process is not “architected”. The methods of architecting a process assumes that we already understand – that the process itself is known and ready for refinement into something expressed via technologies as systems. This isn’t the case with BPM which defines itself as a means towards providing evolutionary process – a perfection intended to match against our changing business environment. Something gained, and then lost, given that business itself is evolutionary. As innovation is one of our key desires behind the process-oriented methodology, a static system is not an achievement. However, we shouldn’t confuse this argument with architecture’s place in: patterns, SDLC, components, and service construction (etc.).
[To be continued…]
