Services are the building blocks of SOA, and like building blocks of a house or a building, the quality will define the value of the finished product. In this case, the SOA itself. Thus, spending...

In today’s market place of continuous change, enterprise agility is the ubiquitous fuel for continuous competitive advantage. But agile enterprises demand not only agile infrastructures and systems, but agile processes as well. Clearly, service based architecture has emerged as an enterprise-wide architectural blueprint and agile development is shaping up as a formidable development methodology. The emergence of the SOA architectural pattern and the agile development methodology come out of the same realities and market pressures: increasing level of technological complexity, increasing speed to market, and incorporating change as part of the process and minimizing its impact, while providing business value better, faster, and more efficiently.

Why is agile development getting such corporate attention as a viable Software Development Lifecycle [SDLC] and what are the existing alternatives that it replaces? Inevitably, IT matters only if it can deliver measurable business value in the form of working software and SLAs when needed in time to beat the competition. The traditional waterfall SDLC approach cannot keep up with the internet-time of doing business for an agile organization. By the time we deliver “the goods” in the traditional sequential SDLC fashion it is either too late, we got the requirements wrong, or is of poor quality.

Agile is about incremental and parallel delivery of working software within prescribed fixed time internals, called Sprints, and fixed size, cross-functional teams or scrum teams. Scrum is an organizational pattern fitted to effectively manage agile development projects and cross-functional teams. Requirements in the form of user stories, use cases, and/or storyboards are placed in a list called a “Product Backlog”. The Product Owner is either the sponsor or visionary and has ultimate control of what goes in the Product Backlog and how it gets prioritized and planned in multiple releases.

Depending on project complexity, dependencies and budget we can have more than one Scrum team delivering software. The Scrum teams draw “to do” items from the Product Backlog. Each team has a short daily stand-up meeting called the Daily Scrum where each member reports progress on what he/she did the day before, what they plan to do today, and any impediments that prohibit the completion of their work. A Scrum Master facilitates the Daily Scrum meetings and drives the removal of all the impediments.

Central to the DNA of Scrum teams is that they are cross-functional and self-organizing just as in the modern theories of emergence, social networking, six-degrees of separation, and game-of-life type models. But this is topic for another discussion. The Scrum teams contain all of the team members necessary to produce working software, such as: developers, architects, testers, business analysts, designer, etc. The original premise of Scrum is that the Product Owner defines what items go in the Product Backlog based on customer’s requirements.

This execution pattern works well for software development but how practical is it for implementing SOA? Do you really want to re-invent the wheel every time you start a project and hope that tribal knowledge will prevail and proliferate? Do you want to keep creating a new ESB and adding new technologies while you already have a corporate standard?

To solve this challenge and establish a repeatable agile SDLC blueprint, you can develop a set of Product Backlog templates pre-populated with the dimensions and attributes from your SOA reference architecture. Ideally, you can define project type design patterns based on solving specific technical problems and map pertinent SOA elements to predefined Product Backlog templates designed to address these specific problems.

To keep the agile purist happy you can capture the entries as questions. For example, on a project design pattern requiring an ESB and if Mule is your enterprise choice, you may have in the SOA section of the template Product Backlog “consider how Mule can facilitate transaction management.” If JBOSS is your J2EE standard and the project has a low latency design pattern, a Product Backlog template item for Sprint number one might be: “consider building a prototype measuring round trip leveraging JCash.”

Clearly, agile SDLC incremental characteristics make the perfect companion methodology for delivering enterprise-wide SOA reference architecture one Sprint at a time. By providing project type design patterns with pre-populated SOA Product Backlog items, one can create a repeatable process that builds and delivers on enterprise vision and established best practices.

Until next time, keep Scrumming.

Back to Articles, including SOA, BPM & BA