Loading ...
Sorry, an error occurred while loading the content.

Re: Integrate or Stovepipe?

Expand Messages
  • news.gmane.org
    Hi Dave Very good question! We ve recently moved from 3 code bases and fragmented teams to a single team and a gradually unifying single code base. We found
    Message 1 of 9 , Nov 2, 2005
    • 0 Attachment
      Hi Dave

      Very good question!

      We've recently moved from 3 code bases and fragmented teams to a single
      team and a gradually unifying single code base. We found that testing
      how the different apps interfaced together was really a pain. We've
      coined a term for our integrated architecture as well - a Monocoque
      architecture.

      The term Monocoque comes from car design You know how cars used to be
      designed and made in separate chunks and then put together aftwards.
      Well now they are designed and made as a unified structure. We use this
      metaphore when explaining to management why we wanted to unify the teams.

      There are many advantages for us in a Monocoque architecture, because
      integration is more important than anything else. In our case, the whole
      is definately greater than the sum of the parts. However if the separate
      apps can stand by themselves and interfacing is only of limited benefit,
      there may be less benefit from doing it the Monocoque way.

      Daniel Poon


      Dave Rooney wrote:

      > I know that the conventional XP wisdom regarding frameworks is to build
      > at least two applications and refactor the commonalities out into a
      > framework to eliminate the duplication.
      > However, what does the group think about dealing with the integration of
      > multiple applications?
      >
      > At a current client, we have two different groups using two different
      > approaches to delivering applications. The group with whom I currently
      > work has a policy where any new functionality to support the business is
      > integrated into the existing system. This results in a common code base
      > for what can appear to the end user to be multiple applications. That's
      > a "Good Thing". However, it does take a good chunk of work to properly
      > integrate new functionality in terms of figuring out where to put
      > things, and refactoring the code appropriately. Over the 2.5 year time
      > period that this system has existed, it has taken gradually longer to
      > integrate each new piece of functionality since the system continues to
      > grow and the refactoring efforts take longer. I have mentioned before
      > that there is a substantial technical debt in this system, and this
      > continues to be an issue. So, the end result is that our releases are
      > taking longer over time for an equivalent amount of functionality.
      >
      > Meanwhile, there is another team that uses a different approach. Their
      > philosophy is to build small, simple applications to meet specific
      > business criteria, and create interfaces between the applications as
      > required. What I'm seeing from them is that they're able to react to
      > business requests faster than we can, although they have a considerable
      > amount of code duplicated between applications. While that team could be
      > considered 'agile', they aren't specifically using an agile development
      > method.
      >
      > So the question is, which approach is better? There are definitely
      > merits to a single, integrated system, but in practice we've found that
      > it certainly isn't easy to do and that our ability to deliver business
      > value has diminished over time (based on our team's track record - we're
      > still way ahead of most other teams). There are also merits to building
      > small stovepipe applications with interfaces, but you then have to deal
      > with duplicated code, possibly in multiple incompatible versions.
      >
      > I'm wondering if a hybrid approach would be better - build the stovepipe
      > application to meet the immediate business need, build any required
      > interfaces, but assume that over time that stovepipe will be integrated
      > into the system to eliminate duplication.
      >
      > Thoughts?
      >
      > Dave Rooney
      > Mayford Technologies
      > http://www.mayford.ca
      >
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
    Your message has been successfully submitted and would be delivered to recipients shortly.