Skip to Content

BPM & SOA – A change is gonna come Part 3: Change the way we work

In my previous blogs, I focussed on the changes ahead where we look at the way IT supports the Business. Business Process orientation, Architecture Frameworks and Services Oriented Architecture are jointly forcing us to change the way think. That is however not where it stops. In this blog, my colleague Martin Gerritsen and I will focus on changes we see in the way we work. Here as well, several initiatives that were planned during the last few years are coming together in the projects at hand.

Main changes are resulting from the shift towards process oriented and business driven IT support as well as from the stronger project governance from an architectural point of view. Combined with the availability of improved tooling (which we will discuss in the next blog in this series) this leads to new ways of working for a lot of SAP consultants and customers. Is it all new then? No, definitely not. We already worked within architectural boundaries, we did design the user interfaces and yes, we did some prototyping now and then. We might even have done some process modelling in the business blueprint phase…

Then ask yourself this: did we do all that in a strict and governed setting? Did we align our developers with the business? Did we have proper discussions on which IT solutions would support the business requirements best or did we discuss how we could mould and bend the IT solution at hand to cover the immediate business needs? Did we have project and solution architects leading the way and did we reuse existing functionality to the max? Or did we put together a team of functional and technical SAP consultants and hoped for the best?

Probably the truth is somewhere in between, but when embracing the process oriented way of working we will have to go through all that. Isn’t that a big hassle? Yes, it is. At least the first time around it is. Depending on the level of BPM maturity, depending on the level of architecture governance in place, depending on the tools at hand and definitely depending on the expertise and focus of project members on process orientation it can be a struggle. The good news is: we don’t have to do it all at once. We don’t have to implement the entire Architecture Framework and Principles before the project starts. It is not mandatory to have all the Services Orientated Guidelines and Tools in place and we don’t have to bring in all kinds of new expertise to do the trick. What we do need is a good plan. We need an IT strategy that supports the transition towards process orientation. We need clear decisions on how the organization wants tot deal with services. We need the willingness to start the process blueprint without thinking IT, focussing on the business process at hand. When we have that, we are off to a good start and we can start changing the way we work.


All this is described and supported by SAP’s Methodology for Accelerated Transition towards SOA. This methodology clearly identifies the levels on which we have to make decisions and provides guidance on the activities we have to execute. All SAP’s initiatives towards process orientation and SOA (SAP EAF, Enterprise SOA, SAP BPM, ESR, NetWeaver CE) are coming together is this approach.

On the Enterprise Level, the Strategy and Governance are providing the essentials. Here the SAP Enterprise Architect Framework and the Service Governance are discussed. When we have sufficient guidance from this level, we can check and develop the Landscape Foundation level, which provides us with the tools and components available for introducing BPM and SOA on the Project / Solution level. For all of you who are wondering how the product offerings from SAP are tied together in the BPM and SOA initiatives, the landscape foundation topic is an excellent chapter to spend some time on. With the boundaries set and the guidelines provided we can start working the projects.

In the Plan phase, the BPM methodology (as discussed in the SAP BPM curriculum) becomes eminent. The Business Process Blueprint (BPB) will be one of the main deliverables resulting from this phase. It is essential that the Business Process Blueprint provides the solution from the business perspective. It would be preferred if the blueprint would not consider any detailed IT restrictions. This will be hard to achieve since we are all limited by the boundaries of our landscape foundation. The BPB describes the Process Flow, the Actors, Rules and Tasks for the process components. It furthermore identifies the Process Performance Indicators (PPIs), Data Objects and the Business Services required in the process steps. With this established, the architecture guidelines will provide the required direction to map the business requirements to the available or planned IT solutions.

The next step is to start detailing and prototyping the design for the IT solutions in the Build phase. With NL for Business we use the model shown here as a reference for the way we work in this area, defining all the IT relevant components from the BPB.

NL4B Approach


Defining the IT solution components (User Interfaces, Process Integration Scenarios, Enterprise Services) from the business requirement provides the flexibility and re-useability required in today’s IT solution architecture. In the Build (realization) and Run (Execution and Monitoring) phases, the details of these solution components are designed and developed. When designing and developing the components, prototyping is a preferred way to finetune the design and to keep the business involved. This is important, since we want to avoid surprises in the end when business ‘suddenly’ realizes a new way of working is coming their way. We have to keep them aligned and in our experience, prototyping and intermediate deliveries which the business can evaluate are excellent methods to realize this.

Another important change is that the delivery of the IT solution will  be part of a continuous improvement cycle. We realize that not all companies are equally mature regarding BPM, but monitoring, evaluation and process improvement are part of the solution lifecycle and will therefore have to be addressed. PPIs defined in the BPB are key to this ongoing evaluation of the processes at hand. The flexible set up up of the IT solution with the reusable (and easily replaceable) components, creates the opportunity to effectively support changes in the business process.

Finally the roles that IT employees play will change. In several organizations in which this way of working was introduced we see old roles disappearing or changing and new roles evolving. Solution Architects are scaling up towards the enterprise level and therefore have to let go of their strong (single) application oriented focus. Introducing the bigger picture of the enterprise level and the SOA governance structures in the organization usually provides them with much appreciated opportunities and challenges once they have overcome their initial resistance to change. The application specialists are shifting towards process orientation and are aligning with the business they support. They will have to make the switch from solution functionality to business requirements in order to stay on top. New skills are required such as process modelling and business rule design. At the same time, the role of the more technically oriented solution specialists is broadening. Active involvement in the design phase is required for e.g. User Interface design and Service definition. This requires additional business knowledge and communication skills as well as expertise on new tools, technologies and products in the SOA provisioning and consumption areas.

So where a lot of activities and components are based on current best practices, process orientation does require changes in the way we work. We don’t have to make these changes all at once. Initial projects will contribute to the development of the SOA governance and the establishment of a proper BPM practice. When skills and expertise improve and architecture and governance mature we are progressively moving towards process orientation.

I would very much like to thank my colleague Martin Gerritsen for his thoughts and input on this topic. He also joins me for the next topic in the Blog Series: change the tools we use.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.