I was asked for advice at a SOA project that starts soon based on Oracle middleware. This is what I came up with as my most critical things to consider at the start of a project. This list is by no means complete and you are welcome to add your top 5.
– It is all too easy to underestimate the efforts of creating a initial working prototype and the reference architecture and then run into large delays because things that seemed so easy just don’t work the way anticipated or the solution proves to be just too slow! So make sure you have the time for try and error until the reference architecture stabilizes and you have solutions for every critical aspect! If this is one of your first projects, don’t get into stress from the beginning due to delivery dates but take some weeks to get a solid reference implementation.
– It is amazing how some things on configuration side are much less intuitive and more complicated than anticipated. Examples for areas where you can spend days understanding the nitty gritty details are
– configuration to optimize performance
– asynch services
– timeouts
Thus it is advisable to have at least one very technical and experienced expert who has deep configuration skills in the team, either from the middleware vendor, from a system integrator or from your own team. Always strange things happen, especially in the beginning and you never know, when you are not very experienced, whether it is a programming mistake or a bug. Fast cycles of understanding, resolving, knowing how to search bugs and solutions in the documentation and fixing it is key.
– for skills in the team: Check you have this type of main skills: Architectural / design, technology and tool expertise.
Make sure you have advanced XML skills: XML Schema, WSDL, especially namespaces, XPath, BPEL. Everybody who is exposed to BPEL and XML is lost without deep understanding because of the untyped, declarative nature of XML things go wrong late after compilation and are hard to track down: “80% of the problems are namespace problems”
– Make performance tests on performance critical aspects early. XML is potentially large and can blow up memory and performance easily. XQuery and Database are means to deal with that. And, even way faster is good old STAX parsing. Again, it takes time to find the bottlenecks and feasible solutions.
– determine main architectural attributes such as the level of loose coupling and make sure everybody buys into them and you map designs to these attributes and guiding principles. This determines efforts and tools.
– don’t be too much in love with tools. Rather have less tools: The complexity rises with each tool and platform drastically and you might end kicking out tools that seemed fantastic but cause problems in the concert of collaborating tools. This is a hard earned lesson 😉
– On change management and project culture many peers have written profoundly, this is important but too broad for this short checklist.
Adventures in SOA and BPM 
Great list of tips Hajo. Couldn’t agree more on the points about determining architectural attributes and investing time in a working prototype. Think it is also important to ensure that your initial project identifies opportunities for creating implementation-free/technology platform-free service contracts. Often times when leveraging existing code or legacy modules it is tempting to use existing interfaces for SOA. Without the proper abstraction, the service would needlessly be coupled.
Vijaynarayanan,
thanks for your comment and pointing out a key aspect. True, too often people still apply bottom up WSDL creation based on a Java class or other existing implementation, this way creating a design that opens door for “tightly coupled SOA” – a too familiar paradox.
Cheers, Hajo
Good points!
Maybe to add:
* Start with guidelines and standards soon. Naming conventions, how to handle errors, debugging, Monitoring, patterns. Later in projects it is harder to incoporate. I also see that is also to experience .
* Use automatic testing for XML mappings. This is worth the effort when testing and regression.
you may also want to check out vtd-xml, the latest and most advanced xml processing model
vtd-xml
Three points:
0- It is a good idea to put your first service workflow pilot as a tightly coupled bottom up creation so that you can benchmark and tune your environment. Then re-factor that same workflow for increasingly loose coupling and again benchmark. This is like putting a tracer round through your first few agile scrum development cycles so you can establish solution context as you tighten and harden the build.
0- The second key factor is very clear governance, service contract specification adherence, and upfront analysis that supports your roadmap plan. Without this up front top down thinking to drive your oversight model… you will shoot yourself in the foot with a canon.
0- Lastly… with a good pilot bench mark set of numbers and initial systems tuning, and a good Capability Maturity Model/Continuous Integration framework in play… (oversight controls) you can proceed for that magic balance of decoupled agility and business capability driving the services inventory.
Follow those three points… your odds to success will improve.
Justin Mead
Sr. Systems Analyst/Implementation Consultant