Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We are planning a new project and we want to go with a services oriented architecture. Everyone agrees that this is the way to go but how does this fit in with starting the development using agile methodologies?

I do not have any experience with SOA, although I have some experience with TDD (test driven development). The team I work with thinks that we need a framework in place before we can even start looking at developers doing work with TDD. In others we spend weeks getting a framework in place (a SOA framework) and then the developers can build on this framework to do their work.

From a TDD point of view, I would have expected each developer to just flesh out the functionality using MOCKs etc whilst the framework is being developed (although I have no idea what a framework in SOA would involve). Then we could plug in the actual framework calls when we need to. Not sure if this right but it feels the correct way.

share|improve this question
add comment

8 Answers

I think you'd be going the wrong way trying to use TDD as a way of fleshing out higher-level architecture elements like the choice of a framework (with the exception of a mocking framework maybe, the need for which can be discovered as your test suite grows). The refactor part of the TDD cycle is much more about micro decisions such as changes in the design of classes or methods, than big picture reorientations. If you need an ORM framework, for instance, you most certainly won't discover it through TDD.

You may be right though in saying that TDD will allow you to work out large parts of your code base in isolation from the rest and thus delay the choice of an SOA framework to the exact needed moment.

However the fact that you can afford to delay the choice doesn't mean it is forbidden to choose upfront, especially for big foundational architectural decisions that will have an impact on how your application is structured. Also keep in mind that unfortunately some frameworks are invasive and you end up forced to code things a certain way, which could ruin a part of your efforts if you have already developed a large part of your Services layer in an agnostic way through TDD.

share|improve this answer
add comment

Simplicity -- the art of maximizing the amount of work not done -- is essential.

Don't assume anything about what frameworks you will be using. Focus on satisfying your clients/users needs as quickly and professional as possible. Add frameworks when you have an actual, real, measurable need for it.

share|improve this answer
add comment

You should definitely not plan to write a framework. You could plan to use one that is already written, (e.g. JEE with Jersey or many others), but attempting to write a proprietary framework to meet some imagined requirements is at best break-even. At worst it becomes a multi-million dollar mistake. The developers who want to write a framework are just postponing the real work of meeting the needs of your customers. If you follow test-driven development and continuously refactor, the exact framework you need will fall out as you refactor.

share|improve this answer
add comment

Agile development approach can be greatly complemented by a framework and the structure of your code.

At the risk of being bashed for linking to my own project, I've been working on a framework specifically optimized for Agile Development. Here is small except from documentation explaining approach to application building with very vivid requirements. It's still work in progress but should be able to answer your question.

http://agiletoolkit.org/learn/app

share|improve this answer
add comment

Agile is only a software development methodology. To understand it better, imagine that you work in a car manufacturing company. Agile just tells you how to manage your work to create a car better (not necessarily to create a better car). However, it doesn't require you to have engine manufacturing pipeline in place first.

Agile is all about breaking long periods of development into smaller periods (sprints) to give developers and businessmen a chance to understand which way they should go sooner, so that they can act more flexibly.

A team can start agile methodology, even without having a framework. In that case, one of the Product Backlog Items could be As a developer, I want to create a framework, so that I can develop faster.

Thus the answer is no, agile doesn't need you to have a framework in place first.

share|improve this answer
    
Thanks Saeed. What I understood from agile is as you said "give the developers and businessmen a chance to understand...". If I do not have a UI in place, how can I get show at the end of an iteration (sprint) what has been achieved? –  JD01 Aug 22 '11 at 12:29
add comment

Agile is many things to many people and some feel strongly about those things than other. Read Agile manifesto. This is just my opinion, but at the end of the day Agile is about doing what's right with minimal amount of overhead and using whatever good and proven methods/techniques (i.e. TDD...) that make sense for your specific situation.

As others have already mentioned, most agile teams strive to deliver small increments in small iterations. And whenever possible you should be doing the same thing. At the same time, it pays to have the right design done upfront. If your application requires a framework, by all means go ahead and put the framework in place. Yes, you will not be able to deliver anything working for several weeks and maybe more, but if you and your team feel that you need it, then do it. The corner stone of Agile is that it's about people, do what people believe you need to do and they will have your back and be vested in the product. We used to force constraints that made the entire team feel weird and awkward and that's just bad.

At the same time keep in mind that you can treat your framework as a separate deliverable that must be delivered to a "development team" so that the team can deliver the final product. Most of the time after the minimal foundation is in place, you can work on framework in increments just like you would on actual product. Decide the absolute minimum you would need from the framework to make the product do something and focus on that first.

Also IMHO, take the phrase "no big design upfront because you are agile" with a grain of salt. Although you definitely do not need to go into details and spend 6 weeks writing design documents, for a large scale project it still pays to spend some time thinking about overall architecture and high-level design. Put the big pieces in their right places so your team has a clear roadmap where you want to end up. Because you only do high-level design, if your direction changes, you will only need to update high-level documentation (shouldn't be a lot). I would never rely on refactoring alone to dictate the final structure of a large application. Your goal is to do minimal design NEEDED, not absolute minimum to a point where there's virtually no design upfront and requirements drive evolution of your modules.

Finally, just because you can't deliver anything actually working until the entire framework is in place, it doesn't mean you can't chop up the framework into several pieces and focus on each one individually along with TDD. You can abstract away SOA interfaces, database, network communications, some other back-end logic and even though all of this must be in the framework, you can do write each one using TDD and mock up whatever interfaces those pieces will talk to. Some of your team can start working on actual application code using mock classes that pretend that your final framework is in place.

So forget about methodology, take a step back and ask yourself (and the team), is SOA the right approach for this application? If it is, you can definitely make it work with agile.

share|improve this answer
    
Thanks for all the information, this has been very helpful. Lets say we don't have much of the framework in place, how can I deliver anything if there is no UI to show the customer? From a TDD or BDD approach would it be fine to show the acceptance tests passing? –  JD01 Aug 21 '11 at 21:21
    
do what makes sense. One aspect of agile is communications, so talk to your product owner and decide together which acceptance criteria you will use for stories that don't have visible deliverables. Usually end customers don't care (or have enough understanding) about workings of low level modules, so showing them TDD results will probably be underwhelming for them. How many developers are on your team? Can you have some work on framework while others start in parallel on UI? One thing that agile advocates and you should try to achieve, is pulling a "single strand" through all... –  DXM Aug 21 '11 at 22:40
    
... layers/levels/tiers of your application. Once that is in place and actions in the UI actually propagate all the way to the other side, you can a) focus on making smaller incremental changes and b) be able to open the actual UI and discuss it with the product owner as functionality is continuously being added. –  DXM Aug 21 '11 at 22:44
add comment

Doing a lot of upfront design (which you will need if you want to build a good framework) is not what agile is about. Especially the first increments are quickly deployed using agile methodologies.

My gut feeling says your choice for a services oriented architecture might be the problem. I'm not saying you shouldn't do any architecture in an Agile project but the first increments will guide you towards a good architecture. If you're really doing an agile project you will let requirements guide you to the right architecture by refactoring old pieces of code to newer insights.

share|improve this answer
add comment

Definitely not. Agile is based on small increments and constant feedback. Starting with a framework is more likely to generate scope creep and besides that, you won't be having anything to show in, at least, the first month of development. It's much more important to be on the same wavelength with the stakeholders, so being able to show some working functionality (even if it's just a mockup) very fast is more important than a framework. You can flesh out the framework as you develop your application and you can later evolve it into something you will use in other projects.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.