Agile SOA @ Graebel

By Dan Burcher, Enterprise Architect for Graebel (a Trail Ridge client)

Note: This is part of a new and continuing series which is collected under the Agile SOA category.

Here at Graebel, we believe that an Agile methodology provides great benefits to our development teams and our customers. Similarly, the decision to implement a service-oriented architecture has the potential to provide numerous benefits to the enterprise and our users. The question then becomes: Can an Agile methodology and SOA complement one another?   

In many ways there are strong synergies between the two disciplines as well as potential conflicts. First, we’ll examine areas where SOA and Agile are complimentary. Secondly, we’ll discuss specific areas where potential conflicts may arise.

SOA and Agile are complimentary

SOA is architecture. SOA stresses that businesses must be able to respond to the market and that by building services, we can get rid of the duplication and get closer to the elusive goal of reuse. By building services instead of applications, teams can leverage work by others from within the enterprise as well as externally.

Agile is a methodology. Agile stresses that everything changes and that software development teams must be able to recognize and respond to change frequently. By introducing both technical and non-technical practices, our development teams are able to help Graebel become an agile enterprise.

Architecture and methodology can be used together. They are complementary by nature. Moreover, SOA and Agile share the same broad goals. They both recognize that change is inevitable and that organizations need to effectively cope with that change. So we would expect that Agile is by default the methodology of choice when building SOAs and vice versa – right?

SOA and Agile may conflict

You would think that with shared goals the overlap of practices and architecture implied by these two techniques would be in agreement and not in conflict. At this point in time there is little in the SOA community that is agile and vice versa. Why is this?

One of the main reasons is that the SOA community approaches the agile methodology discussion with its own perception. Agile is historically grass-roots and small-project based, although throughout the past years the community has gained experience and learned to adapt the principles of the Agile Manifesto to large projects. SOA is a newer initiative and is top-down in nature, taking an incremental approach to the development of loosely-coupled services, processes and messaging components.

Two distinct areas where the SOA and Agile approaches are at odds:

  • SOA encourages that architecture be upfront while Agile has a derogative term for this approach – coined BDUF (Big Design Up Front).
  • SOA encourages teams to split along functional lines while Agile encourages cross-functional teams. 

Graebel’s Approach

Graebel’s SOA Leave-and-Layer MethodologyTo enable the best aspects of SOA and Agile, Graebel uses a leave-and-layer strategy in which the application platforms are incrementally transformed from point-to-point solutions to service-enabled interfaces. This transformation provides reliable access to the right data and processes at the right time, all while continuing to run the business in a transformational manner. This unique approach includes the best aspects of an Agile methodology to plan and manage the transformation and a Separation of Concerns process to build each layer of the SOA stack for each application in the enterprise. 

Graebel’s SOA Leave-and-Layer Methodology (pictured on left)



Graebel's SOA ProgramThis methodology, which we refer to as Incremental / Leave-and-Layer provides a wise alternative to the BDUF approach. Additionally, we are able to accommodate a cross-functional teaming strategy meaning that our SOA Program team is able to join existing application development teams for 2-week release cycles as each application is added to the integration architecture.

Graebel’s SOA Program (pictured on left)

< Back to Blog Listing