Best and Worst Practices in BPM and SOA
Buying software first. According to Peter, the worst mistake is to start a BPM/SOA initiative by evaluating and purchasing software first. The issue is that very few organizations actually know upfront what type of software they need. Adjusting solution to match off-the-shelf software is equivalent to letting someone else run your business.
... most initiatives that start with a product purchase are owned by the IT group and result in bottom-up advocacy and implementation strategy. This causes a disconnect from the strategic goals of the business, because the tendency is to be more focused on the technology than the process or business need.
Discounting organizational change effort. Because most people are change-averse, they don't like change even if it makes their job easier.
If users are properly engaged and provided the opportunity to review, comment upon, validate and help make decisions about the new processes and systems being put into place then they will internalize these changes and accept them.
Trying to "boil the ocean". It is rarely possible to implement a BPM/SOA solution as one massive upgrade or roll out.
BPM and SOA efforts are both inherently evolutionary in that they are best implemented in small, constrained, and frequent capability releases that grow upon each other. Capabilities should be rolled out iteratively in a controlled manner. Processes and services should be independently managed and implemented such that they provide immediate value to their user communities.
Best practices, described by Peter include the following:
It all begins at discovery. Peter considers throwing a technology solution together before there is a clear understanding of the problem as a number one reason for failure.
Accurately defining the processes being managed and documenting the service contracts (WSDL files and data schemas) should be the first and most significant aspect of any implementation initiative. Once an accurate and clearly documented Process Specification (i.e. business requirements) has been validated, signed and approved by your client or partner organization, then and only then should a team begin development and prototyping.
Approach BPM and SOA together as a composite solution. Many people consider BPM and SOA as two independent undertaking, often implemented by different organizations and with different priorities.
BPM and SOA are ,,, strategies and techniques that are utilized to solve some fairly common and ubiquitous problems within business. They also ... [are] well supported by technology platforms. BPM suites are very effective integration tools, especially if there is a need to integrate both humans and computer systems into a consolidated solution. Web services and SOA technologies are great mechanisms to provide code reuse and interoperability between both computer systems/platforms and organizations.
Start with a mission-critical process. As every new approach, SOA BPM needs to be proved in order to obtain management support.
Start with a single mission-critical business process that will recognize identifiable and quantifiable value. Ideally, an organization should select a process that is directly customer focused and does not have an obvious solution... This will result in the implementation being owned by the business group(s) within the organization and not become the responsibility of the Information Technology team.
Peter ends his article by underscoring the complexity and power of SOA and BPM implemented together. He also encourages taking a business, not a technology driven approach to them. Following dos and don’ts as described in his article does not guarantee success, but can decrease the chances of failure.
Posted in: software | Tags: soa bpm buying software first organizational boil boil the ocean inherently mission-critical process composite solutionAgile Adoption: Projects Should Dive-In, Organizations Should Toe-Dip
Hearty debate abounds about whether agile adoption is better done in a gradual "toe-dipping" manner or with an all-or-nothing "head-first dive" approach. Johanna Rothman says do both: projects should dive all-in, while organizations should take it gradually.
In 2 recent blog posts, Plunge In (For Projects) and Small Steps Are Good, Be Careful What You Call Them, Johanna posits that people need to take all-in approaches to adoption of agile at the project level. In essence, she takes a hard line that doing things like working in timeboxed iterations or doing continuous integration, while likely to improve your situation, does not mean you're doing "agile". And further that you are setting yourself up for failure if you call this agile:
...if you call something agile, please make it agile. If you dip your toe into it, you have not made the commitment. If you vary your timeboxes depending on whether you finish work in the timebox, that’s not agile; that’s incremental development. You can say, “We’re experimenting with incremental development. We choose to vary the length of the timebox so we can practice getting to done. Maybe after we practice it for a while, we’ll fix our timeboxes and see how that works.”
That’s perfectly reasonable. I encourage you to do so, if you haven’t tried incremental development yet. But don’t call it agile. It’s not.
Soon after, Rothman presented a third post that ultimately suggests the opposite when it comes to organizational levels of agile adoption. She suggests that managers take a more gradual approach to changing administrative structures across the organization:
Moving to agile for the entire organization is a non-trivial problem. The zeroth step is the project. The first step is the project portfolio. Then comes the really hard work: the human systems are the next step. Once you’ve moved the human systems back to helping the employees, now you can attack the money systems. (One of my clients is trying to do the money systems first, and that’s not working. There may be some give-and-take here, with the money and human systems.)
Managers, it’s ok to dip your toe into agile for the management systems, as long as you take a coherent piece and commit to agile or lean for that piece. It’s not ok to dip your toe for a given project–commit to agile for a project, if that’s right for you. And, commit to learning about agile and lean management.
In essence, Rothman says over this short series of posts that doing agile well requires a level of discipline that not all projects are prepared for. Choose which projects are ready, and transition them fully; but, worry not about transitioning all projects or the whole organization all at once, think 'gradual' when it comes to that. What do you think?
Posted in: website seo | Tags: organizational agile agile adoption ultimate essence gradual