Garage/Yard Sale: Business Process Modelling, SOA, Agile Methodologies, ideas for NetWeaver BPM and Inside Track Sydney Rant…
I’ve titled this a garage sale (or yard sale as my US colleagues would say) as it’s a real mixed bag of topics that are related in some way that I want to sell (I mean discuss but it ruins my analogy). It’s pretty broad in terms of covering business process, methodologies, SOA and development, but if you are BPX’er with some technical savvy or a Solution Architect (Functional or Technical) then please read-on as I’d love to nail this with a decent discussion and potential future follow-up in another blog.
My reason for writing this blog is to put forward some ideasto try cement a direction for those who work for organisations where software development is not their core business and where they are bombarded by all thebest practices out there right now.
So if you’re like me, you know or believe that:
- Modelling is a great way to work with business processes and Business Process Modelling with tools like ARIS is considered a greatway of starting to measure, improve and document your business processes;
- Agile methodologies like Scrum are now beingseen as the bees knees of development methodologies;
- SOA is no longer a consulting marketing dreamand actually is starting to be understood in terms of where it adds value and where it does not;
- SAP’s NetWeaver BPM (Galaxy) is being positioned as the BPM engine for SAP, not replacing PI/XI but providing the cross system workflow tool with a business process view of the world. It’s not a business tool as such (I still can’t see myself asking business users to install Eclipse) but does allow us to visualize workflow cross systems much better thanif we were to use SAP workflow calling Web Services).
Now you’re CEO and CIO are quite possibly telling you that they want SOA, BPM(odelling), BPM(anagement) and I want it done in an Agile way; where do you really start when you have a new business application implementation/development????
Good question and hears a few reasons why…
We still have our external consulting companies wanting to implement waterfall methodologies so they can lock down requirements prior to implementation. Even if we did allow them to run their projects using Scrum or similar, we may not be ready yet to trust them to do this either from their Scrum maturity perspective or wedon’t have someone we intrinsically trust within their project team to act as the lead designer/architect. Another option may be to put one of our architects on the project to give them the agility they require, but that assumes you have enough architects to go around which is usually not likely.
Now we need to start mapping all our as-is business processes in order to develop our to-be world; but hang-on – If I want to do this in aScrum way, must we at least finish our as-is modelling before we build our product backlog or can we just focus on one process area. I’m wondering, can process modelling be done in the same way as code, and be re-factored each release on the fly? Are we just going to confuse the business too much if we try this or are we goingto make way too many assumptions if we do this?
Note – I’m no BPM expert, but I do know we also need to also consider the lifecycle of BPM as too many BPModelling exercises end up as a very expensive once-off documentation exercise. That said, I’m not going to address the business buy-in or tool aspect of this issue, just the methodology component of it.
So we want to implement SOA because we know integration costs are huge. But what I believe time has told us is that without a comprehensive to-be BPModelling exercise, we’re in danger of leaving the identification of suitable reusable services to our techies when this really requires business and techies coming together. (For reference, I believe there are many scenarios where it does not make sense to make an interface a reusable service.)
We now have NetWeaver BPM in our back pocket as a great technical tool (for reference, in its current incarnation, to me it’s more ofan engine for cross-system workflow). We really want to use it for BPManagement to measure and improve processes through what-if scenarios based on real information but we don’t want to have to pull our processes out of our key systems just to do this.
That’s our last problem for today (I’m sure there’s plentymore).
So what to do?
Okay – This is where I’m going to propose an approach which is very specific to an organisation that works in an outsourced environment,has settled on a base set of applications/technologies (like SAP), but holds governance centrally with an insourced team of architects who have way too many projects on the go at once to be heavily involved in more than 1 or 2.
Pretty common with all Agile methodologies is a good understanding of the high-level requirements prior to coming up with ac andidate set of iterations or sprints. You really need this to understand the kind of solution architecture at a high level so that you can also have an idea of the scope and what is practical to be done in the timeframe.
So building an as-is business process model for the area associated with the project is definitely worthwhile prior to commencing the project. Now over time, the fullset of impacted business processes may be captured already, but initially, you won’t have this information so we need to do this if we’re serious about changing the processes in this area in a measurable way. Obviously, from a consulting companyperspective, any company will have no problem in doing this exercise.
Now if we started to do the to-be processes; we’re going to be constraining the development too much from giving the maximum benefits, so really this is where we need to scope the high level requirements and at least understand the potential impacts to the existing processes. This to me is a pretty short and sweet document that captures in table format, components that can be leveraged to build your storyboard.
Now it’s time to plan our iterations, but what are we going to do with our consultants…Okay – Big risk here, but I’m recommending you take an important project and do the following:
- Put one of your internal solution architects on this project for at least 40% of their time if not more;
- Get a Scrum mentor from a consulting firm with proven experience (usually a niche consulting firm) – they could possibly actas the ScrumMaster for the life of the project, but preferably not.
- Engage your most trusted consulting company in a time & materials way but ensure you get the right resources for the project, including a similar Solution Architect who will mirror your Solution Architect (and run future similar projects without your internal Solution Architect).
- Sell the idea to management, telling them that we can quickly shut down the project if we don’t show progress due to the agile approach and how isn’t that better than typical waterfall projects (they’re kind of board already aren’t they?).
- Get to work…
So with this approach we now have the iterations/sprints planned, we have a high-level architecture that has been ratified internally and we’re ready to start developing.
Now being Agile, we have at least the following deliverables every iteration/sprint:
- Our tested production ready code/configuration
- Design documentation
- Test Cases
- Training material
And here’s where it’s different (and possibly a little more annoying):
- To-be business process models for the current iteration changes (and version managed appropriately since your changes are not yet released)
- Requirements mapped to the process models
- Requirements mapped through to our test cases (I’m assuming our testing will remove the need to map our requirements our functional design)
In terms of the to-be business processes; we need to differentiate iterations/sprints from a release. i.e. Although we have a perfect piece of the business process at the end of an iteration/sprint, we would not want to give it to the business till it is stable. Worst thing ever could be to put a business process change into a call centre every 3-4 weeks.
At the end of each iteration/sprint, governance steps can take place, but the assumption is that with your own solution architect involved, there should not be too much requiring refactoring in the next release.
So that gets us past Problem 1 and 2 with hopefully you not being fired (even if it goes all wrong, there is no way this will have a cost blow-out as it can be stopped quickly due to it’s agile nature and focus on quality).
So how to deal with SOA…Well we’ve compromised here. We’re doing to-be models, but unless we leave all integration to the last set of iterations/sprints (which is a verybad idea), we’re going to have to take some short-cuts. So basically, as you do the restricted to-be modelling, it’s important that every interface get reviewed by the solution architect and they need to ask questions of the business like the following:
- Is this interface an out of the box interface?(no point re-inventing the wheel just to make it service enabled at this point)
- Do you foresee this type of interface being ableto be leveraged elsewhere in the future if we write this more generically?
- Is this target application likely to be replacedin the next 5 years?
So pretty lame answer to problem 3, but there you have it. The better your Solution Architect knows your business, the better the outcome of this.
Now problem 4 I put in there as I had an interesting discussion with Oliver Mayer at Inside Track –Sydney…Basically, IMHO SAP’s NetWeaver BPM is lacking a really good business case for just doing it within an SAP environment. But what if they enhanced the functionality of the solution to also allow it to track business processes that take place within systems? Think about this for a minute.
You basically have your to-be model; you import it into NetWeaver BPM, configure your cross-application workflow or workflow for systems without workflow, then for all processes that take part within the system, you expose an API to allow that process to be monitored and measured. Eg. Within an enhancement point, you call out to BPM Galaxy through an async call and set a date/time with a key to identify the specific process and measure that process.
May take quite a bit of playing to make it work, but then we have true BPManagement happening where we can start to play with what-if scenarios with our processes to make significant process improvements.
Anyway, just a thought that sounds awesome to me.
So obviously I’m not a Business Analyst and I’m looking through a pretty specific lens, but if you’ve got this far, have you suffered the same dilemma and come up with a working solution? I would love to hear your thoughts. I haven’t got into detail about how BPMN vs EPC or how you captured detailed functional and non-functional requirements plus the tools required to map these to test cases but maybe that will be my next blog when I go down this path.