Presenters: Rutger Dijkstra


Give and gain insight into the drivers for calcification in Service Oriented development, and measures that might be taken against those.

Intended audience:

engineers, architects, and project managers from the field of business process automation (or interest therein).

About 15 attendees strikes me as the limit for any meaningful discussion.


While adaptability is one of the prime motivators of Service Oriented Architecture, it does actually present a challenge for agile methodologies. With SOA rapidly becoming mainstream in enterprise automation and agile methods slowly being forced upon it by the ever increasing rate of change, the two must meet. This should be a happy marriage, but looks like being an uncomfortable one. The session will kick off with an experience report from the telecom world yielding an inventory of "agile challenges". We then switch over to discussion and brainstorm.

The experience report draws from two perspectives

  • Responsibility for some of the services in an organically grown service oriented landscape wherein the various sub-systems stem from different moments in the past, are built according to the standards of the time and were originally conceived for a different purpose than the role they meanwhile play. While I am a firm believer in letting your SOA evolve organically, the absence of the word "architecture" in the previous sentence is both deliberate and disturbing.
  • Responsibility for the interfaces between the services in a now-we-do-it-all-over-and-not-make-the-same-mistakes project that aimed to realise a SOA from scratch. Being in control of how the services interact, puts one in an ideal position to prevent the big ball of mud from forming. One would think.

Challenges include:

  • SOA is an open invitation to push big design up front to the extreme. Any RFC from the business is likely to impact several services in the landscape and the responsibility for these parts is likely to reside with different parties (teams/departments/companies). This calls for careful coordination of interface contracts and deployment. How do we avoid extremely long release cycles that cause even the smallest of change to take at least 6 months to make it to production?
  • SOA presents a real business case for solving problems in the wrong place. With some systems outsourced and others maintained in-house, the cost and realisation time of changes is wildly variable in ways that have nothing to do with the technical size of the change. It may, therefore, be far cheaper and faster  to implement messy workarounds in all clients than to repair an easily fixable service deficiency. What agile practices counteract this, and how could one apply these?
  • Legacy and off-the-shelf services invite, or even force, the system architects to solve problems in the wrong place because solving it in the right place is not technically feasible. Once service logic starts percolating into your business processes, testing individual services becomes rapidly less conclusive, turning the system in a big ball of mud that can only be tested as a single unit.
  • A B2B service may be serving several independent, possibly competing, parties that have no tolerance for one another's RFCs or release planning. Could the answer to keeping this agile lie in one of the ultimate sins of SOA: the client specific interface?
  • All of this comes, of course, on top of the usual chaos created by orthogonal agendas of the enormous amount of management involved and the irreconcilable inconsistencies of the requirements –imposed by uncoordinated management with conflicting agendas–.

So, good luck.

I am hoping for a discussion/brainstorm session on counter measures. I see three areas for these counter measures: technical, the development process (tactical), and politics (strategic). I also see two scopes for counter measures:local, i.e. applicable to any part in isolation, and global, i.e. applying to the system as a whole (and requiring political victory). It would be nice to get something in all 6 boxes.

Depending on size, experience, and preferences of the audience, the discussion can be planar or done in groups. In the latter case, all groups may tackle the same problem set or we may cut up the cake.

Format and length: 60min experience report & discussion