SOA Architecture and Agile Methodology

Over the past couple of months I have been exposed to colleagues, professional acquaintances, and training that has discussed the merits of Agile Methodologies in creating a loose but improved development organization. One client that I work for has several teams that are employing short iterations and have improved their overall deliver of software functionality. The company has also spent time training the teams via experienced Agilists and employed collaboration software to support epics, mrf, user stories, product backlog etc.

Working in the architecture group, there is currently no process in place but we are considering applying Agile and short 2 week iterations to deliver value to the product teams. In essence have the product teams help define challenging issues to be solved to free them up and allow them to focus on their tactical user stories/development tasks. In addition having the architecture team sit in on the product teams iterations to identify / guide the development teams towards existing services in the domain/enterprise to reduce/eliminate rebuilding existing logic. This can be done by participating in the Iteration Planning Meeting at the beginning of each iteration.

From these experience I will be trying some role/organizational approaches towards SOA in an Agile environment. They include setting up clear versioning policies for the service contracts and using design patterns to decouple the contract from the logic. This will allow the contract to more easily change from its potential tactical definition to a more domain/strategic one.

How easy is SOA?

When reading blogs on SOA or technology in general, what strikes me is the amount of misleading information that exists in the space or even worse, the lack of information. When tackling new technologies in open source or standards, the lack of documentation or practical information is quite often missing. Once in awhile, I find a clear and concise document that is able to help me learn a technology rapidly. An example of this was some work I was doing debugging a Hibernate issue. To really understand the process/facilities that Hibernate provides, the base documentation provided a solid basis and was able to get me to completion within a couple of hours.

Compare this with work I was doing with some WS Standards, where the only information I could find was the specification and a poorly documented reference implementation.

As part of my business diversification towards providing training in the SOA and Open-Source marketplace, I will be trying to distill how SOA, the available tools and design standards can be applied to people that have little to no experience. An example of this is a group of QA personnel who I will be training in SOAPUI.

Another group I am training is around building a SOA Application that is front-ended by FLEX and back-ended by MySQL.

My current experiences is always focused on the KISS principle. Don't assume the audience is familiar with XSD, WSDL, Service-Orientation etc.

To date these students are getting the examples and are helping evolve these heterogenous scenarios into potentially valuable training offerings. So I can definitely answer that SOA is not easy however if approached properly, a wide audience can participate and incorporate the core principles and technologies.