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

Re: [XP] XP and Ivory Tower Architecture

Expand Messages
  • Paul Campbell
    ... Well the best case scenario for the extent of change in a business IT system is that the scope of change is only as big as the scope of the change to the
    Message 1 of 99 , Mar 19, 2007
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "Kelly Anderson"
      <kellycoinguy@...> wrote:
      > That's an interesting question. The first question I would ask back is
      > who decided that there needed to be a big architectural change? How
      > did they decide it, and why? How is it that this change really impacts
      > ALL or most of the teams?

      Well the best case scenario for the extent of change in a business IT
      system is that the scope of change is only as big as the scope of the
      change to the business. The problem occurs when that irriducable
      minimum is still "damn big".

      It seems that businesses like to make big changes to way they do things
      with alarming regularity. Now we could (rightly IMO) argue that they
      should do things more inrementally at that level, however, some changes
      are just big. To give a real example from my own experience: if a
      mobile telco wants to change its tarif structure in some fundamental
      way then you can bet that *everything* is going to have to change -
      network provisioning, crm, billing, online, retail outlet interfaces,
      accounting, managment reporting, product managment etc etc etc (believe
      me when I say Ive barely scrateched the surface).

      Paul C.
    • Paul Campbell
      ... Well the best case scenario for the extent of change in a business IT system is that the scope of change is only as big as the scope of the change to the
      Message 99 of 99 , Mar 19, 2007
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, "Kelly Anderson"
        <kellycoinguy@...> wrote:
        > That's an interesting question. The first question I would ask back is
        > who decided that there needed to be a big architectural change? How
        > did they decide it, and why? How is it that this change really impacts
        > ALL or most of the teams?

        Well the best case scenario for the extent of change in a business IT
        system is that the scope of change is only as big as the scope of the
        change to the business. The problem occurs when that irriducable
        minimum is still "damn big".

        It seems that businesses like to make big changes to way they do things
        with alarming regularity. Now we could (rightly IMO) argue that they
        should do things more inrementally at that level, however, some changes
        are just big. To give a real example from my own experience: if a
        mobile telco wants to change its tarif structure in some fundamental
        way then you can bet that *everything* is going to have to change -
        network provisioning, crm, billing, online, retail outlet interfaces,
        accounting, managment reporting, product managment etc etc etc (believe
        me when I say Ive barely scrateched the surface).

        Paul C.
      Your message has been successfully submitted and would be delivered to recipients shortly.