I haven’t yet started learning either of the two, but I was wondering whether any of you use Agile methodologies to implement SOA?
Thank you
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Working full time with SOA implementations, I have some experience regarding this.
You can use different methodologies to implement SOA into an organisation. I’ve seen no attempt to go in and in one single project remake the entire enterprise integration design to SOA. Rather, this will happend step by step once business requirements emerge or changes.
Often each sub project in a SOA implementation is rather small – often too small to divide into SCRUM sprints with production releases.
In many ways the Waterfall method is usually conceptually the easiest method to implement SOA. The specs of a service WILL CHANGE over time, but there is no way this can be planned into, say 6 months intervalls, since it’s very much driven by business requirement changes or influenced by upgrades/exchanges of enterprise information systems.
However, when the design phase is done and specs + technology pattern is decided, there might be a decent amount of changes of the design spec. in a projects once the implementation phase has started. It is usually the case, from my experience, that once started to flip the stones, old and unknown thigns crawls up that requries changes. A more iterative approach will usually be cheaper than strict waterfall – however not necessairly an agile approach.
Another important factor to decide upon the methodology is the way projects are financed and setup. An agile approach might get better overall result/cash ratio, but that is only if your organisation can cope with agile methods. If you are working as internal contractors to enable SOA for some busines requirement, which I am used to, then a project plan might be setup, a cost estimate and a strict time schedule with responsibiltites. It’s rather hard to hold such as schedule for every single project with an agile approach, specifically, it’s hard to give clear cost estimates for small-medium SOA projects.
For larger SOA projects, delivered to a single owner, I’ve succesfully used SCRUM and really recommend it.