A hotly discussed topic during cocktail hours at the recently conluded Netweaver conference in Orlando was "how succesful are real life projects in doing ESOA, and what are some of the lessons learned in the process?". It was a great experience for me to listen to this candid conversation, and contribute some of my own experiences in managing ESOA projects.
A major struggle for most companies seem to be one of "how do I approach ESOA?". Partly due to misinformation, and partly due to marketing hype - some of the general assumptions out there seems to be that
1. Every service you probably need is service enabled by SAP out of the box.
2. If it is not out of the box, then you can create your own service quite easily.
3. There are immediate tangible benefits by switching to ESOA.
Of course none of these assumptions are completely correct, and the moment you tell this to some one - it deflates their confidence in ESOA. So how does one break the news in a positive manner? This is where a structured approach helps you. I am not going to discuss things like Global data types, ESR etc and focus on some of the more non technical aspects.
You need a well defined scope
This is a no brainer, right? ESOA or otherwise - you need to contain scope in some fashion. Beyond, the obvious, we not only need to contain scope in general - but we need to specifically control the scope of "services" within your overall scope.
ESOA does not need to be an "all or nothing" paradigm. Not every piece of functionality needs to be ESOA enabled. This is not a hard concept to understand. For example, if a piece of functionality is self contained without any interface to another system - there is no urgency to push it over to ESOA right away. Some day later, there might be value in doing it for things like common master data usage, UI unification etc.
The way I do it is by compiling a service model. This is a master scope document for the whole project, and includes all functionality - services and otherwise. Services are further broken down all the way to components, operations etc. Remember that some of the services might be based on non-SAP systems. Maybe in another blog, I will go into the details of developing a service model.
The service model does not care if something is a webservice - all it cares is whether it is a "business service". The general idea is to first get things listed as business users see it, and later take technical realization decisions on how to implement them.
The approach is to attack the scope in a top down fashion to create a service model. Once you have it down pat, then you take a bottoms up evolutionary approach to identify candidates for service enablement, and go through the regular life cycle process in a project (or spread across projects). Over a period of time, the idea is to service enable all suitable parts of your solution. Explain the approach clearly to your stakeholders - so that they see that the value realization doesn't happen overnight.
You need a qualification process
How does one determine what qualifies as a service? Is there a modelling and architecture approach that would tell us how to decide this?
IBM has a patented methodology that we use in our projects. I am sure other consulting companies probably have one too. I cannot emphasize how much this helps us in keeping a project running smoothly, especially when it comes to managing scope.
We subject each new "request for change" to an acid test - a series of questions, and if it passes, we consider it a service. These questions are not rocket science, and you can form your own set of questions, in case your company is taking the ESOA path without a consulting partner. There is a lot of information on the internet waiting for a google search. Spend the time upfront and set a qualification process in place before you start down the ESOA road. Trust me - it will be time well spent.
Use the power of visuals
Any one who has tried ESOA in their organization knows that the geeks fall in love with it faster than the suits. Suits are smart people and once they see ESOA in real life, they usually come around quickly. The trick is - they need to "see" to believe. One of the simplest things you can do to bridge the gap is to organize demonstrations on the system for the suits. Although powerpoints help with keeping the content structured, nothing works better than a demo on the system.
Here is an approach that has worked for me. I use a 3 part demo. In first part, I show a visual composer demo with say weather or google maps - something that every one can relate to. This would usually help break the ice.
Next, I try to combine the maps with something that the business knows of already in the system - like vendors, or customers or employees. Basically I try to show customers in a map or something like that. I found a lot of similar stuff on SDN itself and often times, just reuse a video - instead of developing it myself. In my experience, you win over a third of the users by this step.
In the last part, I choose couple of scenarios from the business - things the users do every day, and put it in VC with guided procedure - and show them how easy it is to compose new processes in hands-on fashion. By now, I usually get 2/3rds of the room to buy in.
The rest - it takes a lot of work to get their buy in, and my view is that it is better to focus my energy on these last few, as opposed to on the entire population.
It goes without saying then, that you have to periodically reinforce the idea with business so that they don't lose momentum. Everytime you need a decision from business, I usually refer them back to the demo we did and ask them "remember that 1-2-3 process we did for invoice verification? I need to check with you what business rules we should check in step2"..or something along those lines.
While we are on the topic - here is a tip. Use real data - use a customer in the production system, and not "CUST1" or "TEST1". A lot of users will not make the connection unless they see data that they trust. Not all suits are this way, but a majority are. To save yourself some frutration - just dig out some real data and use it in your presentations. Better still, ask the users for some example data before the session, so that they feel involved in the process.
This approach helps you back in return too - over time, I have seen business users explain their requirements in a way similar to how they saw things in the demo. This will help you tremendously in the blueprinting and realization phase.
Avoid the potholes along the way
Let us take a look at how things worked several years ago, when ABAP was the only show in town. A big pain of all development managers was to control duplicity of efforts by programmers. Left to their own devices, usually each developer will encapsulate functionality in a different way, and you will end up with several functions that all did the same thing. Even SAP themselves were not completely succesful in preventing this. When I was an ABAP developer, every time I tried to find a function module to use in my own program - I used to find several ones that seemed to do the same thing.
This is exactly true in SOA projects too. A lack of discipline in building services is much more problematic than creating several function modules that do the same thing, but has different interfaces. Why? because services are generally used external to your enterprise, and the world outside your four walls won't adopt your services strategy if there is no stability in the contract. Basically, you will defeat the whole purpose of ESOA .
This is where an SOA architect becomes invaluable. This should be the dude where the buck stops on all things SOA in your project. Traditionally, this role is filled by a senior developer. There is an inherent risk in staffing this by some one with a heavy focus on technology. On the other hand, a heavily business focussed person might not have sufficient background in the technical nuances to take a good decisions. So, till such time as you find a person who has a great blend of technical and business knowledge, try having a technical architect and a business architect doing this role together.
A word of caution though - if things come to a stalemate between the two, you need a mechanism to break the tie in an objective fashion. In my experience, a third person or an overseeing governing body is best suited for this job (rather than giving the over ruling power to either business architect or technical architect).
It would be great if those of you who are into ESOA projects can also share their experiences here, and we can all learn from each other.
