Working with SOA in an Agile environment

In this Ask the Expert, Todd Biske explains if SOA needs to be lightweight and flexible in order to handle Agile projects and also talks about ways governance programs keep Agile developers on track without outside distractions.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

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.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy