A couple of days ago I wrote part 1 of this series and highlighted the things we did that made us successful on our first SOA implementation. Today, I will discuss the things that we should have done differently. Before I start, I would like to note that we are working on six different projects concurrently under the parent program. So some of these "what not to do's" apply to all of these projects not just our initial one that we just rolled.
What not to do...
- Not enough professional services - Our budgeting process only included enough hours to install the stack. We should have covered a few more weeks of professional services for when we first deployed code into the development and testing environments. About a month after we installed the BPMS and ESB, we deployed our first build on these environments. We encountered all kinds of environmental issues and various integration issues between the various components of the stack, especially the portal and BPMS. Since we didn't have budget for any more professional services we tried to figure it all out ourselves. Eventually we brought the vendor in and ate some incremental costs but we lost about a month which delayed the project.
- Needed more vendor references - This is not for the selection criteria but for implementation. We should have sought out more companies that had been through an implementation using these products. We are networking with a few local companies now but it would have been nice to have heard their experiences earlier and we might have prevented some of the setbacks or resolved issues quicker.
- Dove in too fast - This one we didn't have much control over. The downside of having the business fund SOA is that they want results immediately. We started our first project with no governance, no testing strategy, no automated build process, etc. We are trying to implement governance along the way but it always takes a back seat to due dates. Fortunately, a new budget starts in January and we can get the resources we need to get these important tasks done.
- Threw the kitchen sink at the first iteration - I wrote a lessons learned piece a few weeks back which prompted Todd Biske to write a good article called SOA and the Kitchen Sink. We tried to do too many things currently and had a few instances where we were thrashing.
- Not enough internal resources involved early enough - We partnered with a consulting firm to help teach us how to properly architect software in the new world of SOA. At the same time I have been working with the leadership team in IT and the business to free up more internal resources so we can start doing this ourselves. This has two bad side effects. First, very few of our own people were recipients of the knowledge transfer and two, the vendor does not know our business which has led to some gaps in requirements and some architectural decisions that were made that we have had to change.
- Needed more change management - I did spend a lot of time focusing on communications & organization impacts but there was still a lot of "we vs. they", resistance, and confusion about the overall direction. The core team was has always been on the same page, but many spectators are still in the dark. This often leads to resistance and negatively which we deal with immediately, but it would be nice not to have to spend as much time resolving this issues.
- Didn't research SOA testing enough - One of the things we did right was research the heck out of SOA and BPM. But one area that we didn't invest much time in was the testing. We are actively researching the heck out of it now but my advice to others is don't under estimate the changes required to test SOA.
- Occasionally got away from project management best practices - We fell behind by a month because of numerous issues with our environments and some bugs in the stack products that the vendor had to patch. Once we resolved all of the issues we only had two weeks left to deliver our new B2B customer facing portal to our client. We threw everything we had at the remaining tasks but somehow forgot about some of the basics of project management like risk mitigation and we had several communication breakdowns. We coined it as "running around with our hair on fire". On the positive side, we all acknowledged our mistakes and are in the process of fixing this.
- Taming requirements - Requirements have been too volatile and it is hard to be agile when you can't draw that line in the sand until the next iteration. With some of the business services, there does not appear to be enough ownership and accountability. This has caused a lot of rework and has been a big source of frustration.
