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

Re: [XP] Question about XP and Architecture (part 2)

Expand Messages
  • calfred56
    Your approach is reasonable. The 3 challenges described above were identified because they were indentified as very important by the customer, and they each
    Message 1 of 6 , Jul 4, 2003
      Your approach is reasonable.

      The 3 challenges described above were identified because they were
      indentified as very important by the customer, and they each possess
      a significant amount of complexity.

      Your strategy is to tackle the challenges one at a time, with
      relatively small steps (i.e. replace one RF radio with a handheld).
      This is a sound strategy, because there's a lot to learn.

      On the dispatching side, we might start small with a module that
      models the baggage stops and driver assignments, and supports
      manual dispatching. Tracking the manual dispatching decisions
      might yield some interesting data about how the dispatchers think
      about the problem. It helps us to learn more about what makes one
      solution better than another. Also, it lets us capture a rich set
      of test cases for an automated scheduler.

      My original point was less about how to tackle the architectural
      challenges, than it was about how to identify them in the first
      place.

      Thanks for the insights.

      Charlie

      >
      > Let's take a closer look at the stories that might come out of
      this. If
      > I understand the scenario, these folks already have voice radios,
      and
      > they are just looking for an upgrade to more computer automation.
      >
      > If the most important feature of the new system is the scheduling,
      then
      > we could implement that on a desktop computer, and have the existing
      > dispatcher continue to communicate with the handlers by voice.
      >
      > If the most important feature is to replace voice communication with
      > data, then I would first do some spikes into rugged handheld
      options.
      > These might dictate some choices about languages and protocols.
      >
      > I might end up deploying the first version (what some people might
      call
      > a pilot) with non-rugged hardware. Or with rugged hardware that's
      far
      > bigger than the eventual design, if it makes development easier.
      >
      > > I might need to start work on a messaging system in week 1. I
      might want to have
      > > a rudimentary system that allows other components of the system
      to interoperate.
      > > While I might not solve the problem of highly-available messaging
      in week one,
      > > I need to be aware that it is a requirement.
      >
      > I'm not sure how much knowing it's a requirement would drive
      > development. The first story might be (probably should be) to
      replace a
      > single walkie-talkie with a single handheld computer. The existing
      > dispatcher could even manually type in a message to send to the
      handler,
      > so we would need almost no software on the base station side.
      >
      > > o it's VERY immediate, from the standpoint that I don't have
      viable system
      > > without highly-available communications.
      >
      > The first computer might not even need to have reliable
      communications.
      > We don't have that today with our voice system--we require a manual
      > acknowlegement. So we could rely on that with the computer system as
      > well. When a handler sees a message on their computer, they push a
      > button that responds to the home base. If the home base doesn't get
      (or
      > misses) the response, it sends the original message again, flagged
      as a
      > repeat.
      >
      > > My concern is that a messaging system design that isn't thinking
      about issues
      > > regarding high-availability communications with RF network
      devices from the start
      > > is taking a huge risk. In other words, it's extremely difficult
      to take a
      > > messaging system and just add on a high-availability quality
      attribute, like it was
      > > just another feature.
      >
      > I'm not an expert in such things, so I would rely on knowlege from
      > people who are. And I would do spikes (short experiments). And I
      would
      > try to keep the system as absolutely simple as possible, both to
      > minimize effort, and to make it as extensible as possible in any
      > direction.
      >
      > Kevin
    Your message has been successfully submitted and would be delivered to recipients shortly.