Clipped from: http://searchsoa.techtarget.com/answer/Working-with-SOA-in-an-Agile-environment

–by Todd Blake

Can SOA be lightweight and flexible enough to handle Agile projects? How can SOA governance programs keep Agile developers in line without getting in the way of their projects?

There is an incorrect view that Agile and architecture are incompatible, whether we’re talking about service-oriented architecture or enterprise architecture. People who hear the word architecture and immediately equate it with a big up-front design like Waterfall methodology, and that’s simply not the case.

In my opinion, architecture has to be about establishing boundaries based on the context of the situation. Context not only includes the requirements, budget and time to delivery goals of the project, but must also include enterprise goals, cost to operate and cost of future change, to name a few. While Agile efforts have certainly proven successful in managing the context provided by the project, we still need to balance that with the context outside of the project.

SOA and enterprise architecture need to provide context into the Agile processes to ensure it gets taken into account. Unless you’re in a startup, projects don’t have a blank slate to work from. All of the current systems, the enterprise goals, etc. create constraints within which decisions have to be made. If those constraints aren’t properly documented, communicated, and understood, however, projects cannot be expected to be compliant, and it’s likely the Agile process will suffer because the people that need to provide the guidance around that context are not part of the project team and your iteration planning activities.

The right answer is not “get more architects.” Instead, it is to empower the people on those Agile teams with the information they need to make good decisions based not only on the project provided context, but on the enterprise context as well. That is done through roadmaps, reference architectures, patterns, standards and guidelines that are not just put on a SharePoint site, but actively communicated and updated. The more you can empower people to make the right decisions through solid communication and education, the less you should need heavyweight review processes and documentation.

Keep in mind that all of this represents change to the way an organization may operate. Whether it is perceived as lightweight is heavily dependent on the culture of the company. The more change required, the more heavyweight it’s going to seem. You need to find a balance of what the culture can digest yet still change at an appropriate pace. If you try to apply all of the theory in various SOA books (including my own) without thought for whether your culture is ready for it, it will be perceived in a negative light.

I think many people see governance and lightweight as opposite concepts, but I don’t think they have to be. The best approach to governance is to make compliance the path of least resistance. If you can accomplish that, then your governance may not feel so burdensome. At the same time, governance involves oversight, and oversight will always be perceived in a negative light by many.

For example, if you want to make sure that every service provides an audit trail of service interactions, you’ll get far better results if you tell them “route all requests through the ESB and this will be done for you” or “use this shared library of base classes and it will be done for you”. If you just state the policy, then they’ll pick whatever way is most convenient for them, leading to inconsistency in approach and inconsistency in compliance. Make it so you are reducing the work they have to do, not adding more.

If you do everything you can to enable people to make the right decisions as easily as possible and make the wrong decisions clearly painful and problematic, then your governance program will be more successful.