A friend pointed out an interesting blog called RUP versus Agile for SOA Methodology
by Eric Roch. The initial premise seemed to be that Agile methodologies don’t provide enough structure to build a SOA. My initial belief was that he misunderstood what was meant by agile methodologies. He referenced extreme programming (XP) as his example of an agile methodology. Granted, XP would not be my first choice for putting together a SOA either. That really isn’t it’s purpose. However, XP certainly can be used to create web services for the SOA.
He goes on to state that a lightweight version of RUP could be fabricated to provide design “deliverables”. By deliverables, he means the structure and design used to enforce a set of standards across the SOA. He does point out that, “RUP’s iterative nature and focus on architecture early in the process are well-suited for SOA.” The key according to Mr. Roch is to keep the process lightweight and iterative. What really struck me as fascinating is that is exactly the purpose behind OpenUP. OpenUP is a lightweight version of RUP that is highly compatible with Agile development techniques. Of course, OpenUP won’t really deal with the enterprise architecture requirements of the SOA either unless that is part of the architectural constraints of the various projects within the SOA.
Basically, Mr. Roch is treating a SOA as a single project rather then a series of projects build over a period of time by different groups who are experts only within the varying domains of the SOA. An overarching architecture needs to be in place to define the domains and the governance processes and ensure that it meets its potential. Otherwise, all the process in the world applied to individual projects will leave the business with nothing more then disjointed and conflicting web services. The reality is, the problem he is trying to resolve has nothing to do with Agile vs non-Agile. It is all about SOA architecture and governance. Agile methodologies work well within that framework. In fact, it is reasonable to assume that since one of the promises of SOA is the ability to respond quickly to changing business needs, that Agile methodologies are the perfect complement for a SOA.
Unfortunately, Mr. Roch is unfamiliar with the benefits of using a lightweight process framework like OpenUP to drive agile development. I think if he was more aware of the benefits, he would see that using OpenUP and Agile development could be a win-win for the development teams creating the underlying services that make up the SOA and the architects trying to enforce the governance.